For a Plex server, non-ECC risk is negligible.
Very low — close to zero for a typical Plex workload. I wouldn’t worry about it.
ECC RAM prevents single-bit memory errors (bit flips). Those are rare on modern consumer hardware — maybe one uncorrectable error every few years per system. And your use case matters.
Plex streams media files. It reads them, decodes them, and sends them to clients. It rarely modifies the files themselves (only metadata and watch status, which are tiny and often journaled). If a bit flips during a stream, you might see a one-frame artefact or a brief audio hiccup. That’s not data corruption; it’s a minor playback glitch. Nobody notices.
Real data corruption comes from writing bad data to disk — say, a photo library where a flipped bit silently writes garbage to your originals. For a read-heavy media server with only occasional writes (library scans, metadata), the risk is essentially theoretical.
If you were running a database, a filesystem like ZFS that verifies checksums on every read, or a render farm doing 24‑hour renders, I’d say spring for ECC. For Plex? Not worth the extra cost. You’ll lose more sleep over your hard drives failing.
