Un volume che scrive a 3.000 MB/s finché la cache regge, poi a 578, poi a 79,4, e con il disco riempito al 60 per cento arriva a 1,1 MB/s: più lento di un disco meccanico del 2005. Sono i numeri che il canale Homolab ha pubblicato il 21 settembre 2026 su un iPhone 18 Pro Max da 1 TB, ripresi da Tom’s Hardware. Il telefono non interessa a chi gestisce siti per lavoro. Interessa il motivo per cui su quel taglio c’è NAND QLC: è lo stesso motivo per cui la QLC sta finendo dentro i server, i NAS e i VPS che ospitano i vostri siti.

Tre velocità dentro lo stesso disco

Un SSD moderno non ha una velocità in scrittura. Ne ha tre, e ve ne mostra una sola.

La prima è la cache SLC: una porzione del disco fatta funzionare a un bit per cella, velocissima e piccola. Nel test Homolab arriva a 3.000 MB/s. È il numero che finisce sulla scheda tecnica.

La seconda entra in gioco quando la cache SLC è piena: un buffer secondario a tre bit per cella, misurato intorno ai 578 MB/s. Un quinto della prima. Nessuno lo pubblica.

La terza è il disco vero: scrittura diretta sulle celle QLC, quattro bit ciascuna. Qui la misura scende a 79,4 MB/s di media, con cadute puntuali a 25,6 MB/s.

Il punto interessante non è il gradino. È cosa succede quando il disco si riempie, perché la cache SLC è ricavata dallo spazio libero e quindi si restringe insieme a lui. Con il volume al 60 per cento, sempre nello stesso test, la cache scende da 250 GB a 58 GB, il buffer secondario rallenta a 396 MB/s e la scrittura diretta su QLC si assesta a 45 MB/s di media, con minimi a 1,1 MB/s.

Sui carichi misti a bassa profondità di coda — quelli che somigliano a un database che lavora — il modello QLC segna 8.168 punti contro 11.285 del modello TLC di pari generazione: il 38 per cento in meno. Sotto carico pesante il divario si stringe, ma il TLC resta avanti del 12 per cento.

La take: la scheda tecnica di uno storage dichiara il picco, e il picco è la cache, non il disco. Chi dimensiona un server sul numero grande sta dimensionando su una risorsa che si esaurisce, e che si esaurisce prima man mano che il disco si riempie.

La QLC non è una scelta di fascia bassa, è la fascia

Verrebbe da archiviare la cosa come un compromesso commerciale su un telefono. Non lo è. Nel rilevamento prezzi del 31 marzo 2026, TrendForce dava i contratti NAND Flash in crescita del 70-75 per cento su base trimestrale nel secondo trimestre, con la DRAM convenzionale al 58-63 per cento. La causa dichiarata è una sola: domanda da server AI e data center.

Le conseguenze, nello stesso documento, sono due e vanno lette insieme. La capacità produttiva viene spostata sugli SSD enterprise, mentre le applicazioni consumer vengono ridimensionate; e i produttori aumentano i bit disponibili anche tramite una maggiore adozione di QLC. Tradotto: quando l’unico modo per far uscire più terabyte dalla stessa fabbrica è mettere quattro bit in ogni cella invece di tre, la QLC smette di essere l’opzione economica e diventa il default.

TrendForce aggiunge il dato che conta per chi pianifica: la carenza sugli SSD enterprise è attesa per tutto il 2026, e un’espansione significativa della capacità produttiva non è considerata probabile prima di fine 2027 o 2028. Non è un picco stagionale, è una riallocazione strutturale.

Questo è il ponte con una cosa già vista da questa parte del mestiere: l’AI non alza solo il costo dei token, alza il costo e cambia la qualità dei componenti che stanno sotto ai vostri siti. Ne avevo scritto a proposito di memoria, server ed energia; lo storage è lo stesso meccanismo, con un effetto collaterale in più che non è il prezzo ma il comportamento sotto carico.

Dove il dirupo tocca davvero un sito

Il traffico normale di un sito WordPress non incontra mai la QLC nuda. È un carico prevalentemente in lettura, fatto di file piccoli, servito da cache a più livelli. Su quello i tre numeri di prima non cambiano nulla.

Il dirupo si incontra in cinque momenti precisi, tutti accomunati da una cosa: scrittura sostenuta, per un volume più grande della cache.

  • Il backup notturno completo. Dump del database più archivio della cartella uploads, scritti di fila sullo stesso volume.
  • Il restore e la migrazione. Scompattare un archivio da decine di GB è l’unico momento in cui un sito scrive per mezz’ora senza pause.
  • L’import di catalogo e la rigenerazione delle miniature. Su WooCommerce un import di qualche migliaio di prodotti con immagini genera decine di migliaia di file nuovi in pochi minuti.
  • Log e cache su disco. Non per volume, ma per continuità: tengono la cache SLC occupata anche quando credete che il server sia fermo.
  • Gli indici locali per l’AI. Chi si è portato in casa un modello o un indice vettoriale scrive, in fase di indicizzazione, esattamente il tipo di carico che questo hardware gestisce peggio. Vale anche per i modelli locali usati su ticket e contenuti, dove il primo passaggio sull’archivio storico è un’unica, lunga scrittura.

Un conto di ordine di grandezza rende la cosa concreta. Quaranta GB di uploads da archiviare sono circa 41.000 MB. A 578 MB/s sono poco più di un minuto. A 45 MB/s sono quindici minuti. A 1,1 MB/s sono oltre dieci ore. È aritmetica sui numeri misurati da altri, non una misura sul vostro disco: serve solo a mostrare che fra il caso buono e il caso cattivo non c’è un peggioramento, c’è un cambio di scala. Un backup che sfora la finestra notturna e si trova ancora in esecuzione alle nove del mattino non è un backup lento, è un sito lento in orario di lavoro.

Misurarlo in dieci minuti, prima di firmare

La misura è facile da fare e facilissima da sbagliare, perché il modo naturale di testare uno storage — scrivere un file da qualche GB e guardare il risultato — misura solo la cache e vi restituisce il numero della scheda tecnica.

Le due regole che rendono valido il test sono queste: scrivere più dati di quanti ne entrino nella cache, e farlo con il disco già riempito al livello reale di esercizio, non su un volume appena provisionato e vuoto.

Su una macchina Linux, con fio installato:

fio --name=sostenuta --filename=/var/tmp/fio-test \
    --rw=write --bs=1M --size=64G --direct=1 \
    --numjobs=1 --iodepth=1 --end_fsync=1 \
    --log_avg_msec=1000 --write_bw_log=qlc

Il --direct=1 salta la cache del sistema operativo, altrimenti misurate la RAM. Il --write_bw_log è la parte importante: produce un file con la banda campionata ogni secondo, ed è lì che il gradino si vede. Un valore medio unico nasconde esattamente il fenomeno che state cercando.

Senza fio, la versione povera che serve comunque a vedere il crollo (anche questa su Linux: oflag=direct e status=progress sono del dd di GNU coreutils e su macOS non esistono):

dd if=/dev/zero of=/var/tmp/dd-test bs=1M count=65536 \
   oflag=direct status=progress

La velocità stampata durante l’esecuzione scende a scalini. Il numero che dovete scrivervi non è quello finale medio: è il pavimento, cioè il valore su cui si assesta negli ultimi minuti.

Tre avvertenze, tutte imparate a spese di qualcuno. Servono 64 GB liberi e vanno cancellati dopo. Su un volume condiviso il risultato risente anche di quello che fanno gli altri inquilini, il che è un difetto del test ma anche un’informazione. E scrivere 64 GB consuma endurance reale: su QLC, che di cicli ne ha meno, è un test da fare una volta per volume, non ogni settimana.

Cosa cambiare nelle operazioni

Nessuno di questi interventi richiede di cambiare hosting. Riducono tutti la stessa cosa: la quantità di byte scritti di fila.

  1. Tenere il volume sotto il 60-70 per cento. Non è igiene generica: la cache SLC è ricavata dallo spazio libero, quindi ogni punto percentuale di riempimento in più è cache in meno. Nel test citato il passaggio a disco pieno al 60 per cento taglia la cache da 250 a 58 GB, cioè di oltre tre quarti.
  2. Backup incrementali al posto del full notturno. Con restic, borg o un rsync --link-dest la scrittura quotidiana passa da decine di GB a poche centinaia di MB, che stanno dentro la cache SLC anche su un disco mezzo pieno. Il full resta, una volta a settimana, in una finestra dove la lentezza non fa danni.
  3. Comprimere prima di scrivere. Se la CPU è scarica e il disco è il collo di bottiglia, spendere cicli per scrivere metà dei byte è un affare. Su un archivio di uploads già compressi non cambia niente; su un dump SQL cambia molto.
  4. Separare i volumi per tipo di carico. Database e cache su un volume piccolo e veloce, archivio e backup su quello grande ed economico. È lo stesso ragionamento che si fa quando si decide quanta infrastruttura tenere e quanta comprare come servizio: si paga la prestazione solo dove serve.
  5. Spalmare le scritture nel tempo. Due finestre da 20 GB distanti qualche ora battono una finestra da 40, perché fra l’una e l’altra il controller ha il tempo di travasare la cache SLC sulle celle QLC e ripresentarsi vuoto.

Le domande da fare al fornitore

Prima di rinnovare un VPS o comprare un NAS, quattro domande scritte. Vanno fatte per iscritto perché la risposta, quando arriva, è anche una prova.

  • Il volume è su NAND TLC o QLC? Se la risposta è “NVMe”, l’interlocutore non ha capito o non vuole rispondere: NVMe è il protocollo con cui il disco parla, non il tipo di cella con cui scrive.
  • Qual è la banda in scrittura sostenuta oltre la cache? Non il picco. Se il numero non esiste, esiste comunque: significa solo che non è mai stato misurato.
  • Qual è il TBW o il DWPD del volume, e cosa succede quando lo supero? La QLC ha meno cicli di scrittura per cella della TLC. Su un sito che rigenera miniature tutti i giorni è una domanda con una risposta economica.
  • Il volume è dedicato o condiviso? Su storage condiviso la cache SLC la consumate insieme ai vicini, e i vostri tre numeri diventano quattro.

Dove questi numeri non valgono

Onestà sulle fonti, perché qui è facile allargare troppo. Le misure di Homolab sono benchmark sintetici costruiti per rappresentare il caso peggiore, e Tom’s Hardware lo scrive esplicitamente: nell’uso normale del telefono, quel comportamento non si vede. Il canale è una fonte indipendente su piattaforma video, non un laboratorio con metodologia pubblicata e replicata. Va aggiunto che il confronto mette un taglio da 1 TB con celle QLC contro uno da 512 GB con celle TLC: non è un test a parità di capacità, e il taglio più grande in genere gioca a favore della QLC, quindi il divario misurato è semmai conservativo.

E un telefono non è un server. Un SSD enterprise ha più over-provisioning, un controller diverso, dissipazione vera e firmware tarato su carichi continui: i tre numeri non saranno quei tre. Resta uguale la forma della curva, che dipende dalla fisica delle celle e non dal prodotto: picco in cache, gradino sul buffer, pavimento sulla QLC nuda, e cache che si accorcia man mano che il disco si riempie.

Il claim difendibile è quindi più stretto e più utile di quello del titolo di giornata: non “gli SSD nuovi sono lenti”, ma il singolo numero che vi hanno venduto non descrive più il disco, e il divario fra quel numero e il comportamento reale sotto scrittura sostenuta si sta allargando perché la QLC si sta diffondendo. La verifica costa dieci minuti e va fatta sul vostro volume.

In pratica

Tre cose da fare questa settimana, in ordine di costo crescente:

  • Guardate quanto è pieno il volume che ospita i backup. Se è oltre il 70 per cento, avete già perso la maggior parte della cache e il problema non è futuro.
  • Lanciate fio o dd con la regola dei 64 GB e segnatevi il pavimento, non la media. È il numero con cui calcolare quanto dura davvero una finestra di backup o un restore.
  • Se il pavimento è sotto i 100 MB/s, passate a backup incrementali prima di cambiare fornitore: costa un pomeriggio e toglie di mezzo la maggior parte delle scritture.

La cosa da monitorare nei prossimi mesi è la durata delle finestre di manutenzione, non la loro riuscita. Un backup che riesce in tre ore invece che in venti minuti non manda alert, non compare in nessuna dashboard, e intanto vi dice che il disco sotto è cambiato.

Fonti