Zum Hauptinhalt springen

HDD gegen NVMe 2026: Warum die richtige Skalierung wichtiger ist als der reine Preis

Matteo Keller
Storage ZFS TrueNAS Performance
Autor
Stylite AG
Spezialisten in ZFS storage solutions, security. Docker containerization for enterprise environments.
Inhaltsverzeichnis

Header-Bild

Wer 2026 einen neuen Storage plant, erlebt beim Blick auf die Preisliste eine unangenehme Überraschung: NVMe-SSDs sind innerhalb weniger Monate massiv teurer geworden. Was viele schon abgeschrieben hatten, wird dadurch plötzlich wieder interessant, nämlich die klassische, drehende Festplatte. Zeit für einen nüchternen Vergleich: Wo steht die HDD gegenüber NVMe wirklich? Und welche der beiden Technologien ist für welchen Zweck die richtige Wahl?

Unsere Kernthese vorweg: Die spannende Frage ist gar nicht „HDD oder NVMe?", sondern wie Sie den Storage richtig skalieren. Denn HDD und Flash skalieren auf völlig unterschiedlichen Achsen. Wer das versteht, trifft die richtige Entscheidung fast von selbst und spart dabei oft erhebliche Kosten.

Der Auslöser: Warum Flash gerade so teuer ist
#

Der Preissprung bei NVMe ist kein normaler Marktzyklus, sondern eine strukturelle Verschiebung. NAND-Flash, der rund 90 Prozent der Kosten einer SSD ausmacht, ist global knapp geworden. Der Grund: KI-Rechenzentren absorbieren einen Großteil der weltweiten Speicherchip-Produktion, und Hersteller wie Samsung, SK Hynix und Micron lenken ihre Kapazitäten in hochprofitablen HBM-Speicher für GPUs um. Statt neue Fabriken zu bauen, lassen sie die Knappheit lieber die Preise treiben.

Das Ergebnis in Zahlen: NVMe-SSDs haben sich je nach Segment um 100 bis 200 Prozent verteuert. Ein 2-TB-NVMe-Laufwerk, das 2024 noch bei 120 bis 150 Euro lag, wird inzwischen teils jenseits der 300-Euro-Marke gehandelt. Entspannung wird frühestens gegen Ende 2027 erwartet.

Und die HDD? Auch sie ist teurer geworden, aber bei Weitem nicht so dramatisch. Enterprise- bzw. Nearline-Festplatten sind seit September 2025 im Schnitt um rund 46 Prozent teurer geworden, einzelne Hochkapazitäts-Modelle sogar um über 60 Prozent. Trotzdem liegt der Preis pro Gigabyte weiterhin bei einem Bruchteil dessen, was Flash kostet. Der Kostenvorteil pro nutzbarem Terabyte gegenüber NVMe ist damit nicht nur intakt, er ist wieder deutlich größer geworden.

HDD und NVMe im direkten Vergleich
#

Bevor es um Skalierung geht, lohnt der nüchterne Blick auf die Eigenschaften beider Medien:

KriteriumHDD (drehende Platte)NVMe-SSD (Flash)
Kosten pro TBsehr niedrigaktuell sehr hoch
Kapazität pro Laufwerksehr hoch (bis >20 TB)mittel bis hoch, teuer
Sequenzieller Durchsatzgut (150–280 MB/s je Laufwerk)sehr hoch (mehrere GB/s)
Random-IOPSniedrig (~75–100 je Nearline-Laufwerk mit 7.200 U/min)sehr hoch (100.000+)
LatenzMillisekundenMikrosekunden
Leistungsdichteniedrig (viele Spindeln nötig)sehr hoch (wenig Bauraum)

Man sieht sofort: Es gibt kein „besseres" Medium, sondern zwei Werkzeuge mit gegensätzlichen Stärken. Die HDD gewinnt bei Kapazität und sequenziellem Durchsatz pro Euro, die NVMe-SSD bei Random-IOPS und Latenz. Genau diese Gegensätze bestimmen, wie man skaliert. Wer sich zunächst grundsätzlich über Speicherarchitekturen orientieren möchte, findet die Einordnung in NAS, SAN oder das, was Unternehmen über Speicherlösungen wissen sollten .

Die eigentliche Frage: richtige Skalierung
#

Storage skaliert nicht auf einer, sondern auf zwei völlig verschiedenen Achsen: Kapazität und Performance (IOPS/Latenz). Der häufigste und teuerste Planungsfehler ist, beide Achsen mit demselben Medium bedienen zu wollen.

HDDs skalieren Kapazität hervorragend, Performance nur über die Menge. Eine einzelne Platte liefert seit Jahren ungefähr gleich viele Random-IOPS, egal wie groß sie ist. Wer mehr zufällige Zugriffe braucht, muss also mehr Spindeln parallel arbeiten lassen, sprich mehr Laufwerke bzw. mehr vdevs. Kapazität lässt sich bei HDDs sehr günstig aufstocken; Random-Performance dagegen wird mit jeder zusätzlichen benötigten IOPS-Stufe überproportional teuer, weil man Platten kauft, deren Kapazität man gar nicht braucht.

NVMe skaliert Performance auf kleinstem Raum, Kapazität dagegen teuer. Ein einziges NVMe-Laufwerk liefert die IOPS eines ganzen HDD-Regals. Wer Latenz und hohe Zugriffsdichte braucht, bekommt das mit Flash auf minimaler Fläche. Umgekehrt wird reine Kapazität mit NVMe schnell unwirtschaftlich; Terabytes, die überwiegend ruhen, auf Flash zu legen, verbrennt Budget.

Die Skalierungsfrage lässt sich damit auf eine einzige, ehrliche Vorüberlegung eindampfen: Wie aktiv sind meine Daten?

Aktive Daten werden ständig und in kleinen, zufälligen Häppchen gelesen und geschrieben. Sie sind latenzkritisch: laufende Datenbanken, virtuelle Maschinen mit vielen parallelen Zugriffen, transaktionsintensive Anwendungen. Hier skaliert man über Performance, und das Mittel der Wahl ist NVMe.

Ruhende und selten genutzte Daten werden überwiegend sequenziell bewegt oder liegen die meiste Zeit einfach nur da: Backups, Archive, Dateiablagen, Mediendateien, Videoaufzeichnungen. Hier skaliert man über Kapazität, und das Mittel der Wahl ist die HDD.

Wer diese Trennung sauber vornimmt, dimensioniert nicht den gesamten Storage nach den Anforderungen der wenigen aktiven Daten und bezahlt eben nicht teuren Flash für Terabytes, die nur ruhen.

Cache-Beschleunigung: warum HDD-Systeme oft schneller sind, als man denkt
#

An dieser Stelle kommt ein Aspekt ins Spiel, der in der reinen HDD-gegen-NVMe-Rechnung gerne übersehen wird: Ein modernes Storage-System auf Basis von ZFS/TrueNAS setzt Flash und RAM gezielt als Beschleuniger vor die Platten. Das verschiebt die Grenze, ab der man „echtes" NVMe für die Kapazität braucht, deutlich nach oben. Die wichtigsten Begriffe kurz erklärt:

ARC (Adaptive Replacement Cache) ist der Lese-Cache im Arbeitsspeicher. ZFS hält hier die am häufigsten und zuletzt genutzten Blöcke vor und entscheidet intelligent, was drinbleibt. Der Effekt: Häufig gelesene Daten kommen gar nicht erst von der Platte, sondern in RAM-Geschwindigkeit aus dem Cache. Der schnellste Speicher ist der, den man nie anfassen muss, deshalb ist ausreichend RAM der wirkungsvollste und günstigste Performance-Hebel überhaupt. Wie der ARC im Detail arbeitet, ist in ZFS ARC: Der Lese-Cache im Arbeitsspeicher beschrieben.

L2ARC (Level-2 ARC) erweitert genau diesen Lese-Cache auf eine SSD. Reicht der RAM für den aktiven Datenbestand nicht aus, gibt es aber ein wiederkehrendes Zugriffsmuster, fängt eine vergleichsweise kleine NVMe die wiederkehrenden Lesezugriffe ab. Wichtig: L2ARC ersetzt keinen RAM und bringt nur dann etwas, wenn der ARC nachweislich zu klein ist. Andernfalls ist die Investition in mehr RAM sinnvoller.

SLOG (Separate Log Device) beschleunigt synchrone Schreibzugriffe. Bei Anwendungen, die auf die Bestätigung jedes Schreibvorgangs warten, typischerweise NFS-Datastores und Datenbanken, landet das ZFS Intent Log auf einem schnellen, langlebigen NVMe. Das senkt die Schreiblatenz spürbar, ohne dass der gesamte Pool aus Flash bestehen muss. Für rein sequenzielle oder asynchrone Lasten wie Backups bringt ein SLOG dagegen nichts; welche Geräte sich eignen und welche nicht, steht in den SLOG Best Practices .

Special vdev ist für viele der entscheidende Hebel: Metadaten und optional kleine Blöcke werden dauerhaft auf schnellen SSDs abgelegt, während die großen Nutzdaten auf HDDs bleiben. Das Auflisten von Millionen Dateien, das Durchsuchen tiefer Ordnerstrukturen, das Arbeiten mit vielen kleinen Files fühlt sich damit an wie Flash, obwohl die Kapazität von günstigen Platten kommt. Anders als ein Cache ist das Special vdev fester Bestandteil des Pools und muss deshalb zwingend redundant (gespiegelt) ausgelegt werden.

Die Botschaft ist wichtig für die Skalierung: Cache und Beschleuniger heben ein HDD-System weit über sein „nacktes" IOPS-Niveau, aber sie ersetzen kein NVMe, wenn Daten dauerhaft und in großem Umfang aktiv sind. Ein Cache hilft bei wiederkehrenden Mustern; bei durchgängig zufälliger Volllast läuft er ins Leere.

Wo die HDD völlig ausreicht
#

Konkrete Fälle aus der Praxis, in denen ein HDD-basierter Pool (in der Regel RAID-Z2), sinnvoll ergänzt um etwas Cache und ein Special vdev, absolut angemessen ist:

  • Der klassische Firmen-Fileserver: SMB-Freigaben, Projektordner, Office-Dokumente. Zugriff überwiegend sequenziell und gut cachebar.
  • Backup-Repository: Ob Veeam, Bacula oder ZFS-Replikation, Backups sind sequenzielle Schreiblast auf große Kapazität. Teurer Flash wäre hier verschwendetes Budget.
  • Archiv- und Compliance-Daten: Aufbewahren, selten anfassen. Hier zählt jeder Euro pro Terabyte.
  • Video- und Überwachungsspeicher: Kamerastreams sind hoher, aber sequenzieller Durchsatz, ideal für Platten.
  • Nextcloud und Dateisync: Für die typische Dokumentenablage im Mittelstand ist HDD plus Special vdev wirtschaftlich klar die bessere Wahl.

Wo Sie wirklich NVMe brauchen
#

Genauso ehrlich muss man die andere Seite benennen. Es gibt Workloads, bei denen die drehende Platte auch mit Cache nicht mehr mithält:

  • Große Hosting-Operationen: Viele Kunden, viele parallele VMs, garantierte Antwortzeiten. Das verlangt hohe, konsistente IOPS und niedrige Latenz, idealerweise NVMe-Mirrors.
  • Aktive Datenbanken: OLTP-Systeme mit vielen kleinen, zufälligen Schreibzugriffen sind der klassische Flash-Fall. Der Read-Modify-Write-Aufwand von RAID-Z auf HDDs würde hier zum Flaschenhals.
  • Virtualisierung mit hoher Zugriffsdichte: Dutzende oder Hunderte VMs auf einem Datastore erzeugen ein hochgradig zufälliges I/O-Muster. Hier führt an Flash kein Weg vorbei.
  • Latenzsensible Anwendungen: Überall dort, wo der Storage der limitierende Faktor für die Nutzererfahrung ist.

Die Empfehlung, nach Bedarf skaliert
#

Als grobe Orientierung, wie sich das übersetzt:

Fileserver, Backup, Archiv (überwiegend ruhende Daten): HDD-Pool im RAID-Z2, ergänzt um ein Special vdev (gespiegelt) für Metadaten sowie bei Bedarf L2ARC/SLOG. Skaliert günstig über Kapazität, sehr gutes Alltagsgefühl.

Gemischte Workloads (Fileserver plus etwas Virtualisierung): HDD-Kapazität als Basis, Flash gezielt als Beschleuniger davor. Der wirtschaftlichste Punkt für viele mittelständische Umgebungen.

Hosting, Datenbanken, dichte Virtualisierung (dauerhaft aktive Daten): All-Flash-Pool aus NVMe-Mirrors. Mirrors statt RAID-Z, weil sie die beste Random-IOPS-Performance und die niedrigste Latenz liefern. Skaliert über Performance, hier ist der höhere Preis pro Terabyte gerechtfertigt.

Wichtig, und das ist unsere Kernbotschaft: Die vdev-Struktur eines Pools ist nachträglich kaum änderbar. Umso wertvoller ist es, den Bedarf und die richtige Skalierungsachse vorab sauber zu analysieren, statt pauschal auf All-Flash oder pauschal auf HDD zu setzen. Welche Layout-Varianten es gibt und was sie kosten, zeigt der Beitrag zum ZFS Pool Layout .

Fazit: Nicht der Preis entscheidet, sondern die Skalierung
#

Der Flash-Preisschock von 2026 macht die HDD nicht zum Retro-Objekt. Er rückt nur wieder ins Bewusstsein, was gutes Storage-Design immer ausgezeichnet hat: Man skaliert die Achse, die man wirklich braucht. Kapazität kauft man günstig auf Platten; Performance kauft man dort, wo sie zählt, mit Flash. Wer aktive und ruhende Daten sauber trennt und Cache-Mechanismen richtig einsetzt, bekommt für die große Mehrheit der Anwendungen im Mittelstand die wirtschaftlich beste Lösung, nicht den Kompromiss.

Die einzige Voraussetzung: Sie müssen ehrlich beantworten, wie aktiv Ihre Daten wirklich sind. Genau da unterstützen wir Sie.


Nicht sicher, welches System zu Ihrem Bedarf passt?

Unser neuer TrueNAS Navigator hilft Ihnen, in wenigen Schritten das passende System für Ihren Anwendungsfall einzugrenzen, von der HDD-basierten Kapazitätslösung bis zum All-Flash-Performance-Pool. Für eine individuelle Dimensionierung und Skalierungsberatung stehen Ihnen die Storage-Experten der Stylite AG jederzeit zur Verfügung.

Stylite AG – Ihr TrueNAS Partner für professionelle Storage-Lösungen.


Quellen (Stand Juli 2026):


Matteo Keller ist im Marketing bei Stylite AG tätig und beschäftigt sich schwerpunktmäßig mit Enterprise-Storage-Lösungen und TrueNAS-Systemen.

Verwandte Artikel

TrueNAS Goldeye 25.10 – Einfachere Deployments und Terabit-Performance
Wim Bonis
Storage TrueNAS ZFS Performance Enterprise AI KI Virtualisierung
TrueNAS SCALE auf dem AOOSTAR WTR Max: Erste Schritte nach der Installation
Matteo Keller
Storage TrueNAS ZFS
TrueNAS SCALE Installation auf AOOSTAR WTR MAX – Schritt-für-Schritt Anleitung
Matteo Keller
Storage TrueNAS ZFS Hardware
Was ist ZFS eigentlich – und warum reden alle darüber?
Matteo Keller
Storage ZFS TrueNAS
TrueNAS 26 – Ransomware-Schutz, Hybrid-Pools und ein neues Versionsschema
Wim Bonis
Storage TrueNAS ZFS Security Open Source
ZFS Snapshots von Open-E JovianDSS per Pull replizieren
Wim Bonis
Storage ZFS Open Source Open-E TrueNAS
Hot Spares in ZFS: Warum ein Hot-Spare oft mehr Risiko als Nutzen bringt
Wim Bonis
Storage ZFS RAID Open-E TrueNAS
Sonderzeichen in Dateinamen: Probleme mit SMB, WebDAV und Nextcloud
Wim Bonis
Storage ZFS Tools Samba Linux TrueNAS
ZFS Snapshot-Replikation in TrueNAS SCALE: Remote Backup mit Push und Pull
Wim Bonis
Storage ZFS TrueNAS Backup Replikation