Cloudflare D1: i limiti del piano Free che bloccano le query

Dal 1 settembre 2026, scegliere Cloudflare D1 Free per la produzione significa prendere una decisione esplicita sulla disponibilità. Quando un account consuma in un giorno 5 milioni di righe lette oppure 100,000 righe scritte, le query D1 possono interrompersi fino alla mezzanotte UTC.

Cloudflare D1 ha cambiato il tipo di guasto, non la quota

Le soglie gratuite esistevano già. A cambiare è ciò che accade quando vengono raggiunte.

Su Workers Free, il superamento di una delle due soglie giornaliere porta ora D1 a rifiutare le query sia tramite Workers Binding API sia tramite REST API. Cloudflare documenta messaggi distinti per i limiti di lettura e scrittura e specifica che le query riprendono quando la quota si azzera alle 00:00 UTC. I dati archiviati restano intatti, ma l'applicazione potrebbe non riuscire né a leggerli né a modificarli.

È questo il punto decisivo: un semplice dato di consumo è diventato un confine netto per la disponibilità.

Cloudflare invia un'email quando viene raggiunto il limite giornaliero. Il messaggio spiega la causa dell'incidente, ma arriva quando il database è già indisponibile. A un team che gestisce un servizio in produzione servono un budget e un avviso anticipato, non soltanto una spiegazione a guasto avvenuto. Il changelog D1 del 1 settembre riporta il comportamento esatto e il testo degli errori.

Workers Paid non è interessato da questo blocco giornaliero. Un prototipo che resta ampiamente sotto entrambe le soglie potrebbe non dover cambiare piano oggi. Un prodotto attivo che dipende da D1, invece, deve ormai trattare il piano Free come qualsiasi altra risorsa dotata di un punto di arresto.

Conta il numero di righe esaminate

La quota di lettura non corrisponde a 5 milioni di chiamate API né a 5 milioni di record restituiti. Corrisponde a 5 milioni di righe esaminate dal database per rispondere alle query.

Si consideri un filtro che restituisce un solo cliente senza poter usare un indice adeguato. Per trovare quel record, D1 potrebbe dover esaminare una tabella di 5,000 righe. Eseguendo la stessa query 1,000 volte si consumano tutti i 5 milioni di letture giornaliere. Il risultato è minuscolo, il lavoro sottostante no.

Le scritture sono più immediate da calcolare. Un'operazione INSERT, UPDATE o DELETE conta le righe modificate. Inserire 10 righe equivale a 10 righe scritte. Anche operazioni sullo schema come CREATE, ALTER e DROP possono consumare una combinazione di letture e scritture.

La dimensione delle righe non cambia questo contatore. Una riga da 1 KB e una da 100 KB valgono entrambe una riga. A incidere sul numero di letture è la forma della query.

Un indice permette a D1 di raggiungere direttamente i record pertinenti anziché esaminare l'intera tabella. In genere, una piccola quantità di lavoro aggiuntivo in scrittura produce una riduzione molto più consistente delle letture. Quando viene scritta una colonna coperta da un indice, D1 aggiorna la riga della tabella e almeno una riga dell'indice. Per questo conviene indicizzare le colonne usate di frequente in filtri e join, non ogni colonna disponibile.

La guida agli indici di Cloudflare propone una verifica semplice. Si antepone EXPLAIN QUERY PLAN alla query costosa: un piano con SCAN sta leggendo la tabella, mentre SEARCH ... USING INDEX indica l'uso di un indice. Dopo aver aggiunto un indice, va eseguito PRAGMA optimize per fornire al query planner statistiche aggiornate.

Come cambiano i costi di Cloudflare D1

Workers Free continua a costare $0. È cambiato il rischio: il conto massimo del database resta pari a zero, ma il database può smettere di servire l'applicazione per il resto della giornata UTC.

Workers Paid parte da $5 per account al mese. Al posto del blocco giornaliero introduce un volume mensile incluso e tariffe per l'utilizzo eccedente.

Il salto dal piano Free al Paid è più ampio di quanto sembri. Trenta giorni al tetto di lettura del piano Free totalizzerebbero 150 milioni di righe, appena lo 0.6% dei 25 miliardi di letture incluse nel piano Paid. Trenta giorni al tetto di scrittura arriverebbero a 3 milioni di righe, cioè il 6% dei 50 milioni di scritture incluse.

Per molte piccole applicazioni, quindi, il primo passaggio a pagamento non dipende dai consumi extra: è una decisione sulla disponibilità da $5. Le richieste Workers, la CPU, lo spazio D1 oltre 5 GB e gli altri prodotti Cloudflare conservano contatori propri. I $5 sono dunque il costo minimo, non la promessa che l'intero account costerà esattamente $5. L'analisi più ampia dei prezzi di Cloudflare chiarisce come si separano account e prodotti.

D1 non applica costi per trasferimento dati o throughput. Questo non attenua il problema del piano Free: significa soltanto che l'egress non rientra tra i numeri da considerare in questa decisione.

Quattro team, quattro decisioni operative

Un founder indipendente con un SaaS attivo

Se accesso, stato della fatturazione o dashboard cliente leggono dati da D1, il piano Free espone ormai la produzione a un rischio di fermo. Il primo passo è individuare la giornata ordinaria più intensa, poi correggere le scansioni complete. Se l'applicazione continua ad avvicinarsi al limite, il minimo di $5 costa meno che pianificare un numero imprecisato di ore senza accesso al database.

Il vantaggio non è una maggiore capacità del database in astratto. È poter eliminare la mezzanotte UTC dal piano di ripristino degli incidenti.

Un'agenzia con più database nello stesso account

La formulazione del limite fa riferimento all'account. Chi gestisce un'agenzia deve quindi censire ogni database D1 presente nell'account Cloudflare, non controllare la proprietà di un solo cliente e considerare sicuro l'intero account.

Le metriche per database permettono di trovare il progetto più rumoroso; prima di definire il budget dell'account, però, occorre sommare tutti i consumi. Il risultato è un valore condiviso di cui il team operativo può assumersi la responsabilità. La scansione inefficiente di un progetto non deve trasformarsi in un'interruzione inspiegabile per un altro progetto dello stesso account.

Un backend engineer alle prese con letture costose

L'obiettivo è individuare la forma delle query, non cancellare dati a caso. D1 restituisce rows_read e rows_written nell'oggetto meta di ogni query. Questi valori mostrano il costo preciso di una singola esecuzione.

Cloudflare offre anche query insights tramite Wrangler e GraphQL Analytics API. Ordinando per numero di letture emergono le scansioni ripetute; a quel punto si esamina il piano, si aggiunge l'indice strettamente necessario e si misura di nuovo. La stessa modifica riduce il consumo della quota e, in genere, anche la latenza.

Un responsabile operativo che gestisce importazioni o sincronizzazioni

Una sincronizzazione massiva può consumare 100,000 scritture prima che il traffico dei clienti abbia la possibilità di usare il database. Un job non urgente può essere distribuito tra più finestre di reset; in alternativa, si può passare al piano Paid prima di un'importazione in produzione.

Non bisogna contare su una pulizia successiva al raggiungimento del limite di scrittura. Anche DELETE è un'operazione di scrittura: la stessa quota esaurita può quindi bloccare la query di pulizia fino al reset. Il vantaggio di pianificare prima è mantenere disponibili le scritture in tempo reale durante il lavoro batch.

Definire il budget dei limiti prima che arrivi l'avviso

Una prima policy concreta può essere questa. Non è un requisito di Cloudflare, ma una regola operativa: per la produzione si usa come budget l'80% della quota Free pubblicata. Il tetto giornaliero operativo diventa così 4 milioni di letture e 80,000 scritture, lasciando 1 milione di letture e 20,000 scritture come margine per i picchi e i ritardi di misurazione.

1. 1

   Misurare una giornata reale

   Aprire Cloudflare, entrare in D1, selezionare ogni database e aprire Metrics. La vista predefinita copre le ultime 24 ore. Occorre consultare uno storico sufficiente a includere normali giorni feriali, lanci, importazioni e picchi di traffico. D1 conserva queste metriche per 31 giorni.

2. 2

   Trovare la query che consuma le righe

   Durante i test dei percorsi importanti, usare i valori meta.rows_read e meta.rows_written di ogni query. Con query insights si possono ordinare le istruzioni più frequenti o costose. Sulla peggiore query di lettura va eseguito EXPLAIN QUERY PLAN; una scansione completa va corretta prima di considerare il cambio di piano come unica soluzione.

3. 3

   Avvisare prima della soglia critica

   Usare GraphQL Analytics API, che legge gli stessi dataset della dashboard, per un controllo programmato dell'account. L'avviso al responsabile deve scattare a 4 milioni di letture o 80,000 scritture. L'email inviata da Cloudflare al raggiungimento del limite resta utile per confermare l'incidente, ma non dovrebbe essere il primo segnale in produzione.

4. 4

   Decidere subito come gestire l'errore

   Stabilire cosa deve restituire il Worker quando D1 genera un errore di limite. Una lettura dalla cache può ancora essere utile, purché non esegua un'altra query D1. Un percorso di scrittura richiede una risposta chiara di indisponibilità oppure una coda progettata separatamente. Non si devono ripetere le richieste in loop contro una quota che non può ripristinarsi prima della mezzanotte UTC o di un upgrade.

La documentazione sulle metriche D1 indica rowsRead e rowsWritten come campi GraphQL e conferma che la dashboard usa gli stessi dati analitici. Un piccolo team dispone così di un percorso manuale immediato e di uno automatizzabile quando il database diventa abbastanza importante da richiedere una reperibilità.

I limiti reali della soluzione

Un indice non è gratuito. Occupa spazio e aggiunge scritture quando cambiano i valori indicizzati. Conviene aggiungere soltanto gli indici che eliminano scansioni costose, per poi misurare il nuovo equilibrio. Un account già vicino al limite di 100,000 scritture può peggiorare la situazione indicizzando senza criterio.

Neppure il piano Paid è illimitato. Include 25 miliardi di letture e 50 milioni di scritture al mese, quindi addebita l'utilizzo eccedente alle tariffe pubblicate. L'upgrade rimuove il blocco giornaliero del piano Free, in genere entro pochi minuti, ma non elimina la necessità di controllare le query inefficienti o di prevedere il resto della fattura Workers. La pagina aggiornata dei prezzi D1 è il riferimento numerico da conservare nel runbook.

Va considerata anche una particolarità nella cronologia delle fonti. Una nota di rilascio D1 del gennaio 2025 indicava l'inizio dell'applicazione dei limiti per il 10 febbraio 2025. Il changelog più recente, dedicato a questo evento, indica invece il 1 settembre 2026. In questo articolo la pagina più nuova viene considerata la fonte principale perché descrive esplicitamente l'attuale distribuzione della modifica. Ecco perché un risultato di ricerca meno recente potrebbe riportare una data diversa.

Infine, «i dati archiviati non sono interessati» è un'affermazione più circoscritta di «il prodotto funziona». I dati possono essere al sicuro mentre ogni percorso che ne ha bisogno restituisce un errore. La conseguenza per l'attività è l'indisponibilità.

Cosa fare lunedì con Cloudflare D1

È il caso di intervenire questa settimana se un'applicazione rivolta ai clienti usa Workers Free e interroga D1 durante le richieste. Prima si misura, poi si correggono le scansioni evidenti, si imposta l'avviso a 4 milioni di letture e 80,000 scritture e si autorizza in anticipo il passaggio al piano Paid da $5.

Si può attendere se si tratta di un prototipo usa e getta, lo storico di 31 giorni resta molto al di sotto del budget operativo e un giorno di errori nelle query non avrebbe effetti su clienti o ricavi. L'avviso va comunque mantenuto, perché sia il traffico sia la dimensione delle tabelle modificano il calcolo delle letture.

Questo specifico blocco giornaliero non riguarda gli account già su Workers Paid né le applicazioni che non interrogano D1.

La decisione del lunedì è semplice: aprire la scheda Metrics di D1 per ogni database, annotare la giornata con il massimo numero di letture e scritture dell'account, individuare la query responsabile della scansione più ampia e autorizzare una persona a eseguire l'upgrade. Se, dopo aver corretto la query, un normale picco supera ancora 4 milioni di letture o 80,000 scritture, l'account va spostato su Workers Paid quello stesso giorno.

Per ricevere anche la prossima novità di piattaforma trasformata in una decisione operativa, iscriviti alla newsletter.