NVMe appears in every hosting comparison and is almost never explained, which is how it ended up meaning "fast" in the same vague way "premium hardware" does. It is not a faster server. It is a storage protocol with roughly a tenth of the per-request latency of a SATA SSD and a queue design built for parallelism, and it matters exactly as much as your workload touches the disk. For a CPU-bound shooter that is close to zero. For a database committing transactions, or a large world writing a save every ten minutes, or a 40 GB backup archive, it is the difference between a hitch nobody notices and one that costs you players. This post is about telling those cases apart.
What NVMe actually is#
The confusion comes from comparing the wrong things. NVMe is not a type of flash memory; the chips in an NVMe drive and a SATA SSD are the same kind of thing. What differs is how the computer talks to them.
A SATA SSD speaks AHCI, a protocol designed in 2004 for mechanical disks. AHCI has one command queue, 32 commands deep, and assumes the expensive part of a request is moving a physical arm. A SATA III link tops out around 550 MB/s in practice.
NVMe was designed for flash and sits directly on PCIe. It supports up to 65,535 queues of 65,536 commands each, which sounds absurd until you remember that flash is internally parallel across dozens of chips and AHCI could never keep them all busy. A PCIe 3.0 x4 drive does roughly 3,500 MB/s; a PCIe 4.0 x4 drive roughly 7,000 MB/s.
| 7,200 rpm HDD | SATA SSD | NVMe (PCIe 3.0) | |
|---|---|---|---|
| Sequential read | 150-200 MB/s | ~550 MB/s | ~3,500 MB/s |
| 4K random read IOPS | 100-200 | 80,000-100,000 | 300,000-1,000,000 |
| Typical request latency | 5-10 ms | 100-200 us | 20-100 us |
| Queue depth | 1 | 32 | effectively unlimited |
The throughput row is the one marketing quotes and the one that matters least. Almost nothing a game server does is a 3 GB sequential read. The rows that matter are the last two: how long one small request takes, and how many can be in flight at once. That is where the order-of-magnitude difference lives, and it is why a workload made of thousands of small reads and writes - which is what a world save and a database commit both are - behaves completely differently.
Storage is also not just the drive. RE:NODE runs NVMe throughout, on a ZFS pool, and a filesystem like ZFS adds its own behaviour on top: every block is checksummed so silent corruption is detected rather than served, writes are copy-on-write so a power loss leaves a consistent filesystem rather than a half-written one, and a read cache in RAM means a hot working set often never reaches the drive at all. The drive sets the floor; the filesystem decides how often you hit it.
Where a game server touches the disk#
More places than people expect, and in bursts rather than continuously.
The disk work on a game server falls into seven jobs, and they have very different profiles:
- World saves. Periodic, and usually at least partly on the main thread. Minecraft writes changed chunks into region files (
region/r.0.0.mca, each holding a 32x32 block of chunks); Valheim writes one.dbfile for the entire world; Palworld and the Unreal survival games write large save blobs. A big world save is thousands of small writes or one enormous one, and either is disk-bound. - Chunk and zone loading. A player walking into unexplored territory reads from disk, or generates and then writes. This is the one that produces a stutter as somebody flies across the map.
- Logs. Continuous, small, append-only. Cheap, until a plugin logs every block placement.
- Plugin and mod databases. EssentialsX user files, CoreProtect's block log, a SQLite file being hammered by every action on the server. This is quietly the heaviest disk workload on many Minecraft servers.
- Startup. Reading the jar or the game binaries, the mod list, the plugins, and the spawn chunks. A modded server reads several gigabytes before it accepts a connection.
- Backups. Reading the entire world and writing a compressed archive. Almost pure disk.
- Updates and Workshop downloads. Large sequential writes, plus verification reads.
Where NVMe shows, in order#
| Operation | What it is | What NVMe changes |
|---|---|---|
| Periodic world save | Thousands of small writes | The freeze gets shorter, sometimes invisible |
| Backup and restore | Read everything, write an archive | Minutes become a fraction of that |
| Server start | Large sequential and random reads | Noticeably faster on modded servers |
| Chunk load on exploration | Small random reads | Fewer stutters as players move |
| Database commit | fsync per transaction | The biggest single difference of all |
| Plugin SQLite writes | Constant small synchronous writes | Removes a common hidden tick cost |
| Log writes | Small appends | Nothing you would notice |
The save case deserves the detail because it is the one players actually feel. Most games serialise the world and write it while the simulation waits. On a world that has grown to tens of gigabytes, that write is the longest single block of the tick loop, and it happens on a timer, forever. Valheim is the clean example: the whole world is one file, written every -saveinterval seconds, and on a mature world the pause is measurable. Shortening the interval reduces how much you can lose in a crash and increases how often you pay the pause, and fast storage is what makes that trade cheap. The Valheim guide works through the save settings.
Backups are the other honest win, and they are nearly pure disk. A nightly job that reads a 30 GB world and writes a compressed archive is doing exactly the work storage is rated for. On slow disks that job overlaps with the evening, competes with the game, and turns into the mystery lag everybody blames on the host. On NVMe it finishes before anyone notices. It also changes the number that actually matters in an emergency, which is not how long the backup took but how long the restore takes - see backups that actually restore and testing a restore before you need it.
Where it makes no difference at all#
This is the part hosting pages leave out.
Tick rate on a CPU-bound server. If the simulation cannot finish a step in its budget because there is too much to simulate, the disk was never involved. Faster storage changes nothing, and the money would have been better spent on clock speed. CPU or RAM is the triage for working out which you have.
Network latency. A player at 180 ms is 180 ms from the server. Storage has no opinion about this.
Anything already in memory. The active world, the entity list, the plugin state, the JVM heap: none of it touches the disk between saves. A server with enough memory to hold its working set reads from disk rarely, which is precisely why adding memory sometimes fixes what looks like a storage problem.
Steady-state performance of a small server. A Counter-Strike server on a static map reads the map once and then does essentially no disk I/O for the rest of the night. The storage on that plan is a place to keep files.
Bad configuration. A plugin doing a synchronous database query on the main thread every tick is slow on NVMe too. It is just slow slightly faster.
Databases are where it genuinely dominates#
If you run a database - a Postgres or MongoDB instance, a FiveM server with a real backing store, a Minecraft economy plugin with thousands of transactions - storage latency sets a hard ceiling on throughput, and the arithmetic is unforgiving.
A durable database calls fsync before it acknowledges a commit, because a commit that is only in the page cache is a promise it cannot keep through a power loss. That fsync is a synchronous round trip to the device, and one connection cannot commit faster than one fsync at a time:
max commits per second, per connection = 1 / fsync latencyHDD, 8 ms fsync -> 125 commits/sSATA, 1 ms fsync -> 1,000 commits/sNVMe, 50 us fsync -> 20,000 commits/sThose are ceilings, not predictions, and real systems batch commits from multiple connections to do better. But the shape is why a write-heavy application on slow storage hits a wall that no amount of query tuning removes, and why the same application on NVMe simply does not notice. PostgreSQL tuning for small servers covers the settings that interact with this, and explain analyze for slow queries covers the other half, which is the queries themselves.
Read performance matters differently. A query that finds its data in the cache never touches the disk at all - which is why shared_buffers and the operating system's page cache get tuned first. NVMe changes what happens on a cache miss, and on a working set larger than memory that is most of the time. Database hosting plans are sized with that in mind, but the general rule holds anywhere: memory removes reads, fast storage makes the reads you cannot remove cheap.
Measuring it yourself#
Do not trust a specification sheet, and specifically do not trust dd.
# Misleading: writes through the page cache, measures RAM$ dd if=/dev/zero of=test bs=1M count=1024# Better, but still only sequential throughput$ dd if=/dev/zero of=test bs=1M count=1024 oflag=direct conv=fdatasyncSequential throughput is the least relevant number. What you want is small random I/O latency and IOPS:
$ fio --name=randread --ioengine=libaio --direct=1 --rw=randread \ --bs=4k --iodepth=32 --numjobs=1 --size=1G --runtime=30 \ --time_based --group_reporting$ fio --name=syncwrite --ioengine=sync --fsync=1 --rw=write \ --bs=4k --size=256M --runtime=30 --time_basedThe first gives random read IOPS and a latency distribution. The second is the fsync test, and it is the one that predicts database behaviour. Read the 99th percentile latency, not the average - the average tells you how it usually feels and the tail tells you what the freeze looks like.
For a quick check with nothing installed, ioping -c 20 . prints per-request latency in the current directory. For watching a live server:
$ iostat -xz 1Look at r_await and w_await - average milliseconds a request waited - and aqu-sz, the average queue depth. Ignore %util on an NVMe device; it was designed for single-queue disks and reports 100% on a drive that is barely working, because it measures whether any request was in flight rather than whether the device is saturated. A high %util with a w_await of 0.1 ms is a healthy NVMe drive, not a bottleneck.
On a panel-based host you will not have fio, and the useful substitute is the disk graph next to the memory and CPU graphs. A sawtooth on the disk graph that lines up exactly with the hitches players report is your answer, and reading a server load graph covers the shapes.
Disk space is a separate question from disk speed#
Plans state a disk size and everyone reads it as a storage allowance, which it is, but the number interacts with performance in two ways worth knowing.
Running near full is slow. Flash needs free blocks to write into, and a nearly full drive spends time shuffling data to make room. Filesystems that are copy-on-write, ZFS included, need free space to work efficiently. Keeping usage below about 80% is a performance setting, not just tidiness.
Backups live in the same space unless they do not. A game's built-in backup feature writes beside the world, which means a 30 GB world with four retained backups needs 150 GB and protects against exactly one failure mode: a corrupt save. It does nothing about a deleted server or a bad restore. Platform backups on RE:NODE are copied to separate hardware, verified and pruned on a schedule, and the panel's own backup slots are stored off the machine they protect - which is the property that makes a backup a backup rather than a second copy of a file on the same disk.
Sizing advice that follows from both: pick disk size from the world you expect in a year plus room for archives, not from what the world is today. Worlds only grow, and pre-generating a bounded world is the one technique that makes the growth predictable.
FAQ#
Is NVMe worth paying extra for?
If it is a line item, look at your workload first. It is worth it for databases, for large worlds that save often, and for anything doing frequent backups. It is not worth a premium for a small shooter server or a Discord bot, which barely touch the disk after starting. On RE:NODE it is not a line item; every plan is NVMe, including the cheapest, because the alternative is a false economy on hardware that is a small part of the cost.
Will NVMe fix my server lag?
Only if the lag is periodic and lines up with saves, backups or player exploration. Lag that is constant, that gets worse with more entities, and that shows as high tick time with a calm disk graph is a CPU problem, and storage will not touch it.
Does NVMe make my server start faster?
Yes, noticeably, on anything with a large world or a long mod list - that startup is mostly reading files. A vanilla server with a small world starts in a few seconds on anything, so the difference is invisible there.
What is the difference between NVMe and SSD?
An SSD is flash storage; NVMe is a protocol for talking to it over PCIe. Most "SSD" in hosting copy means a SATA SSD using AHCI, which is a 2004 protocol with one shallow queue. Same chips, very different latency and parallelism.
Do I need NVMe for a Minecraft server?
It helps more than people expect, because Minecraft's disk work is small random reads and writes: chunk loading as players explore, region files on save, and plugin databases like CoreProtect writing constantly. None of that is throughput and all of it is latency, which is the thing NVMe changes.
Can slow storage cause low TPS?
Yes, indirectly and intermittently. A save or a synchronous plugin write that blocks the main thread spends tick budget, which shows as a huge maximum tick time with a normal average. That pattern is a storage problem masquerading as a CPU one, and what tick rate actually means covers how to read the difference.
Comments
Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.