Cloudflare Hyperdrive: Postgres Dall'edge

Cloudflare Hyperdrive esiste per un problema preciso e per nulla affascinante: un Worker che gira in 200 città e parla con un solo database Postgres in una sola città è più lento della stessa query eseguita da un server piazzato accanto a quel database. Non un po’ più lento. Spesso diverse volte più lento, e per ragioni che non hanno nulla a che vedere con il modo in cui la query è scritta.

L’istinto, quando un’applicazione serverless sembra fiacca, è incolpare il query planner o aggiungere un indice. Su Workers che parlano con un database regionale la query di solito va benissimo. Il problema è la connessione.

Cosa risolve davvero Hyperdrive: il costo di stabilire una connessione al database, pagato a ogni singola richiesta. Una connessione Postgres richiede un handshake TCP, una negoziazione TLS e uno scambio di autenticazione prima che si muova una sola riga, e ognuno di questi passaggi è un giro di andata e ritorno da dove il Worker si è risvegliato fino a dove vive il database. Hyperdrive tiene connessioni calde vicino al tuo database e le mette in pool, così il Worker prende in prestito una connessione già aperta invece di costruirne una.

Perché un Worker collegato direttamente a Postgres è lento

Un server applicativo tradizionale apre un pool di connessioni una volta all’avvio e le riutilizza per tutta la vita del processo. Il costo dell’handshake si paga all’accensione e poi si spalma su milioni di richieste, finché qualcuno non riavvia il servizio.

I Workers non funzionano così. Ogni invocazione è di breve durata e può girare in una qualsiasi delle località di Cloudflare. Non esiste un processo di lunga durata che tenga un pool, quindi senza aiuto ogni richiesta paga per intero il costo di apertura, e lo paga sulla distanza che separa l’edge dal tuo database di origine.

Tre giri di andata e ritorno prima del primo byte di dati non sono un problema di tuning. Un utente a Sydney che colpisce un Worker collegato a Postgres a Londra paga quella latenza quattro volte: TCP, poi TLS, poi autenticazione, poi finalmente la query. La query in sé magari dura due millisecondi.

C’è un secondo guasto, più silenzioso. Postgres alloca un processo backend per ogni connessione e il suo massimo è finito, di solito qualche centinaio. Un Worker che scala a migliaia di invocazioni simultanee esaurirà quel pool e comincerà a raccogliere connessioni rifiutate proprio durante il picco di traffico per cui avevi costruito l’edge.

Cosa fa Hyperdrive al riguardo

Hyperdrive si colloca fra il Worker e il database come connection pooler gestito da Cloudflare per tuo conto. Mantiene connessioni calde verso la tua origine, così un’invocazione ne prende una in prestito invece di negoziarne una nuova da zero.

Mette anche in cache i risultati delle query. Le letture che si ripetono possono essere servite senza toccare affatto l’origine, il che trasforma una questione di latenza in una questione di cache hit per una quota significativa del traffico. Le scritture e tutto ciò che non è deterministico passano dritte.

La configurazione è una stringa di connessione. Registri il database presso Cloudflare, ricevi un binding Hyperdrive e punti il tuo driver Postgres esistente su quel binding invece che sul database. Il driver, l’SQL e lo schema non cambiano. Conta più di quanto sembri, perché significa che la modifica è reversibile e puoi misurarla contro una connessione diretta senza riscrivere nulla.

I numeri che decidono se è adatto

Verificato sulla documentazione di Cloudflare ad agosto 2026, e da ricontrollare prima di impegnarti, perché questi valori si muovono.

Hyperdrive non comporta alcun costo aggiuntivo su nessuno dei due piani e non prevede commissioni di egress. Ciò che conta come query è definito in senso ampio: un select, un insert, un update, un delete o una modifica di schema contano tutti, e le query servite dalla cache contano quanto quelle non in cache. La quota giornaliera gratuita si azzera a mezzanotte UTC.

La documentazione dei limiti indica un timeout di connessione iniziale di 15 secondi e un timeout di inattività di 10 minuti. Il tetto di 60 secondi per query è quello che frega i team che migrano un carico di reporting: una query analitica che su un cron job impiega due minuti qui fallisce e basta.

Quali database funzionano davvero

Hyperdrive supporta PostgreSQL dalla 9.0 alla 17.x e MySQL dalla 5.7 alla 8.x , self-hosted o gestiti. MariaDB rientra nella compatibilità MySQL.

Fra i provider gestiti citati per nome ci sono AWS Aurora nelle sue varianti compatibili con Postgres e MySQL, Neon, Supabase, Timescale, Materialize, CockroachDB e PlanetScale. Funzionano anche le istanze gestite su Azure e Google Cloud.

Il vincolo pratico non è il motore, è la raggiungibilità. Il tuo database deve essere indirizzabile dalla rete di Cloudflare. Un’istanza Postgres sigillata dentro una VPC privata senza endpoint pubblico ha bisogno di un tunnel o di un accordo di peering prima che Hyperdrive possa anche solo vederla, e quello è un progetto di rete, non una modifica di configurazione.

Quando Cloudflare Hyperdrive è la risposta sbagliata

Quando i dati devono stare all’edge. Se il tuo pattern di accesso è fatto di lookup chiave-valore, Workers KV è più veloce e più semplice. Se vuoi un piccolo database relazionale che viva vicino al Worker invece che in una sola regione, D1 è il prodotto pensato per questo. Hyperdrive serve quando hai già Postgres o MySQL e intendi tenerteli.

Quando il carico è analitico. Il tetto di 60 secondi e la contabilizzazione per query si adattano al traffico transazionale. Le aggregazioni lunghe appartengono a un job runner che parla direttamente con il database.

Quando non hai misurato. Il fallimento che vediamo più spesso è un team che aggiunge Hyperdrive a un’applicazione che non era mai stata limitata dalle connessioni. Se un Worker è lento perché emette sei query sequenziali dove ne basterebbe una, mettere in pool quelle sei connessioni lo rende marginalmente meno lento e lascia intatto il problema vero.

Quella misurazione vale la pena di essere fatta bene prima di tutto il resto. Il nostro confronto fra Cloudflare Workers e AWS Lambda spiega dove l’esecuzione all’edge vince davvero, e Cloudflare D1 copre il caso in cui spostare il database batte accelerare la strada per arrivarci.

Prendere la decisione giusta

Cronometra una richiesta da capo a fondo su una connessione diretta, poi di nuovo attraverso Hyperdrive, da una località lontana dal tuo database. Se la differenza è piccola, la tua latenza vive altrove e ti sei risparmiato una dipendenza. Se la differenza è grande, hai trovato denaro vero.

Mecanik progetta e revisiona architetture edge con il suo team di sviluppo software , compresa la parte poco affascinante in cui qualcuno misura che cosa sia davvero lento prima di riprogettare qualsiasi cosa. Se la tua applicazione serverless è più lenta del server che ha sostituito, il percorso di connessione è il primo posto da guardare.

Da leggere anche: Creare un’API Cloudflare Workers: guida serverless 2026 , Cloudflare Queues: job in background all’edge , Ridurre la latenza dei LLM: caching e strategie edge e Come sviluppare una web app nel 2026 .

Domande frequenti

Quale problema risolve Cloudflare Hyperdrive? Il costo di aprire una connessione al database a ogni richiesta. Un Worker è di breve durata e non tiene alcun pool di connessioni, quindi senza Hyperdrive ogni invocazione paga un handshake TCP, una negoziazione TLS e uno scambio di autenticazione sulla distanza che separa l’edge dal tuo database, prima che si muova un solo dato. Hyperdrive tiene connessioni calde in pool vicino all’origine, così il Worker ne prende una in prestito.

Quanto costa Cloudflare Hyperdrive? Nulla oltre al tuo piano Workers. È incluso sia nel piano Free sia nel piano Paid, senza costi separati e senza commissioni di egress. Il piano Free consente 100.000 query al database al giorno, azzerate a mezzanotte UTC, e il piano Paid è illimitato. Select, insert, update, delete e modifiche di schema contano tutti come query, e le query servite dalla cache contano quanto quelle non in cache.

Quali database supporta Hyperdrive? PostgreSQL dalla 9.0 alla 17.x e MySQL dalla 5.7 alla 8.x, self-hosted o gestiti, con MariaDB coperta dalla compatibilità MySQL. Fra i provider citati ci sono AWS Aurora, Neon, Supabase, Timescale, Materialize, CockroachDB e PlanetScale, oltre alle istanze gestite su Azure e Google Cloud. Il database deve essere raggiungibile dalla rete di Cloudflare.

Quali sono i limiti principali di Hyperdrive? Dieci database configurati per account sul piano Free e 25 sul piano Paid, circa 20 connessioni all’origine per configurazione sul Free e 100 sul Paid, una durata massima della query di 60 secondi, una risposta in cache da 50 MB, un timeout di 15 secondi per la connessione iniziale e un timeout di inattività di 10 minuti. Il tetto di 60 secondi per query è quello che blocca i carichi analitici.

Meglio Hyperdrive o D1? Hyperdrive quando hai già un database Postgres o MySQL che intendi tenere e il problema è la latenza per raggiungerlo. D1 quando vuoi un database relazionale che viva fin dall’inizio sulla rete di Cloudflare. Risolvono problemi diversi: uno accelera la strada verso un database esistente, l’altro elimina la distanza spostando i dati.