NVMe vs SSD vs HDD dla obciążeń hostingowych

Zaktualizowano May 9, 2026Baza wiedzy X-ZoneServers

Wybór pamięci masowej w hostingu wpływa na widoczną dla użytkownika wydajność bardziej niż niemal jakikolwiek inny parametr. NVMe SSD, SATA SSD i klasyczne dyski talerzowe różnią się 100-1000-krotnie w wskaźnikach najważniejszych dla baz danych i obciążeń dynamicznych — IOPS i opóźnieniach — ale tylko 5-10-krotnie w samym koszcie za gigabajt. Ten przewodnik rozkłada na czynniki pierwsze leżącą pod spodem technologię, podaje realistyczne liczby IOPS i opóźnień oraz pokazuje, gdzie każdy poziom pamięci masowej zarabia na siebie w 2026 r.

Leżąca u podstaw technologia: dlaczego luka jest tak duża

HDD przechowują bity magnetycznie na obracających się talerzach, co wymaga fizycznego ruchu głowic trwającego 3-15 ms na odczyt losowy. SATA SSD używają komórek pamięci flash dostępnych w mikrosekundach, ale komunikują się starszym protokołem AHCI/SATA zaprojektowanym dla dysków talerzowych. NVMe SSD używają tej samej flash, ale rozmawiają przez PCIe protokołem zaprojektowanym od podstaw pod równoległy dostęp o niskich opóźnieniach — i luka pojawia się wszędzie.

Dysk HDD 7 200 RPM ma średnio 8,3 ms opóźnienia rotacyjnego plus 3-12 ms czasu wyszukiwania, co daje całkowite opóźnienie odczytu losowego ok. 5-15 ms. SATA SSD eliminuje oba dzięki elektronicznej flash, obniżając opóźnienie do ok. 100 mikrosekund (50-100x szybciej), ale jest ograniczony przez pojedynczą kolejkę poleceń protokołu SATA AHCI z 32 oczekującymi operacjami I/O. NVMe (Non-Volatile Memory Express, ustandaryzowane w 2011 r.) zostało zaprojektowane konkretnie pod flash: transport PCIe (bez kontrolera SATA na trasie), 64 tys. kolejek poleceń po 64 tys. poleceń każda (wobec 32 w AHCI) i uproszczony zestaw poleceń. Efekt: opóźnienie end-to-end NVMe spada do 10-50 mikrosekund, równoległość skaluje się niemal liniowo z głębokością kolejki, a pojedynczy dysk NVMe utrzymuje ponad milion losowych IOPS, podczas gdy SATA SSD zatrzymuje się w okolicach 100 tys. Luka technologiczna nie jest „o trochę lepiej” — jest 10-100x w każdej istotnej metryce.

IOPS, opóźnienia i przepustowość — porównanie

Typowe liczby na 2026 r. HDD: 100-200 losowych IOPS, 5-15 ms opóźnienia, 200 MB/s sekwencyjnie. SATA SSD: 50-100 tys. losowych IOPS, ok. 100 μs opóźnienia, 500-550 MB/s sekwencyjnie. NVMe Gen 4 SSD: 500 tys.-1 mln losowych IOPS, 10-50 μs opóźnienia, 5-7 GB/s sekwencyjnie. NVMe Gen 5 SSD: 1,5-2 mln IOPS, ok. 10 μs opóźnienia, 12-14 GB/s sekwencyjnie.

To typowe zakresy cen detalicznych i enterprise w 2026 r., a nie absolutne minima czy maksima. Ceny konsumenckiego NVMe spadły szybciej niż enterprise; luka między konsumenckim NVMe Gen 4 (ok. 70 €/TB) a NVMe enterprise o wysokiej wytrzymałości (ok. 150 €/TB) wynika dziś głównie z wytrzymałości (DWPD — drive writes per day) i kondensatorów ochrony przed utratą zasilania, a nie z surowej wydajności. Dla dostawców hostingu właściwym wyborem jest niemal zawsze NVMe enterprise, ponieważ dyski konsumenckie nie mają wytrzymałości na stałe zapisy ani PLP wymaganych dla obciążeń współdzielonych.

MetrykaHDD 7,2KSATA SSDNVMe Gen 4NVMe Gen 5
Losowe IOPS odczytu (4K)100-200ok. 95 tys.500 tys.-1 mln1,5-2 mln
Losowe IOPS zapisu (4K)100-200ok. 85 tys.300-700 tys.1-1,4 mln
Opóźnienie odczytu (typowo)5-15 msok. 100 μs10-50 μsok. 10 μs
Odczyt sekwencyjny150-250 MB/s500-550 MB/s5-7 GB/s12-14 GB/s
InterfejsSATA 6 Gb/sSATA 6 Gb/sPCIe 4.0 x4PCIe 5.0 x4
Najlepsza głębokość kolejki protokołu13265 53665 536
Koszt 2026 za TB (enterprise)ok. 15-25 €ok. 80-120 €ok. 100-150 €ok. 150-220 €
Koszt 2026 za TB (konsumencki)ok. 25-35 €ok. 50-70 €ok. 70-100 €ok. 120-180 €

Kiedy NVMe ma znaczenie

NVMe ma znaczenie wszędzie tam, gdzie losowe IOPS i opóźnienia ogonowe dominują w wydajności obciążenia: relacyjne bazy danych, magazyny klucz-wartość, indeksy wyszukiwania, kolejki wiadomości, farmy buildowe kontenerów, potoki CI/CD i każde obciążenie o wysokiej współbieżności. Im szybsza aplikacja, tym bardziej korzysta z NVMe — wąskie gardła przesuwają się z dysku na CPU.

Trzy kategorie obciążeń notują dramatyczne zyski z NVMe. Obciążenia bazodanowe — Postgres, MySQL, SQL Server — wykonują wiele równoczesnych losowych odczytów 4-16 kB na indeksach; opóźnienie bezpośrednio przekłada się na czas zapytania. Typowe obciążenie OLTP na SATA SSD uderza w ścianę opóźnień zapytań na 95. percentylu około 1 ms; na NVMe to samo obciążenie działa na p95 poniżej 200 mikrosekund. Obciążenia kontenerowe — Docker, Kubernetes — wykonują tysiące małych odczytów podczas pobierania obrazów i ekstrakcji warstw; NVMe skraca czas zimnego startu 5-10x. Potoki CI/CD i buildowe — bazel, gradle, npm install — są patologicznie ograniczone losowym I/O; przejście z SATA na NVMe rutynowo skraca czasy buildów o połowę. Wspólny mianownik: każde obciążenie, w którym wiele równoczesnych małych operacji ustawia się w kolejce, korzysta ze skalowania głębokości kolejki NVMe. Jednowątkowe obciążenia sekwencyjne notują mniejszą poprawę, bo SATA SSD i tak nasycają swój interfejs.

Kiedy NVMe nie ma znaczenia (a HDD może wystarczyć)

Serwowanie statycznych treści, streaming wideo, zimne kopie zapasowe, archiwizacja logów i wsadowe przetwarzanie dużych plików nie notują znaczących zysków z NVMe, ponieważ są sekwencyjne i ograniczone pasmem, a nie IOPS. HDD 7 200 RPM lub nawet napęd SMR „Hammer” o 250 MB/s sekwencyjnie radzi sobie świetnie — i jest 5-10x tańszy za terabajt.

Trzy wzorce obciążeń ledwie używają IOPS. Serwowanie statycznych treści podaje pliki od 100 kB do kilku MB sekwencyjnie; read-ahead OS i cache dysku sprawiają, że SATA SSD lub nawet HDD jest dla użytkowników końcowych w praktyce równie szybki jak NVMe (zwłaszcza gdy z przodu stoi CDN). Streaming wideo działa podobnie jak długie odczyty sekwencyjne z silną lokalnością cache stron; nawet strumień 10 Gbps treści 4K można łatwo zasilić z poola HDD o 250 MB/s. Pamięć zimnych kopii zapasowych i archiwów dba o koszt za TB i trwałość, a nie o opóźnienia — Backblaze, AWS Glacier i większość korporacyjnych poziomów backupu nadal używają HDD (lub taśm magnetycznych) dla archiwów na skalę petabajtów, gdzie dostęp jest rzadki. Należy określić, czy obciążenie jest ograniczone IOPS, czy pasmem, zanim zapłaci się premię za NVMe; dla obciążeń sekwencyjnych w skali HDD nadal wygrywają pod względem ekonomiki za bajt.

Kompromisy koszt-na-GB w 2026 r.

Cennik enterprise za TB w 2026 r. (typowe zakresy): HDD ok. 15-25 €, SATA SSD ok. 80-120 €, NVMe Gen 4 ok. 100-150 €, NVMe Gen 5 ok. 150-220 €. Luka HDD-SATA się zmniejszyła; luka SATA-NVMe jest dziś na tyle mała, że większość nowych wdrożeń hostingowych standaryzuje się domyślnie na NVMe, a HDD trzymane są dla poziomów backupu i archiwów.

Dwa lata temu luka cenowa SATA-NVMe była na tyle istotna, że średnie plany VPS nadal dostarczały SATA SSD jako standard. Do 2026 r. luka zamknęła się do ok. 20-30% na konfiguracjach enterprise, a luka wydajności (10x na IOPS, 5x na opóźnieniach) sprawia, że matematyka jest prosta: zapłać 20% więcej, dostań 10x wydajności. Niemal każdy masowy host VPS wysyła dziś domyślnie NVMe Gen 4 jako pamięć podstawową. SATA SSD utrzymują się głównie w platformach serwerów dedykowanych z większą liczbą zatok dyskowych, gdzie 8-12 SATA SSD w RAID-10 daje inny profil kosztowy niż 2-4 dyski NVMe w programowym RAID. HDD pozostają dominujące tylko dla obciążeń backupu, archiwum i pamięci masowej hurtowej, gdzie koszt za TB jest ważniejszy niż IOPS. Dla każdego nowego wdrożenia bazy danych jako podstawy NVMe to jedyny sensowny domyślny wybór.

RAID, redundancja i czego nie powie arkusz specyfikacji

Wydajność pojedynczego dysku to tylko połowa historii. RAID na NVMe dodaje narzut CPU, chyba że używa się sprzętowych kart RAID NVMe (rzadkich i drogich); programowe md RAID-1 mirrory są powszechne, RAID-5/6 mniej. Wytrzymałość (DWPD) i ochrona przed utratą zasilania (PLP) mają tyle samo znaczenia co IOPS — konsumenckie dyski NVMe bez PLP mogą stracić dane przy awariach hosta podczas stałych zapisów.

Trzy szczegóły często pomijane w arkuszach specyfikacji. Po pierwsze, programowy RAID-5/6 na NVMe jest ograniczony CPU, a nie dyskiem — przy ponad milionie IOPS obliczanie parzystości może nasycić wiele rdzeni. Większość produkcyjnych wdrożeń NVMe zamiast tego stosuje mirrory RAID-1 i polega na backupach jako zabezpieczeniu poza mirrorowaniem. Po drugie, wytrzymałość dysku jest oceniana w DWPD (drive writes per day) w okresie gwarancji 5 lat; konsumencki NVMe to 0,3-0,5 DWPD, mainstreamowy enterprise to 1-3 DWPD, a write-intensive enterprise to ponad 10 DWPD. Mocno zapisywane obciążenie bazodanowe na dysku konsumenckim potrafi go zużyć w ciągu miesięcy. Po trzecie, ochrona przed utratą zasilania — wbudowane kondensatory wypłukujące zapisy w trakcie do flash przy zaniku zasilania — jest standardem na dyskach enterprise i nieobecna na większości konsumenckich. Bez PLP awaria hosta podczas fsync może uszkodzić dane mimo prawidłowego działania aplikacji. Należy zawsze sprawdzać arkusz specyfikacji pod kątem tych trzech szczegółów, nie tylko IOPS.

Najczęściej zadawane pytania

Czy NVMe jest zawsze szybszy od SATA SSD?
Dla losowego I/O przy każdej istotnej głębokości kolejki tak — NVMe jest 5-15x szybszy w IOPS i 5-10x niższy w opóźnieniach. Dla czysto sekwencyjnych jednowątkowych odczytów dużych plików luka się zmniejsza, bo interfejs SATA 6 Gb/s i tak nasyca fizyczną prędkość talerza; oba zachowują się podobnie pod tym konkretnym wzorcem dostępu.
Czym jest DWPD?
DWPD oznacza „drive writes per day” — ile pełnej pojemności dysku można nadpisać dziennie w okresie gwarancji (zwykle 5 lat) bez przekroczenia wytrzymałości. Dysk 1 TB przy 1 DWPD jest oceniony na 1 TB zapisów dziennie, czyli łącznie 1,825 PB. Obciążenia bazodanowe i CI/CD potrafią przekroczyć oceny DWPD klasy konsumenckiej w ciągu miesięcy.
ZFS czy ext4 z NVMe?
Oba działają. ZFS dodaje sumy kontrolne, snapshoty i kompresję niewielkim kosztem CPU; na NVMe koszt CPU jest bardziej widoczny niż na wolniejszej pamięci masowej. ext4 to domyślny wybór o niższym narzucie dla surowej wydajności IOPS. XFS to mocny środek dla obciążeń z dużymi plikami. Należy wybierać na podstawie wymagań funkcjonalnych, a nie wydajności — wszystkie trzy nasycają nowoczesne NVMe.
Czy NVMe pomaga konkretnie PostgreSQL-owi?
Znacząco. Wypłukiwanie write-ahead log (WAL) Postgresa jest wrażliwe na opóźnienia i korzysta z opóźnień fsync NVMe rzędu 10-50 mikrosekund w porównaniu z ok. 100 mikrosekundami SATA. Skanowanie indeksów na dużych tabelach podobnie korzysta z losowych IOPS odczytu. Realne obciążenia Postgresa działają zwykle 2-5x szybciej na NVMe niż na SATA SSD.
A co z NVMe over fabrics?
NVMe-oF pozwala zdalnym dyskom NVMe wyglądać jak lokalne przez RDMA, TCP lub Fibre Channel. Umożliwia współdzielenie pul wysokowydajnego NVMe między wieloma hostami z opóźnieniem zbliżonym do lokalnego (poniżej 100 mikrosekund dodanych). Jest powszechny w korporacyjnych macierzach pamięci masowej i coraz częstszy w chmurach hyperscale, ale rzadki w masowym hostingu ze względu na koszty sieci i złożoność.
Czy konsumenckie dyski NVMe są kiedykolwiek akceptowalne w hostingu?
Dla dedykowanych, jednonajemcowych serwerów z lekkimi obciążeniami i dobrze przetestowanymi backupami czasem tak — przy znaczących oszczędnościach kosztów. Dla współdzielonego hostingu VPS, środowisk wielonajemcowych lub każdego obciążenia z trwałymi zapisami NVMe enterprise z PLP i wyższym DWPD to jedyny bezpieczny wybór.

Powiązane produkty X-ZoneServers