Next-Generation Storage: NVMe-oF, Optane, and SSDs for Cloud Databases

From HDD to NVMe-oF: How Storage Evolved and Why Databases Are Looking at the Disk Again

When people talk about database performance, the focus almost automatically shifts to CPU and RAM. That makes sense: the processor does the computation, memory holds hot data, and cache speeds up reads. But every database eventually reaches the point where data must not simply be “kept close,” but actually written, read back, committed as transactions, and flushed to the WAL. And that is exactly where storage becomes critical again.

If you look at the history in brief, it is not really a museum of hardware, but an evolution of bottlenecks. With each generation, storage became faster, yet the nature of database problems changed along with it.

From HDD to SSD: When Mechanical Storage Became a Bottleneck for Databases

For a long time, everything relied on HDDs. That was often good enough for archives and sequential workloads, but databases quickly ran into limits with random reads and writes. This was especially painful in OLTP scenarios, where short operations and consistent response times matter most.

The shift to SSDs changed the picture dramatically. Over the past decade and a half, storage for enterprise workloads has effectively been rebuilt around flash. But together with the gains in latency and IOPS, it became clear that “SSD” is not a magic word, but an entire class of devices with very different behavior under load.

2011 and Beyond: NVMe Stopped Being Just “a Faster SSD”

The next major milestone was NVMe. For databases, its importance was not in the marketing label, but in a storage access model better suited to high-speed media, one that reduces unnecessary overhead between the application and the device.

Then the market arrived at a natural question: if local NVMe is that good, can similar performance be achieved without tying storage rigidly to a single server? That is where the story of NVMe-oF begins — an attempt to extend the advantages of NVMe beyond local PCIe and make high-speed storage more flexible and networked. This is especially interesting in the cloud, because it makes it possible to separate storage from compute without fully giving up a low-latency access model.

2015–2026: The Dream of Memory-Class Storage, the Lesson of Optane, and the New Reality

At the same time, the market was looking toward storage-class memory and ultra-low latency. The story of Optane showed very clearly that speed alone is not enough: even a strong technology does not automatically become a standard if scaling and operations around it remain difficult, and the price is far from attractive.

By 2025–2026, the conversation around next-generation storage is no longer shaped by the idea that one technology has defeated all the others. What matters much more is the combination of fast NVMe media, network disaggregation, and predictable behavior under load. And that is exactly where the whole history of storage development leads us: as CPU, memory, and networking became faster, storage once again turned into a problem — not in the old, obvious sense of “the disk is slow,” but in a more frustrating one. Storage now affects tail latency, write consistency, replication behavior, and the overall stability of a database under live production load.

What Fast Storage Is Made of Today: SSDs, NVMe, and Why the Label “NVMe” Is No Longer Enough

After that historical overview, it is tempting to reduce the conclusion to a comforting formula: HDDs are in the past, so from here on everything is simple — just pick NVMe and move on. In practice, however, storage for databases has long stopped being divided into “slow” and “fast.” For a database, the more important question is how predictably the storage behaves under live workload conditions.

That is why the label NVMe by itself guarantees very little. On paper, two options may both look like “fast NVMe,” yet in real operation the difference becomes obvious under writes, traffic spikes, compaction, or replication.

To avoid looking at storage too abstractly, it helps to break the picture down into a few simple layers:

The table above highlights the main point: for a database, it is not only the medium itself or the interface that matters, but also how the storage behaves under writes and peak load. That is usually where the real difference lies between something that looks fast on a product page and something that remains stable in production.

That is why storage for databases is best chosen not by a buzzword, but by the combination of several factors: solid media, an appropriate protocol, and predictable behavior under load. And this is exactly where the next step becomes especially interesting — what happens when NVMe is extended across the network, and why the cloud needed that in the first place.

NVMe-oF: Why Extend NVMe Across the Network, and Where It Actually Makes Sense

At this stage, storage starts to reveal a distinctly engineering-minded trick. Local NVMe is attractive because it is fast, close to the server, and easy to understand: the device sits right next to the host, latency is low, and the access path is short. But that same approach has a downside — it ties high-performance storage to a specific machine. And in the cloud, that kind of tight coupling is inconvenient.

That is exactly where the idea of NVMe-oF comes from. Put simply, it is an attempt to extend the benefits of NVMe beyond a single server — over the network, but without the heavy overhead traditionally associated with network storage. Storage stops being “a disk inside one particular box” and becomes a more flexible resource that can be attached through a fabric.

On paper, this looks almost ideal: fast storage combined with what the cloud values most — resource separation, flexibility, and the ability to scale compute and storage independently. But the moment NVMe stops being local, the network enters the picture. That means the question is no longer only about the quality of the media itself, but also about the stability of the fabric, the transport, jitter, and the system’s behavior under peak load.

This can be illustrated as follows:

In practice, NVMe-oF becomes especially interesting where local NVMe ties storage too rigidly to the server, while traditional network storage cannot deliver the required performance. In those cases, it becomes a compromise between speed and flexibility.

But it is a compromise, not a universal replacement for everything. If a database is extremely sensitive to even small latency fluctuations, and the network between nodes does not lead a particularly stable life, the additional network layer can consume part of the performance gain. In that kind of setup, the application feels not only the storage medium itself, but the entire path leading to it.

This matters even more for cloud databases, because storage there almost always exists alongside replication, failover, migrations, and the constant need for operational manageability. That is why the next step is to look beyond the idea of a “fast disk” and focus instead on how the entire design behaves in terms of latency, and how predictably it performs under real production load.

Why Cloud Databases Need More Than IOPS: Tail Latency, Network Effects, and Predictability

When the conversation turns to storage for databases, it is very easy to get carried away by attractive numbers. A device delivers so many IOPS, so many gigabytes per second, and it starts to feel as though that alone should be enough to choose a winner. But for a cloud database, the problem almost never sounds like “we ran out of abstract speed.” Much more often, it sounds like this: everything looked fine, and then, at the worst possible moment, the system started behaving unevenly.

That is exactly where tail latency enters the picture. A database is rarely harmed by average latency alone. What hurts it are those rare but unpleasant tail events — the moments when a portion of operations suddenly starts taking noticeably longer than usual. From the application’s point of view, this feels like jitter, lag, and spikes in response time that distort the entire user experience.

This is especially painful in the cloud. There, storage does not live inside a sterile box. It exists alongside the network, replication, neighboring services, and background activity. As a result, the database is no longer feeling just the disk — it is feeling an entire chain of conditions that determine how it actually behaves.

Several factors matter most here:

• What matters is not peak speed by itself, but how steadily the storage sustains load
  
• IOPS mean very little without understanding how the device behaves under writes, flushes, and mixed workloads
  
• If storage is disaggregated or depends on remote components, the network begins to affect the database no less than the medium itself
  

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure



Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans



Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus



Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster


• Average latency is reassuring only on paper; real problems tend to arrive through tail spikes
  
• For long-term operation, what matters is not one-time “fastness,” but predictability under live workload

Consider a typical situation. On average, everything looks respectable: the metrics are clean, the disk is fast, replication is progressing, and reads are responsive. But under a write spike, a checkpoint, or intense background activity, the storage suddenly starts responding not in 1–2 milliseconds, but in something noticeably worse. For monitoring, this may appear as a “rare event.” For the application, it is already a story of sudden slowdowns and unstable transactions.

That is why, for cloud databases, predictability is often more valuable than an impressive peak number. A device that delivers a less spectacular top-end result but behaves steadily and calmly is often more useful than storage that looks brilliant in a benchmark and then starts to lose composure under real mixed production load.

The network adds its own personality to the problem. If storage, replication, or data paths depend on remote components, any instability starts affecting the database not directly through the disk, but through the entire route leading to it. In that case, the problem no longer looks like “we do not have enough IOPS.” It becomes a more frustrating story: sometimes the system responds quickly, sometimes slowly, with no obvious logic from the end user’s perspective.

That is why, when evaluating storage for cloud databases, it is better to think not in terms of “which device is faster on paper,” but in terms of a more practical question: how steadily and predictably will this entire design behave under our actual workload?

How to Choose in Practice: Media Type, Replication, Durability, Cost, and Workload Profile

In practice, choosing storage for a cloud database almost never starts with the question, “Which disk is the fastest?” A far more useful starting point is to understand your workload profile and identify what will be most painful for the database in reality: writes, reads, mixed I/O, traffic spikes, background operations, or sensitivity to transaction commit latency.

In most cases, the choice comes down to validating five things:

• Which type of media best fits the nature of the workload
  
• How the database behaves under writes and mixed I/O
  
• How replication and write acknowledgment are designed
  
• What the architecture will cost not only at launch, but in long-term operation
  
• How predictably it handles real peaks and failure scenarios

That is exactly why storage cannot be chosen based on one attractive specification alone. The same NVMe device may look excellent in a short benchmark and behave very differently under live workload conditions. And fast local writes do not automatically mean a resilient architecture if replication, durability, and the network path around the database are too fragile.

At its core, a good storage choice is always a compromise. Not between “fast” and “slow,” but between performance, predictability, resilience, and cost. And if that compromise is chosen for the real database rather than for a benchmark or a polished slide deck, then the storage is already serving the system — instead of the system being forced to adapt to the storage’s quirks.

Conclusion

For a cloud database, storage has long since stopped being just “a disk that holds data.” It affects latency, write stability, behavior under peak load, replication, and, ultimately, how predictably the database will operate in production at all. That is why looking only at the NVMe label, impressive IOPS figures, or the name of a well-known technology is no longer enough.

If you truly need a database that behaves consistently, do not start with the marketing. Start by examining your actual workload. Look at where the system is struggling today: writes, tail latency, the network, replication, or storage behavior under mixed I/O. Only then should you choose the design that can withstand that reality rather than a laboratory benchmark. That is exactly the kind of approach that separates sound infrastructure from something expensive, yet perpetually fragile.