The philosophy of this forum has always been to provide exceedingly generous image sizes (both in pixel size, and file size), and to allow the attachment of up to 100 images per individual post. Contrast this with forums like PeachParts, which dramatically limit the size of images to very very small file sizes, and the number you can attach.
Why this is important is because image detail is important to members. Historical documentation of all E500E models is a key strategic goal of this site, and preserving this information is paramount for future owners and buyers. Particularly when perusing things like cars for sale, and images posted of these cars -- we want to as permanent a record as possible of high quality images as originally posted by auction sites, for sale ads, etc. Artificially limiting or reducing image quality is antithetical to allowing details to show from original images, as they become a part of the record of each individual car.
There are many image optimization add-ons for XenForo from numerous developers (some free; some paid), as well as modules that can be installed at the operating system level.
Another contributing factor to the forum's large catalog of stored images, is that ALL images linked from and/or attached to messages are automatically proxied, and then stored on the site's storage volumes as both a thumbnail, and a full-size image. This is because web sites have a way of going down over time, and often when this happens images are lost forever. It also helps when images are deleted from web pages, auction sites, and so forth. The forum adds approximately 0.3-0.6 GB of images to its catalog, PER WEEK. Images are only proxied if the request/URL originates from this site.
If ever required, it would be a very simple thing to automatically import and resize all stored images to make them smaller. Yes, this would free up many gigabytes of space, but paying $240 per year for 200 GB of NVMS-based, instantly accessible image storage is really not that big of a deal. To improve image display performance, images are also cached for 365 days.
The forum already has the very powerful ImageMagick Linux module installed (in addition to the more basic GD image processing library, which is not used), which automatically processes all uploaded images. All full-size images are stored on a separate volume of 200 GB, attached to the main forum virtual machine. This volume is expandable on the fly as needed, and is currently approximately 53% full. It costs $20 per month, which is not that much, and is backed up daily and also rsync'd weekly to a local hard drive (which is backed up continuously via both Backblaze and also Apple's Time Machine). Thumbnails for all images are stored on the main VM 80GB drive, as they don't take up much storage space.
Approximately 60% of the main VM 80GB storage drive is currently in use -- much of it storing the access logs for the site, Linux error messages, and so forth. Logs are rotated regularly, but all access logs are stored for approximately one year in case they need to be forensically reviewed.
@xfadmin has full root-level SSH access to the machine. It is an Ubuntu-based virtual machine, running Ubuntu 20.04 LTS, running at the Newark, NJ data center of Linode. There is no "hosting;" it is a full and true virtual machine running on a dual-processor VM. Earlier iterations of this forum from 2008 through March 2019, when the forum ran the phpBB and later the vBulletin 4.x software, were hosted in the classic sense, with very limited administrative access.
That is not the case with the current iteration of the forum, and is why we are able to run things like Elasticsearch (which runs atop a Java runtime environment -- something not possible / installable in a shared hosting environment due to resource restraints). If you notice, the Elasticsearch provides almost instant/real-time search capability via suggestions based on input; it also provides very granular and accurate searching.
Another disadvantage of classic shared hosting is total inode counts, which the very most generous shared hosting environments only allow 500,000-750,000 total inodes, maybe 1,000,000 at the very most. We were bumping up near that limit with the old forum when it was using shared hosting, which is why shared hosting is only adequate for small forums.
Full VM hosting provides many many millions of inodes and would be pretty much impossible to outgrow.