Photo libraries are the workload that quietly breaks budget VPS maths. A text-heavy blog might use 2 GB of disk after five years; a family photo collection with originals and thumbnails passes 100 GB in the same period, and Immich wants to generate a preview and a transcoded version of every asset it stores. That changes the question from “how much RAM do I need” to “what does a decade of photos cost to host, and does the cheap VPS still win?” If you are still choosing a host, compare budget VPS plans side by side on disk and transfer rather than on CPU, because storage is what drives this bill.
This article runs the numbers for a realistic library, then covers the parts of Immich that consume server resources: the Postgres database, the thumbnail job queue, and the machine-learning container that does face and object search.
What Immich actually stores per photo
Immich keeps the original file unchanged, then generates several derivatives. A typical 12-megapixel phone photo is 3 to 5 MB as HEIC or JPEG. The thumbnail set adds roughly 10% to 15% of the original size, and if you enable transcoding for video, an HEVC clip can be re-encoded to a more playable format at similar or slightly smaller size. Count on original storage plus 15% overhead as a working estimate.
A 50,000-photo library at 4 MB average is 200 GB of originals, so call it 230 GB with derivatives. Video changes the arithmetic fast: a 20-minute 4K clip can be 1.5 GB on its own, and a few hundred of those will outweigh tens of thousands of stills. Measure your actual library before choosing a plan — a directory listing of file sizes takes a minute and is more useful than any estimate.
The VPS disk problem: provisioned versus usable
Budget VPS plans price disk cheaply up to a point and then get expensive quickly. The common bands are 20 to 40 GB at $3 to $6/month, 80 to 160 GB at $8 to $15/month, and 200 to 400 GB at $15 to $30/month. Beyond 400 GB, block storage attached to a VPS usually costs $0.05 to $0.10 per GB per month, which is $10 to $20 per month for 200 GB on its own.
That is where the economics turn. A 300 GB library on a $25/month plan costs $300 a year for a server whose CPU would comfortably run on a $6 plan. You are paying for disk at a markup that often exceeds what object storage or a used drive would cost. The fix is almost always to split the workload rather than buy a bigger VPS.
Three cost structures, priced over three years
The comparison below assumes a 250 GB library growing at roughly 15% a year, so year three holds about 330 GB. It prices the same library three ways a budget-conscious user would reasonably consider.
| Structure | Monthly | 3-year total | Notes |
|---|---|---|---|
| Large VPS only | $22–$28 | $810–$1,010 | Single point of failure; growth needs a migration |
| Small VPS + object storage | $6 + $6–$12 | $430–$650 | Originals off-box; egress charged on viewing |
| Small VPS + home NAS over WireGuard | $6 + drive amortised | ~$300 + hardware | Cheapest long run; depends on home upload speed |
The object-storage option is usually the best middle ground, but read the egress clause first. A photo library is read-heavy — scrolling a timeline pulls thumbnails constantly — and egress at $0.01 to $0.02/GB adds up faster than storage does. Keeping thumbnails on the VPS and originals in object storage cuts that bill dramatically, since thumbnails are what get fetched during normal browsing.
Memory: Postgres, the job queue and the learning container
Immich’s steady-state footprint is smaller than its reputation suggests. Postgres with sensible tuning for a single small instance sits around 250 to 400 MB. The Node.js server process runs 200 to 400 MB depending on activity. Redis, if enabled, is another 30 to 60 MB. Add the OS and a reverse proxy and you are at roughly 1 GB before anything interesting happens.
The machine-learning container is the outlier. For face recognition and CLIP-based search it loads ONNX models and will happily consume 1.5 to 3 GB of RAM during a scan. On a 2 GB plan this triggers the OOM killer, and the symptom is a container that restarts mid-scan and never finishes indexing. The standard workaround on budget hardware is to either disable smart search entirely or point Immich at an external ML service on a more capable machine — a laptop or a home server — and let the VPS do storage, serving and background jobs. That keeps the VPS at 2 GB and costs nothing extra.
CPU and the thumbnail job spike
Importing a library is CPU-bound in a way that daily use is not. Generating thumbnails and transcoded video for tens of thousands of assets will run every core flat for hours. On a shared 2 vCPU budget plan that means sustained CPU steal and possibly a fair-use warning if the host watches burst usage. Expect a first import of 50,000 assets to take anywhere from six to twenty hours depending on core quality and whether transcoding is enabled.
Two practical mitigations: disable video transcoding during the initial import and enable it afterwards, and run the import in batches overnight rather than all at once. Once imported, steady-state CPU is under 10% of one core for a household-sized library, which is why a $6 plan can genuinely serve a family of four users.
Backups are the hidden third cost
Photo libraries are exactly the data you cannot afford to lose, and Immich’s own documentation is explicit that a database dump plus the original files is the only complete backup. Budget VPS plans at the $6 tier often ship snapshots but no off-site backup, so you need a second copy somewhere. Restic or Borg to object storage typically costs $3 to $6 per month for 250 GB with compression if your originals are already compressed.
Do not skip this line in the budget. A three-year total that ignores backups is a total that assumes you never need them, and one storage incident on a budget host is usually enough to change that assumption permanently. Price the backup in from day one and the cost model stays honest.
Where the budget VPS still wins
For libraries under roughly 200 GB, a single $10 to $15 plan with included off-site backup is simpler and often cheaper than assembling object storage, a CDN and a backup bucket. Above 300 GB, the split architecture wins on both cost and resilience, and the gap widens every year as the library grows. The crossover point is worth calculating once for your own library rather than assuming either answer.
The deciding factor is not the monthly price of the plan, it is what happens in year three when you need another 80 GB. A partition that requires migrating the whole server is a real cost; adding a bucket is not. Model the growth before you buy, and the budget option stops being the one with the smallest number on the homepage. When your library size is known, match your storage total against budget VPS disk tiers and price the third year, not the first month.

