NVMe vs. SSD vs. HDD für Hosting-Workloads
Aktualisiert May 9, 2026X-ZoneServers Wissen
Die Wahl des Speichers im Hosting beeinflusst die für Nutzer sichtbare Performance stärker als nahezu jede andere Spezifikation. NVMe-SSDs, SATA-SSDs und drehende Festplatten unterscheiden sich auf den für Datenbanken und dynamische Workloads wichtigsten Kennzahlen – IOPS und Latenz – um den Faktor 100–1000, jedoch nur um den Faktor 5–10 in den reinen Kosten pro Gigabyte. Dieser Leitfaden analysiert die zugrunde liegende Technologie, liefert realistische IOPS- und Latenzwerte und zeigt, wo jede Speicherstufe 2026 ihren Platz findet.
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)
Die Auslieferung statischer Inhalte, Video-Streaming, kalte Backup-Speicherung, Log-Archivierung und die Batch-Verarbeitung großer Dateien profitieren kaum spürbar von NVMe, weil sie sequenziell und bandbreiten- statt IOPS-gebunden sind. Eine 7.200-RPM-HDD oder sogar ein Hammer-SMR-Laufwerk mit 250 MB/s sequenziell reicht völlig aus – und ist pro Terabyte 5–10× günstiger.
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.
Fragen
Häufig gestellte Fragen
Ist NVMe immer schneller als SATA-SSD?
Bei Random-I/O mit nennenswerter Queue-Tiefe ja – NVMe ist 5–15× schneller bei IOPS und 5–10× niedriger bei Latenz. Für rein sequenzielle Single-Threaded-Reads großer Dateien verringert sich der Abstand, weil SATA mit 6 Gbit/s die physische Plattenrate bereits ausreizen kann; in diesem speziellen Zugriffsmuster fühlen sich beide ähnlich an.
Was ist DWPD?
DWPD steht für „Drive Writes Per Day“ – wie viel der vollen Laufwerkskapazität täglich über die Garantieperiode (meist 5 Jahre) überschrieben werden darf, ohne die Endurance zu überschreiten. Ein 1-TB-Laufwerk mit 1 DWPD ist auf 1 TB Schreibvorgänge pro Tag bzw. 1,825 PB insgesamt ausgelegt. Datenbank- und CI/CD-Workloads können Consumer-DWPD-Werte innerhalb weniger Monate überschreiten.
Sollte ich ZFS oder ext4 mit NVMe verwenden?
Beide funktionieren. ZFS ergänzt Checksumming, Snapshots und Komprimierung mit geringen CPU-Kosten; auf NVMe wird der CPU-Aufwand sichtbarer als auf langsamerem Speicher. ext4 ist die Standardwahl mit dem geringsten Overhead für rohe IOPS-Performance. XFS ist ein guter Mittelweg für Workloads mit großen Dateien. Wählen Sie nach Funktionen, nicht Performance – alle drei sättigen modernes NVMe.
Hilft NVMe speziell bei PostgreSQL?
Deutlich. Postgres-Write-Ahead-Log (WAL)-Flushes sind latenzempfindlich und profitieren von NVMes 10–50-µs-fsync gegenüber SATAs ≈ 100 µs. Index-Scans über große Tabellen profitieren ebenfalls von Random-Read-IOPS. Echte Postgres-Workloads laufen auf NVMe typischerweise 2–5× schneller als auf SATA-SSDs.
Was ist mit NVMe-over-Fabrics?
NVMe-oF erlaubt es, entfernte NVMe-Laufwerke über RDMA, TCP oder Fibre Channel als lokal erscheinen zu lassen. Es ermöglicht das Teilen leistungsstarker NVMe-Pools über mehrere Hosts mit nahezu lokaler Latenz (unter 100 µs zusätzlich). In Enterprise-Storage-Arrays und zunehmend in Hyperscaler-Clouds ist es üblich, im Standard-Hosting wegen Netzwerk- und Komplexitätskosten seltener.
Sind Consumer-NVMe-Laufwerke jemals akzeptabel im Hosting?
Bei dedizierten Single-Tenant-Servern mit leichten Workloads und gut getesteten Backups manchmal ja – mit signifikanter Kostenersparnis. Für geteiltes VPS-Hosting, Multi-Mandanten-Umgebungen oder jede Workload mit anhaltenden Schreibvorgängen ist Enterprise-NVMe mit PLP und höherem DWPD die einzige sichere Wahl.