Zugrunde liegende Technologie: Warum die Lücke so groß ist
HDDs speichern Bits magnetisch auf rotierenden Platten und benötigen physische Kopfbewegung von 3–15 ms pro Random-Read. SATA-SSDs verwenden Flash-Speicher, der in Mikrosekunden erreichbar ist, kommunizieren aber über das alte AHCI/SATA-Protokoll, das für rotierende Datenträger entworfen wurde. NVMe-SSDs nutzen denselben Flash, sprechen aber über PCIe mit einem von Grund auf für parallelen, latenzarmen Zugriff entwickelten Protokoll – und der Unterschied zeigt sich überall.
Eine 7.200-RPM-HDD hat im Mittel 8,3 ms Rotationslatenz plus 3–12 ms Seek-Zeit, was eine Random-Read-Latenz von etwa 5–15 ms ergibt. Eine SATA-SSD eliminiert beides durch elektronischen Flash und senkt die Latenz auf rund 100 Mikrosekunden (50–100× schneller), wird aber durch das SATA/AHCI-Protokoll mit einer einzigen Befehlswarteschlange und 32 ausstehenden I/Os gebremst. NVMe (Non-Volatile Memory Express, 2011 standardisiert) wurde speziell für Flash entworfen: PCIe-Transport (kein SATA-Controller im Pfad), 64K-Befehlswarteschlangen mit je 64K-Befehlen (gegenüber 32 bei AHCI) und ein verschlankter Befehlssatz. Ergebnis: End-to-End-NVMe-Latenz fällt auf 10–50 Mikrosekunden, Parallelität skaliert nahezu linear mit der Queue-Tiefe, und ein einzelnes NVMe-Laufwerk kann 1+ Million Random-IOPS erreichen, während eine SATA-SSD bei rund 100K endet. Die Lücke ist nicht „inkrementell besser“, sondern 10–100× auf jeder relevanten Kennzahl.
IOPS, Latenz und Durchsatz im Vergleich
Typische Werte 2026. HDD: 100–200 Random-IOPS, 5–15 ms Latenz, 200 MB/s sequenziell. SATA-SSD: 50K–100K Random-IOPS, ≈ 100 µs Latenz, 500–550 MB/s sequenziell. NVMe Gen 4 SSD: 500K–1M Random-IOPS, 10–50 µs Latenz, 5–7 GB/s sequenziell. NVMe Gen 5 SSD: 1,5M–2M IOPS, ≈ 10 µs Latenz, 12–14 GB/s sequenziell.
Diese Werte sind typische Einzelhandels- und Enterprise-Preisspannen 2026, keine absoluten Tiefst- oder Höchstwerte. Consumer-NVMe-Preise sind schneller gefallen als Enterprise-Preise; die Lücke zwischen Consumer-Gen-4-NVMe (≈ 70 EUR/TB) und langlebigem Enterprise-NVMe (≈ 150 EUR/TB) liegt heute überwiegend bei Endurance (DWPD – Drive Writes Per Day) und Power-Loss-Protection-Kondensatoren, weniger bei der reinen Performance. Für Hosting-Anbieter ist die relevante Wahl praktisch immer Enterprise-NVMe, weil Consumer-Laufwerken die anhaltende Schreibperformance und der PLP-Schutz für geteilte Workloads fehlen.
| Kennzahl | 7,2K-HDD | SATA-SSD | NVMe Gen 4 | NVMe Gen 5 |
|---|---|---|---|---|
| Random-Read-IOPS (4K) | 100–200 | ≈ 95K | 500K–1M | 1,5M–2M |
| Random-Write-IOPS (4K) | 100–200 | ≈ 85K | 300K–700K | 1M–1,4M |
| Lese-Latenz (typisch) | 5–15 ms | ≈ 100 µs | 10–50 µs | ≈ 10 µs |
| Sequenzielles Lesen | 150–250 MB/s | 500–550 MB/s | 5–7 GB/s | 12–14 GB/s |
| Schnittstelle | SATA 6 Gb/s | SATA 6 Gb/s | PCIe 4.0 x4 | PCIe 5.0 x4 |
| Optimale Queue-Tiefe | 1 | 32 | 65.536 | 65.536 |
| Kosten/TB 2026 (Enterprise) | ≈ 15–25 EUR | ≈ 80–120 EUR | ≈ 100–150 EUR | ≈ 150–220 EUR |
| Kosten/TB 2026 (Consumer) | ≈ 25–35 EUR | ≈ 50–70 EUR | ≈ 70–100 EUR | ≈ 120–180 EUR |
Wann NVMe wichtig ist
NVMe ist überall wichtig, wo Random-IOPS und Tail-Latenz die Performance dominieren: relationale Datenbanken, Key-Value-Stores, Suchindizes, Message-Queues, Container-Build-Farms, CI/CD-Pipelines und alle Workloads mit hoher Parallelität. Je schneller die Anwendung, desto stärker profitiert sie von NVMe – Engpässe verlagern sich von der Disk zur CPU.
Drei Workload-Kategorien profitieren deutlich von NVMe. Datenbank-Workloads – Postgres, MySQL, SQL Server – setzen viele parallele zufällige 4–16-KB-Reads auf Indizes ab; die Latenz übersetzt sich direkt in Abfragezeit. Eine typische OLTP-Workload erreicht auf SATA-SSD eine Wand bei rund 1 ms p95-Abfragelatenz; auf NVMe läuft dieselbe Workload mit p95 unter 200 µs. Container-Workloads – Docker, Kubernetes – führen tausende kleiner Reads während Image-Pulls und Layer-Extraktionen aus; NVMe verkürzt Cold-Starts um Faktor 5–10. CI/CD- und Build-Pipelines – bazel, gradle, npm install – sind stark random-IO-gebunden; der Wechsel von SATA auf NVMe halbiert die Build-Zeiten regelmäßig. Gemeinsamer Nenner: Jede Workload, in der viele kleine parallele Operationen anstehen, profitiert von NVMes Skalierung mit der Queue-Tiefe. Single-Threaded sequenzielle Workloads profitieren weniger, weil SATA-SSDs bereits ihre Schnittstelle ausreizen können.
Wann NVMe weniger wichtig ist (und HDD reicht)
Statische Inhalte, Video-Streaming, kalte Backup-Speicherung, Log-Archivierung und große Batch-Verarbeitungen mit großen Dateien profitieren kaum von NVMe, weil sie sequenziell und bandbreiten- statt IOPS-gebunden sind. Eine 7.200-RPM-HDD oder gar SMR-Drive mit 250 MB/s sequenziell reicht – und ist 5–10× günstiger pro TB.
Drei Workload-Muster nutzen kaum IOPS. Statische Inhalte werden in 100-KB- bis Mehrere-MB-Dateien sequenziell ausgeliefert; OS-Read-Ahead und Disk-Cache machen eine SATA-SSD oder gar HDD für Endnutzer nahezu so schnell wie NVMe (besonders mit vorgelagertem CDN). Video-Streaming läuft als lange sequenzielle Reads mit starker Page-Cache-Lokalität; selbst ein 10-Gbps-Stream mit 4K-Inhalt lässt sich problemlos aus einem 250-MB/s-HDD-Pool speisen. Kaltes Backup und Archivspeicher zählen Kosten/TB und Haltbarkeit, nicht Latenz – Backblaze, AWS Glacier und die meisten Enterprise-Backup-Ebenen nutzen weiterhin HDDs (oder Magnetbänder) für Petabyte-Archive mit seltenem Zugriff. Klären Sie, ob Ihre Workload IOPS- oder bandbreitengebunden ist, bevor Sie den NVMe-Aufpreis zahlen; bei sequenziellen Workloads im großen Maßstab gewinnen HDDs weiterhin pro Byte.
Kosten pro GB im Jahr 2026
Enterprise-Preise pro TB 2026 (typische Spannen): HDD ≈ 15–25 EUR, SATA-SSD ≈ 80–120 EUR, NVMe Gen 4 ≈ 100–150 EUR, NVMe Gen 5 ≈ 150–220 EUR. Die HDD-zu-SATA-Lücke ist enger geworden; die SATA-zu-NVMe-Lücke ist heute klein genug, dass die meisten neuen Hosting-Bereitstellungen standardmäßig auf NVMe setzen, mit HDDs für Backup- und Archivebenen.
Vor zwei Jahren war die SATA-zu-NVMe-Preislücke groß genug, dass mittlere VPS-Tarife noch SATA-SSDs als Standard hatten. Bis 2026 hat sich die Lücke bei Enterprise-SKUs auf etwa 20–30 % verringert; die Performance-Lücke (10× IOPS, 5× Latenz) macht die Rechnung einfach: 20 % mehr zahlen für 10× mehr Leistung. Praktisch jeder Standard-VPS-Anbieter liefert primären Speicher heute standardmäßig auf NVMe Gen 4. SATA-SSDs überleben überwiegend in Dedicated-Server-Plattformen mit mehr Drive-Bays, in denen 8–12 SATA-SSDs in RAID-10 ein anderes Kostenprofil als 2–4 NVMe-Laufwerke in Software-RAID liefern. HDDs dominieren weiterhin nur bei Backup-, Archiv- und Massenspeicher-Workloads, in denen Kosten pro TB wichtiger sind als IOPS. Für jede neue primäre Datenbankbereitstellung ist NVMe die einzig sinnvolle Standardwahl.
RAID, Redundanz und was im Datenblatt fehlt
Single-Drive-Performance ist nur die halbe Geschichte. NVMe-RAID erzeugt CPU-Overhead, sofern keine Hardware-NVMe-RAID-Karten genutzt werden (selten und teuer); Software-md-RAID-1-Mirrors sind üblich, RAID-5/6 weniger. Endurance (DWPD) und Power-Loss-Protection (PLP) sind so wichtig wie IOPS – Consumer-NVMe ohne PLP kann bei einem Host-Crash während dauerhafter Schreibvorgänge Daten verlieren.
Drei häufig fehlende Details. Erstens: Software-RAID-5/6 auf NVMe ist eher CPU- als disk-gebunden – bei 1+ Million IOPS kann die Paritätsberechnung mehrere Kerne sättigen. Die meisten produktiven NVMe-Setups setzen daher auf RAID-1-Mirrors und vertrauen für Haltbarkeit jenseits des Spiegels auf Backups. Zweitens: Drive-Endurance wird in DWPD (Drive Writes Per Day) über eine 5-Jahres-Garantieperiode angegeben; Consumer-NVMe liegt bei 0,3–0,5 DWPD, Mainstream-Enterprise bei 1–3 DWPD, schreibintensives Enterprise bei 10+ DWPD. Eine schreibintensive Datenbank-Workload kann ein Consumer-Laufwerk innerhalb von Monaten verschleißen. Drittens: Power-Loss-Protection – Bord-Kondensatoren, die in-flight-Schreibvorgänge bei Stromausfall in den Flash schreiben – ist auf Enterprise-Laufwerken Standard und auf den meisten Consumer-Laufwerken abwesend. Ohne PLP kann ein Host-Crash während eines fsync Daten beschädigen, obwohl die Anwendung alles richtig macht. Prüfen Sie diese drei Details immer, nicht nur IOPS.