You may even want to consider splitting your geodatabase into two parts, if possible. One for the tax maps, another for photographs. However, if your photos are attributes to your tax layer features, then your you should consider compacting and compressing your file geodatabase, as already mentioned in the comments.
A couple of notes about compact vs compress.
Compacting tidies up storage of records in files by reordering them
and eliminating empty space. If you frequently add and delete data in
a file or personal geodatabase, you should compact your geodatabase on
a monthly basis. This can reduce file sizes and improve performance.
- If your data is organized in such a manner that some of it is read-only, then you can consider "compressing" your data. It should be noted that all features in a compressed state are not editable, read-only. Therefore if your images are attributes to your tax data, you will not be able to compress the featureclass if you want to continue editing (which I assume you will want to be doing). Compress is really great for base data that won't change very often. You can compress the entire geodatabase, a feature dataset, or just the featureclass that contains your images.
To reduce storage requirements, you can compress vector file
geodatabase feature classes and tables (collectively referred to as
datasets in the rest of this topic) to a read-only format. Once
compressed, display and query performance is comparable to
decompressed data. You might find it provides slight performance
improvements in some operations but slows slightly in others.
