I benchmark che confrontano D1, PlanetScale e Neon tendono a misurare la cosa sbagliata. Latenza in microsecondi, throughput in query al secondo, risultati di query sintetiche: nessuno di questi numeri risponde alla domanda che conta: quale di queste tre banche è giusta per quello che stai costruendo ora, considerando dove cresceranno i tuoi dati, quanto vuoi pagare mentre non hai traffico e quale dialetto SQL assume il tuo codice. Esistono tre diverse architetture con diversi compromessi, non variazioni di prestazioni dello stesso prodotto.
D1: SQLite all'avanguardia a costo zero per iniziare
L'argomento centrale di D1 è l'integrazione nativa con Cloudflare Workers. Quando un lavoratore accede a un database D1 tramite associazione, non esiste un handshake TCP, non esiste una stringa di connessione, non esiste un pool di connessioni da gestire. La query va direttamente all'associazione D1 nello stesso contesto di runtime, con una latenza inferiore al millisecondo per stabilire la chiamata. In un'architettura serverless in cui ogni millisecondo di sovraccarico è importante, questa integrazione è reale e misurabile.
Il livello gratuito offre 5 GB di spazio di archiviazione, 5 milioni di righe lette al giorno e 100mila righe scritte al giorno, sufficienti per lo sviluppo, strumenti interni e prototipi con traffico reale ridotto. Nel piano a pagamento: 0,001 $ per milione di righe lette, 1 $ per milione di righe scritte, 0,75 $/GB al mese di spazio di archiviazione. Lo sviluppo locale tramite wrangler dev --local crea un vero file SQLite sulla macchina, con parità di comportamento con il database remoto.
I limiti che definiscono dove D1 non è utile: 2 GB per banca, 10 banche nel piano a pagamento, nessuna estensione SQLite personalizzata tranne sqlite-vec per la ricerca vettoriale. Una banca che cresce oltre i 2 GB non ha un percorso di espansione all'interno di D1: è necessario suddividere i dati o migrarli su un'altra banca prima di raggiungere il limite. Per le applicazioni che prevedibilmente supereranno questo tetto, D1 è la banca giusta con cui iniziare e la banca sbagliata da mantenere a lungo termine.
PlanetScale: MySQL con sharding orizzontale e ramificazione dello schema
PlanetScale è costruito su Vitess, la stessa infrastruttura di database che ha scalato MySQL di YouTube a volumi che MySQL standard non è in grado di gestire. Questa origine definisce ciò che offre PlanetScale: MySQL autentico (la maggior parte degli ORM funziona senza modifiche), partizionamento orizzontale gestito dalla piattaforma man mano che i dati crescono e il flusso di lavoro con ramificazione dello schema che distingue PlanetScale da qualsiasi altro database oggi disponibile.
La ramificazione dello schema funziona come il controllo della versione per lo schema: crei un ramo dello schema, applichi le modifiche, esegui il test e unisci nuovamente al ramo principale. La migrazione viene eseguita senza bloccare le tabelle, a differenza dello standard ALTER TABLE di MySQL, che blocca le scritture durante l'esecuzione. Per i team che hanno difficoltà con le finestre di manutenzione per le migrazioni o che necessitano di ripristinare in modo sicuro le modifiche dello schema, questa funzionalità risolve un problema reale.
Il costo è il filtro più importante: PlanetScale ha terminato il livello gratuito nel 2024. Il piano Scaler parte da $ 39 al mese. Per i progetti collaterali e le applicazioni in fase iniziale non legate alle entrate, questo piano elimina PlanetScale come opzione. Per prodotti con entrate costanti e team con esperienza MySQL, $ 39 al mese per ciò che PlanetScale offre è ragionevole. Il confronto corretto non è con D1 gratuito, ma con il costo della gestione manuale dello sharding MySQL quando il volume cresce.
Neon: vero PostgreSQL con elaborazione serverless
Neon fornisce PostgreSQL: non un sottoinsieme compatibile, non SQLite con un'interfaccia MySQL, ma l'effettivo runtime Postgres. Questa distinzione è importante quando ciò di cui hai bisogno non esiste in nessun altro database serverless: PostGIS per dati geospaziali, pg_trgm per ricerca di testo fuzzy, pg_partman per il partizionamento automatico delle tabelle, TimescaleDB per serie temporali, funzioni di finestra complesse che SQLite esegue con limitazioni.
Il modello di calcolo serverless di Neon, che scala fino a zero quando non ci sono query, lo mette in una posizione interessante per le applicazioni con traffico sporadico: paghi per il calcolo solo quando si accede attivamente al database. Il piano Pro costa $ 19 al mese con 10 GB di spazio di archiviazione inclusi. Per i team che dispongono già di codice PostgreSQL e necessitano di un database serverless senza migrare il dialetto SQL, Neon è il percorso più diretto.
Lo svantaggio rispetto a D1 in un ambiente Cloudflare Workers: Neon utilizza un pool di connessioni (Neon Proxy) a cui si accede tramite la stringa di connessione PostgreSQL standard. Non esiste un legame nativo come quello di D1. La latenza per stabilire la connessione al Neon Proxy dipende dalla regione Neon configurata e da dove è in esecuzione il Worker: può essere 10 ms o 80 ms a seconda della topologia, rispetto al valore inferiore al millisecondo per D1.
Il costo della migrazione tra i tre
Scegliere un database all'inizio di un progetto ha un costo implicito che si manifesta solo se la scelta è sbagliata ed è necessario cambiare. Le tre banche hanno costi di migrazione asimmetrici.
Passare da D1 a Neon è tecnicamente fattibile ma non banale: wrangler d1 export genera un dump SQL nel dialetto SQLite, che deve essere convertito in PostgreSQL prima dell'importazione. È supportata la maggior parte delle query, ma comportamenti specifici di SQLite, come l'affinità di tipo, la semantica di AUTOINCREMENT rispetto a SERIAL, la gestione delle date, richiedono una revisione caso per caso. Il volume delle modifiche dipende da quanto il codice sfrutta le peculiarità di SQLite.
Passare da PlanetScale a qualsiasi altro database significa passare da MySQL a SQLite (D1) o PostgreSQL (Neon): dialetti diversi con divergenze di sintassi sufficienti a richiedere un reale sforzo di portabilità. Se il codice utilizza transazioni con sintassi specifica di MySQL, funzioni di stringa MySQL o altre funzionalità proprietarie, la migrazione sarà più costosa.
La regola che semplifica la decisione: se utilizzi Cloudflare Workers e i tuoi dati rientrano in meno di 2 GB, D1 è l'impostazione predefinita corretta. Se hai bisogno di PostgreSQL fin dall'inizio (per estensioni, compatibilità con strumenti esistenti, per query che SQLite non supporta bene), inizia con Neon anziché eseguire la migrazione in un secondo momento. PlanetScale entra in gioco quando il requisito è il ridimensionamento orizzontale di Vitess, non il prezzo di ingresso. Nessuno dei tre risolve bene i carichi di lavoro analitici: per questo, Cloudflare Analytics Engine o un database OLAP specializzato è la strada più breve.
Leggi anche
- Instradamento e-mail, Improvmx e Inoltro e-mail: confronto onesto
- Lavoratori + D1 + KV + R2: comporre associazioni nello stesso servizio
- DNS proxy vs solo DNS: cosa cambia e quando ciascuna modalità ha senso
- KV vs R2 vs Cache API: quando utilizzare ciascun livello di archiviazione Cloudflare
- Cloudflare D1: Il database SQLite all'edge — e perché "edge" non significa ciò che sembra
- Bilanciamento del carico e geodirezione di Cloudflare: quando il DNS diventa un livello di traffico intelligente