Die Frage klingt 2026 fast schon rhetorisch: Warum sollte man in einem neuen Server noch SATA-SSDs verbauen, wenn NVMe deutlich schneller ist? In der Praxis ist die Antwort weniger eindeutig, als der Marketing-Sprech der Hersteller vermuten lässt. NVMe ist nicht in jedem Slot die richtige Wahl, und SATA ist in bestimmten Rollen nicht schlechter, sondern schlicht wirtschaftlicher. Dieser Beitrag ordnet die vier Kriterien, an denen wir Kundenprojekte entscheiden — Latenz, IOPS-Größenordnung, Endurance (DWPD) und Preis pro Terabyte — und zeigt, wann sich der Aufpreis für NVMe technisch wie betriebswirtschaftlich rechnet.
Wir verzichten bewusst auf eigene Benchmark-Zahlen. Jede Umgebung, jede Firmware-Generation und jede Workload-Mischung erzeugt andere Werte. Statt vermeintlicher Absolutzahlen liefern wir Größenordnungen und Entscheidungsregeln, mit denen Sie in einer konkreten Situation eine belastbare Wahl treffen können.
Die technischen Grundlagen: warum NVMe schneller ist
SATA ist ein Speicherprotokoll aus der Zeit rotierender Festplatten. Es überlebt seit über zwanzig Jahren, weil es günstig, ausgereift und rückwärtskompatibel ist. Der Standard SATA 6G liefert im Bruttoprotokoll rund 6 Gbit/s pro Port, netto bleiben je nach Overhead etwa 550 bis 600 MByte/s sequenziell pro Laufwerk übrig. Das Protokoll transportiert SCSI-Kommandos und arbeitet mit einer Queue-Tiefe von 32.
NVMe wurde von Anfang an für Flash-Speicher entworfen. Das Protokoll setzt direkt auf PCIe auf und lässt den SCSI-Umweg weg. Statt einer Warteschlange von 32 unterstützt NVMe bis zu 65.536 Queues mit je 65.536 Kommandos. Für die Praxis bedeutet das: NVMe skaliert mit parallelen Zugriffen, während SATA an der eigenen Queue-Tiefe erstickt.
PCIe 4 vs. PCIe 5 vs. SATA 6G
Ein PCIe-4-x4-Slot liefert theoretisch rund 8 GByte/s pro Richtung, PCIe 5 x4 verdoppelt das auf rund 16 GByte/s. SATA 6G bleibt bei 0,6 GByte/s. Das ist ein Faktor von 13 bis 26 auf der reinen Bandbreite — und beim Random-Zugriff mit tiefer Queue oft ein noch deutlich größerer Unterschied.
Für sequenzielle Backups auf Rotationsmedium-Nachbau (also lineares Schreiben) reicht SATA weiterhin völlig aus. Für Datenbank-Workloads mit vielen parallelen kleinen Reads/Writes ist der Abstand zwischen SATA und NVMe nicht linear, sondern eine Größenordnung.
Latenz: der wichtigste Unterschied
Der spürbarste Unterschied im Alltag ist nicht die Bandbreite, sondern die Zugriffslatenz. Enterprise-SATA-SSDs liegen im typischen Read-Latenz-Bereich von etwa 60 bis 100 Mikrosekunden. Enterprise-NVMe erreicht 10 bis 20 Mikrosekunden, PCIe-5-Datacenter-Modelle teilweise deutlich darunter.
Das ist für viele Workloads egal — aber nicht für alle:
- VM-Boot-Storms (viele Windows-VMs starten gleichzeitig) profitieren spürbar von niedriger Latenz
- OLTP-Datenbanken mit vielen kleinen Transaktionen skalieren fast linear mit sinkender Commit-Latenz
- AI/ML-Pipelines, die Trainingsdaten aus einem Datenpool streamen, profitieren von Latenz + Bandbreite
- Fileserver-Workloads (SMB/NFS mit typischen Office-Dokumenten) sind so gut wie nie latenzlimitiert
Für den letzten Fall ist die nächstliegende Frage nicht “NVMe oder SATA”, sondern “Wie viele Spindeln oder SSDs habe ich in meinem Pool und wie ist der Cache konfiguriert”. Details dazu haben wir im Beitrag SSD-Lebensdauer verstehen: TRIM, Wear Leveling und SMART-Monitoring beschrieben.
IOPS-Größenordnungen: was heute wirklich zählt
IOPS-Angaben aus Herstellerdatenblättern sind Idealwerte, gemessen mit Queue-Tiefe 32 auf 4K-Blöcken, gerne im Read-Only-Fall. In der Praxis gilt: Für eine grobe Einordnung reicht die Größenordnung.
- Enterprise-SATA-SSD: typischerweise im Bereich 70.000 bis 100.000 Random-Read-IOPS, Write oft deutlich niedriger
- Enterprise-NVMe PCIe 4: typischerweise 800.000 bis 1.500.000 Read-IOPS, Write im hohen sechsstelligen Bereich
- Enterprise-NVMe PCIe 5: darüber, teilweise deutlich, aber CPU- und Firmware-limitiert
Der reale Nutzen: Ein einzelnes PCIe-4-NVMe-Laufwerk ersetzt IOPS-technisch problemlos ein SATA-SSD-RAID aus zehn oder mehr Laufwerken. Für VM-Hosts mit hoher Konsolidierungsdichte oder für Virtualisierungs-Cluster ist das nicht Luxus, sondern die Grundlage stabiler Antwortzeiten.
Wo SATA-IOPS reichen
Ehrlich betrachtet: für die meisten Standard-Workloads reichen SATA-IOPS problemlos. Ein RAIDZ2-Pool aus acht guten SATA-Enterprise-SSDs stemmt einen typischen KMU-Fileserver, ein mittelgroßes Backup-Repository oder einen Veeam-Landing-Pool ohne merklichen Engpass. Erst wenn viele parallele Random-Streams gleichzeitig zugreifen, wird die niedrige Queue-Tiefe zum Flaschenhals.
Endurance (DWPD): oft der wichtigere Wert
Für den Serverbetrieb ist die reine Geschwindigkeit oft nicht der Knackpunkt — sondern die Lebenserwartung unter Last. Der Standardwert dafür ist DWPD (Drive Writes Per Day) oder alternativ TBW (Total Bytes Written) über die Garantielaufzeit.
- Read-intensive Laufwerke (etwa 0,3 bis 1 DWPD): Fileserver, Backup-Targets, Content-Delivery
- Mixed-Use (etwa 1 bis 3 DWPD): Virtualisierung, allgemeine Serverworkloads
- Write-intensive (3 DWPD und mehr): Datenbanken, Log-Aggregation, ZFS-SLOG
Die entscheidende Erkenntnis: Der Formfaktor (SATA oder NVMe) sagt nichts über die Endurance aus. Es gibt Read-Intensive-NVMe mit 0,3 DWPD ebenso wie Write-Intensive-SATA mit 3 DWPD. Wer eine SATA-SSD für ein SLOG einbaut und dafür ein Consumer-Modell nimmt, hat das Problem nicht gelöst, sondern in eine andere Richtung verschoben.
Wenn Sie den Endurance-Bedarf grob abschätzen wollen: Der Beitrag SSD-TRIM, Wear Leveling und Lebensdauer führt durch die Rechnung, wie viel Schreiblast Ihre Workload tatsächlich erzeugt.
Preisrahmen 2026: warum SATA nicht tot ist
Ein pauschaler Euro-Preis pro Terabyte veraltet in der SSD-Welt binnen Wochen — der Markt schwankt spürbar mit NAND-Zyklen, Währungskursen und Kapazitätsklassen. Wir verzichten daher auf feste Zahlen und beschreiben nur die relative Positionierung:
- Enterprise-SATA-Read-Intensive ist im September 2026 weiterhin die preiswerteste Klasse pro Terabyte — mit deutlichem Abstand zu allem anderen
- Enterprise-NVMe Read-Intensive PCIe 4 hat sich preislich stark an SATA angenähert, liegt aber je nach Kapazität und Charge weiterhin darüber
- PCIe-5-Datacenter-NVMe ist eine eigene Klasse und deutlich teurer — rechtfertigt sich nur mit passender CPU, PCIe-Lanes und Workload
- Write-Intensive-Klassen sind protokollunabhängig ein Vielfaches der Read-Intensive-Preise
Für ein konkretes Angebot zu Ihrer Konfiguration — inklusive tagesaktueller Preise, Kapazitätsvarianten und Endurance-Auswahl — nutzen Sie unseren TrueNAS-Konfigurator oder fragen Sie uns direkt an.
Entscheidungsregeln aus der Praxis
Aus unseren Projekten mit TrueNAS- und Proxmox-Kunden lassen sich ein paar robuste Regeln ableiten.
Wann NVMe eindeutig lohnt
- All-Flash-VM-Hosts mit hoher Dichte (30+ produktive VMs pro Node): Latenz und IOPS zahlen sich in stabileren P99-Werten direkt aus
- Datenbank-Storage (Postgres, MSSQL, MariaDB mit spürbarer Concurrency)
- Latenzkritische Fachanwendungen — ERP mit vielen parallelen Nutzern, PDM-Systeme, Video-Editing
- AI/ML-Trainingsdaten, sofern das GPU-Budget zur SSD-Klasse passt (siehe die F-Serie All-Flash-Systeme)
- ZFS-SLOG und Metadata-Vdev brauchen niedrige Latenz — hier ist NVMe der Standard
Wann SATA weiterhin ehrlich passt
- Backup-Repositories und Veeam-Landing-Pools — sequenzielles Schreiben, Bandbreite pro Laufwerk reicht, Kapazität zählt
- File-Server mit klassischen Office-Dokumenten und moderater Nutzeranzahl
- Archiv-Pools mit überwiegend kaltem Zugriff
- Zweit-Storage (Testumgebungen, Staging, Log-Retention), wo Latenz keine Rolle spielt
- Bestandssysteme mit begrenzten PCIe-Lanes, bei denen ein NVMe-Umbau den ganzen Server sprengen würde
Wer nicht sicher ist, in welche Kategorie das eigene System fällt, kann sich anhand des Beitrags Hypervisor-Storage: iSCSI vs. NFS — wann was einen ersten Eindruck über die Anforderungscharakteristik verschaffen.
Hybrid-Setups: die pragmatische Lösung
In der Praxis ist die Antwort selten “alles NVMe” oder “alles SATA”. Am wirtschaftlichsten sind meist hybride Layouts:
- NVMe für heiße Workloads — VM-Root-Disks, Datenbank-Blöcke, Metadata-Vdev
- SATA-SSD für warme Kapazität — Fileshares, Landing-Zone
- HDD für kaltes Archiv — sofern noch benötigt
TrueNAS trennt diese Rollen sauber über Pools, Vdev-Klassen und Special-Vdevs. Der Konfigurator zeigt, welche Backplane welche Kombinationen zulässt und welche Slots sich für welchen Zweck einsetzen lassen.
Was nicht in dieses Vergleichsschema passt
Zwei Zusatzhinweise, die in reinen NVMe-vs-SATA-Diskussionen oft verloren gehen:
SAS ist noch nicht tot. SAS-SSDs (12G / 24G) sind protokollverwandt zu SATA, aber mit Dual-Port, höherer Queue-Tiefe und Enterprise-Feature-Set. In Dual-Controller-Storage-Systemen bleibt SAS eine wichtige Option, auch wenn NVMe zunehmend Anteil gewinnt. Für klassische Direct-Attached-Server ist SAS im Mittelstand meist nicht die richtige Antwort — eher entweder SATA oder NVMe.
EDSFF löst 2,5-Zoll schrittweise ab. Neue Server-Generationen setzen zunehmend auf E1.S oder E3.S statt auf U.2 — kleinere Formfaktoren, bessere Kühlung, höhere Packungsdichte. Für die nächsten drei bis fünf Jahre werden Sie beide Welten parallel sehen, in Neubauten lohnt aber ein Blick auf die EDSFF-Roadmap des jeweiligen Herstellers.
Fazit: keine automatische Antwort mehr
2026 ist “NVMe oder SATA” keine Ideologie-Frage mehr, sondern eine Entscheidung entlang von Workload, Konsolidierungsdichte und Budget. Für VM-Hosts, Datenbanken und AI-Pipelines führt an PCIe 4 oder 5 kein Weg vorbei. Für Backup-Targets, klassische Fileserver und Archiv-Pools ist SATA weiterhin ehrlich wirtschaftlich.
Wenn Sie bei einer konkreten Konfiguration unsicher sind, sprechen Sie uns an — wir arbeiten die Anforderung mit Ihnen durch und geben eine ehrliche Empfehlung, auch wenn sie “SATA reicht” lautet.
FAQ
Ist NVMe automatisch besser als SATA?
Nein. NVMe hat bei Latenz und paralleler IOPS-Leistung einen Größenordnungsvorteil, aber für viele Workloads — besonders Backup-Targets, klassische Fileserver und Archiv-Pools — reicht SATA-SSD problemlos und ist deutlich günstiger pro Terabyte.
Lohnt sich PCIe 5 gegenüber PCIe 4 heute schon?
Für die meisten Workloads liefert PCIe 4 mehr Bandbreite, als die Anwendung tatsächlich abrufen kann. PCIe 5 lohnt sich, wenn Sie tatsächlich CPU-, RAM- und Netzseitig in der Lage sind, die Bandbreite zu nutzen — typisch für AI/ML, sehr große In-Memory-Datenbanken und Medien-Pipelines mit hohen Raw-Bitraten.
Was ist wichtiger, TBW oder DWPD?
Beides ist derselbe Wert aus unterschiedlichen Blickwinkeln. DWPD (Drive Writes Per Day) ist meist praktischer, weil er direkt an die tatsächliche Schreiblast anknüpft. TBW (Total Bytes Written) ist hilfreich für Total-Cost-of-Ownership-Rechnungen über die Garantielaufzeit.
Kann ich in einem TrueNAS-Pool NVMe und SATA mischen?
Technisch ja, praktisch nicht als Data-Vdev empfehlenswert — der Pool läuft nur so schnell wie das langsamste Vdev. Sinnvoll ist die Trennung: NVMe für Metadata-Vdev, SLOG oder eigene Pools mit heißer Workload, SATA für Kapazitäts-Pools mit sequenziellem Zugriff.
Sind Consumer-NVMe-SSDs eine günstige Alternative für Server?
Nein. Consumer-NVMe ohne PLP (Power Loss Protection), mit niedriger DWPD und Consumer-Firmware haben in produktiven Servern nichts zu suchen — weder als Datenpool noch als SLOG. Der scheinbar günstige Einkauf zahlt sich in Ausfällen und Datenverlust nicht aus.
Wo bekomme ich für meine Konfiguration einen konkreten Preisrahmen?
Nutzen Sie unseren TrueNAS-Konfigurator — damit sehen Sie tagesaktuell, welche NVMe- und SATA-Kombinationen für Ihre gewünschte Kapazität und Endurance-Klasse verfügbar sind. Für individuelle Serverkonfigurationen sprechen Sie uns direkt an.
Weitere Artikel
Was kostet Storage wirklich? Cloud vs. TrueNAS über 5 Jahre
Cloud-Storage wirkt günstig – bis Egress, API-Calls und Dauerbetrieb die Rechnung drehen. Eine ehrliche TCO-Betrachtung über 5 Jahre: wann sich On-Premise-TrueNAS rechnet, inklusive Beispielrechnung und Konfigurator.
TrueNAS-Proxmox-Plugin 25.10.6: vier Beobachtungen aus unserem Testlab, die wir an iXsystems zurückspielen
Early-Adopter heißt mitgestalten. Wir betreiben das offizielle TrueNAS-Storage-Plugin für Proxmox VE produktiv und dokumentieren hier, was wir in Version 2.1.17+deb1 auf PVE 9.2.11 und TrueNAS SCALE 25.10.6 beobachtet haben -- inklusive Workarounds für die Community und Verweis auf unsere Partner-Rückmeldung an iXsystems.
TrueNAS als Datenbank-Storage: MSSQL, PostgreSQL und MySQL sauber anbinden
TrueNAS Datenbank Storage in der Praxis: iSCSI-Anbindung, sync=always, Slog-Sizing und ZFS-Snapshots für MSSQL, PostgreSQL und MySQL im KMU.