RAM is one of the easiest specs to either badly underbuy or badly overbuy in a homelab, because the honest answer to “how much do I need” is “it depends on what you’re actually running,” and most buying guides dodge that and just tell you to get 32GB or 64GB and move on. That’s not wrong exactly, but it skips the reasoning that lets you size correctly for your own setup instead of someone else’s. Here’s how to actually work it out, plus the ECC question that comes up right behind it.

Start from what’s actually running, not a round number

The right way to size RAM is to add up what your real workloads need, then leave headroom, not to pick a number that sounds generous.

Proxmox itself. The hypervisor host needs some memory for itself before anything else runs, budget 2-4GB for the host OS and Proxmox’s own services. This isn’t a place to skimp, a starved host makes everything on top of it flaky, not just slow.

VMs. A full VM needs its RAM allocation reserved up front in most default configurations (ballooning can share unused memory back to the host, but plan capacity as if it’s dedicated, ballooning is a safety margin, not a sizing strategy). A lightweight Linux VM running one or two services can live in 2-4GB. A Windows VM, or anything running a heavier stack like a full monitoring suite or a database with a real working set, wants 8GB or more before it stops feeling cramped.

LXC containers. This is where Proxmox homelabbers actually save the most RAM versus an all-VM setup, because containers share the host kernel and only pay for their own process memory, not a whole guest OS. A Gitea instance, an Uptime Kuma, a Pi-hole, each of these comfortably runs in 512MB-1GB. This is the reason the LXC-vs-VM decision on this site matters as much for RAM budgeting as it does for isolation, favoring containers where isolation requirements allow it is a direct way to fit more services into less memory.

The workloads that actually move the number. A few specific things are the real RAM hogs in a typical homelab, and they’re worth budgeting for by name instead of folding into a generic “services” line:

  • ZFS ARC. If you’re running ZFS (see the ZFS pool layout guide on this site), it wants to cache aggressively in RAM by default, up to half of total system RAM unless you cap it. This isn’t a leak, it’s ZFS doing its job, but it means a ZFS-heavy box needs meaningfully more RAM headroom than the same box without ZFS, or an explicit zfs_arc_max cap if RAM is tight.
  • Media server transcoding and libraries. Plex and Jellyfin themselves aren’t heavy on RAM (the GPU or CPU does the actual transcode work, see the GPU guide on this site), but a large library with metadata scanning active can use more than people expect during a rescan.
  • Any local AI/LLM work. If Ollama or similar is in the picture, that’s a different sizing conversation entirely, model weights alone can eat 8-40GB+ depending on model size, and that’s before considering whether it fits in system RAM versus GPU VRAM at all.
  • Databases with a real dataset. Anything Postgres or MySQL-backed with actual data volume, Paperless-ngx, Immich, a self-hosted analytics stack, wants enough RAM that its working set doesn’t constantly hit disk.

Add it up, then add headroom. Sum your real workloads, add the host’s own 2-4GB, and then add 20-30% on top rather than running right at the edge. A homelab that’s pinned at 95% RAM utilization on a normal day has no room for the one VM that needs to boot for maintenance, or the container that leaks memory for a week before you notice.

Where that lands in practice

For most homelabbers running a handful of LXCs plus two or three VMs, in the Pi-hole, Gitea, Uptime Kuma, one media server, one or two general-purpose VM range, 32GB is a comfortable, not tight, number. That’s the sweet spot referenced in the mini-PC-vs-custom-build piece on this site for a reason, it’s enough to run a real service stack without constantly watching the meter, without paying for capacity you’ll never touch.

64GB earns its keep once ZFS is doing real work with a meaningful ARC budget, once there’s a local AI workload in the mix, or once the VM count grows past what a lean container-first setup would need. This is also roughly where a used enterprise platform (see the buying-used-enterprise-gear piece on this site) starts to look attractive purely on RAM economics, used server-grade DDR4 in bulk is often cheaper per gigabyte than buying a matched consumer kit at the same capacity.

Beyond 64GB is workload-specific territory, not a default. Don’t buy 128GB because it’s available cheap on the used market unless you can point at the specific VM, container, or ARC budget that’s actually going to use it. Idle RAM isn’t doing anything for you, and more RAM sitting empty doesn’t make anything else in the homelab faster.

Is ECC actually worth it for a homelab

ECC (error-correcting code) memory detects and corrects single-bit memory errors on the fly instead of letting them silently corrupt data or crash a process. The honest answer on whether it’s worth chasing splits pretty cleanly by what’s actually at stake on the box.

Where ECC earns its cost. Anything running ZFS benefits from ECC more than most workloads, because ZFS’s whole value proposition is data integrity, checksumming and catching corruption that other filesystems miss (see the bit-rot and checksumming article on this site for the full case). ZFS doesn’t require ECC to function, it will run fine on non-ECC RAM, but a bit flip in RAM before data is written and checksummed can still get written and checksummed wrong, meaning ZFS faithfully protects data that was already corrupted in memory. If the whole point of your NAS or storage box is protecting data you actually care about, pairing that with ECC closes a gap ZFS alone doesn’t cover. The same logic applies to anything running a database you’d be upset to see subtly corrupted.

Where it’s not worth chasing. A general-purpose Proxmox box running Pi-hole, a reverse proxy, a monitoring stack, and a couple of low-stakes VMs isn’t protecting anything that a rare bit flip would meaningfully hurt, and most of those services would just restart cleanly if something did go wrong. Consumer platforms also make ECC an awkward add-on rather than a clean choice, it typically requires both a CPU that supports it (many AMD consumer chips do at the silicon level even if motherboard vendors don’t always expose it cleanly; most Intel consumer chips explicitly don’t) and a motherboard chipset that actually enables it, so chasing ECC on a consumer build often means chasing a specific, sometimes obscure, CPU/board combination rather than just checking a box in a spec sheet.

The practical path. If ECC matters for your use case, a used enterprise platform (server-grade Xeon or EPYC, the same category covered in the buying-used-enterprise-gear piece) makes ECC support a given rather than a hunt, since it’s standard on that hardware class. If you’re on a consumer mini PC or desktop build instead, verify ECC support explicitly before assuming it, check both CPU and board, don’t buy ECC RAM speculatively for a platform that won’t actually run it in ECC mode.

Bottom line

Size RAM from your actual workload list, not a round number, and pay particular attention to ZFS ARC, any AI workload, and database working sets, since those are what actually move the total. 32GB comfortably covers a typical container-and-VM homelab, 64GB is where ZFS-heavy or AI-adjacent setups start to make sense. ECC is worth seeking out specifically when you’re protecting real data on a ZFS box or database server, and easiest to get by pairing it with used enterprise hardware rather than hunting for a consumer platform that happens to support it.