Cloudflare Workers Python: accesso ai database esistenti

Cloudflare Workers Python: il database resta dov'è

Il vero vantaggio di questa novità è ciò che non occorre più spostare.

Hyperdrive è un livello di connessione gestito tra un Cloudflare Worker e un database PostgreSQL o MySQL esistente. Non è un nuovo database e non copia i record su Cloudflare. Il codice Python apre una connessione TCP con un normale driver, utilizzando i parametri forniti da un binding Hyperdrive. Dietro le quinte, Hyperdrive mantiene il pool di connessioni persistenti verso il database.

Questo cambia il workaround più comune. Un Worker Python che non riusciva a raggiungere direttamente il database poteva chiamare una piccola API o un server incaricato esclusivamente di eseguire SQL. Il percorso era questo:

Prima: Worker Python → bridge per il database → PostgreSQL o MySQL

Ora: Worker Python → Hyperdrive → PostgreSQL o MySQL

Cloudflare gestisce l'apertura della connessione vicino al Worker e mantiene le connessioni del pool vicino al database di origine. La sua guida a Hyperdrive conta sette round trip in una configurazione tradizionale prima della prima query: uno per TCP, tre per TLS e tre per l'autenticazione al database. Riutilizzare il pool evita di ripetere l'intera procedura a ogni breve invocazione del Worker.

Il percorso supportato ha requisiti precisi. I Worker Python richiedono una data di compatibilità pari o successiva a 2026-09-08 e la funzionalità è ancora in beta. Per PostgreSQL, Cloudflare ha testato asyncpg, pg8000 e psycopg; per MySQL, aiomysql e pymysql. I driver consigliati sono asyncpg e aiomysql.

Secondo Cloudflare, potrebbero funzionare anche altri driver TCP. Questo, però, non garantisce che ogni pacchetto, ORM o applicazione esistente sia compatibile. La compatibilità del database permette di superare il primo controllo, non l'intera migrazione.

La voce di budget che cambia

Il risparmio più evidente si presenta quando l'app Python gira già su Workers e si paga un bridge solo perché il Worker deve accedere al database.

Il calcolo è semplice:

Costo mensile attuale = database + Worker + hosting del bridge

Costo mensile possibile = database + Worker

Il costo del database rimane. Il pooling delle connessioni e la cache delle query integrati in Hyperdrive non comportano costi separati con Workers Paid; inoltre, Hyperdrive non addebita il traffico in uscita. Se l'account rientra già nell'utilizzo incluso di Workers, il costo Cloudflare aggiuntivo per questo percorso di connessione è quindi $0. Il risparmio concreto possibile corrisponde alla fattura dell'hosting del bridge che si riesce davvero a eliminare.

Anche la manutenzione rientra nello stesso calcolo. Eliminare il bridge può significare eliminare anche un deployment, un health check, un set di secret, un flusso di log e un punto di errore. Non attribuire un valore economico a questo lavoro finché non è chiaro chi lo gestisce e con quale frequenza crea problemi.

Per un nuovo account a pagamento, Workers Paid parte da $5 per account al mese. Sono inclusi 10 milioni di richieste e 30 milioni di millisecondi CPU al mese. Oltre queste soglie, si pagano $0.30 per ogni milione di richieste aggiuntive e $0.02 per ogni milione di millisecondi CPU aggiuntivi. Nel piano, le query al database tramite Hyperdrive risultano illimitate.

Il piano Free è sufficiente per una piccola prova. Include 100,000 richieste Worker al giorno e 100,000 query Hyperdrive al database al giorno, con 10 millisecondi di tempo CPU per invocazione. Sono contatori separati: una singola richiesta che esegue più istruzioni SQL può consumare più query al database.

Chi può sfruttare subito questa novità

Un founder indipendente con un servizio FastAPI

Immaginiamo un founder con un Worker FastAPI davanti a un database PostgreSQL gestito e un piccolo container che riceve chiamate HTTP ed esegue SQL. Se quel container non contiene logica di business, un test con asyncpg può stabilire se Hyperdrive è in grado di sostituirlo.

Il vantaggio non è un database nuovo. Consiste nel mantenere schema, backup e provider attuali, eliminando un servizio nato soltanto come adattatore di connessione. Conviene migrare prima una singola route, confrontarne risultato e latenza e rimuovere il bridge solo quando il comportamento in produzione coincide.

Una piccola agenzia con database MySQL dei clienti

Una piccola agenzia può gestire diverse API Python essenziali, ognuna collegata al database MySQL di un cliente. Il nuovo percorso consente di provare aiomysql o pymysql direttamente nel Worker, invece di distribuire un proxy per il database accanto a ogni applicazione idonea.

Il vantaggio è la coerenza operativa. L'agenzia può adottare un unico percorso di deployment dei Worker e una configurazione Hyperdrive per ogni database. Il bridge va invece mantenuto quando gestisce l'autorizzazione dei tenant, la trasformazione degli schemi, l'auditing o qualsiasi altra funzione che non si limiti a inoltrare le query.

Un platform team che sposta un endpoint ad alta intensità di lettura

Un platform team non deve migrare l'intero backend. Può spostare su Workers un singolo endpoint Python pubblico e orientato alle letture, mantenere il database regionale e lasciare a Hyperdrive il pooling delle connessioni all'origine.

In questo scenario anche la cache richiede una scelta esplicita. Per impostazione predefinita, Hyperdrive conserva per 60 secondi le letture idonee e può restituire un risultato non aggiornato per altri 15 secondi durante la riconvalida. Le letture pubbliche di cataloghi o contenuti possono tollerarlo. Per autenticazione, permessi, stato della fatturazione e letture immediatamente successive a una scrittura, è opportuno usare una configurazione Hyperdrive separata con cache disattivata.

Il precedente confronto tra Django e FastAPI resta utile per scegliere il framework. Questa novità cambia una parte della decisione: mantenere PostgreSQL o MySQL è ora un percorso documentato per i Worker Python, ma ciò non certifica il resto di un'applicazione Django o FastAPI.

Il test di connessione minimo e sicuro

Usa un database MySQL non di produzione e un utente di test con privilegi limitati. L'obiettivo è verificare il percorso di connessione con SELECT 1, non simulare un'intera migrazione sui dati dei clienti.

Crea una configurazione Hyperdrive con cache disattivata, così il primo test misura un round trip effettivo verso il database:

npx wrangler hyperdrive create python-db-test --connection-string="mysql://user:password@HOSTNAME_OR_IP_ADDRESS:PORT/database_name" --caching-disabled

Copia in wrangler.toml l'ID della configurazione restituito da Wrangler. La data seguente è successiva al requisito minimo 2026-09-08:

name = "python-hyperdrive"
main = "src/main.py"
compatibility_date = "2026-09-16"
compatibility_flags = ["python_workers"]

[[hyperdrive]]
binding = "HYPERDRIVE"
id = "<HYPERDRIVE_CONFIG_ID>"

Aggiungi il driver a pyproject.toml:

[project]
dependencies = [
    "aiomysql",
]

Poi inserisci in src/main.py il test di connessione documentato da Cloudflare:

import aiomysql
from workers import Response, WorkerEntrypoint


class Default(WorkerEntrypoint):
    async def fetch(self, request):
        hd = self.env.HYPERDRIVE
        connection = await aiomysql.connect(
            host=hd.host,
            port=int(hd.port),
            user=hd.user,
            password=hd.password,
            db=hd.database,
            ssl=None,
        )
        try:
            cursor = await connection.cursor()
            await cursor.execute("SELECT 1")
            result = await cursor.fetchone()
            return Response.json({"result": result[0]})
        finally:
            connection.close()

Esegui il deployment con il comando documentato per Python Workers:

uv run pywrangler deploy

La riga che più spesso sembra errata è ssl=None. Nell'esempio di Cloudflare, riguarda la connessione del driver tra il Worker e Hyperdrive. La connessione di Hyperdrive al database di origine richiede comunque TLS e non supporta connessioni di origine non sicure in chiaro.

Il bridge è facoltativo, non automaticamente superato

La novità modifica un percorso di connessione, ma non trasforma i Worker Python in server CPython senza restrizioni.

Il supporto dei pacchetti Python comprende i pacchetti pure Python, le wheel PyEmscripten e i pacchetti inclusi in Pyodide. Cloudflare definisce ancora preliminare il supporto dei pacchetti WebAssembly, quindi una dipendenza mancante può bloccare la migrazione. La documentazione su driver e ORM supporta attualmente soltanto SQLAlchemy sincrono. SQLAlchemy asincrono non è supportato perché nell'ambiente Workers manca il supporto per greenlet.

Anche il protocollo del database presenta limiti precisi. Hyperdrive supporta PostgreSQL dalla versione 9.0 alla 17.x e MySQL dalla 5.7 alla 8.x, oltre a MariaDB. Non supporta SQL Server o MongoDB. Sono esclusi gli advisory lock di PostgreSQL e LISTEN o NOTIFY; per MySQL, non sono supportate le query multi-statement né le prepared statement a livello di protocollo. Sia nel piano Free sia nel Paid, una query può durare al massimo 60 secondi.

Il pooling cambia anche le aspettative sullo stato della sessione. Hyperdrive usa il transaction pooling: al termine della transazione, la connessione all'origine torna nel pool. Il codice che presume di conservare lo stato della sessione tra una transazione e l'altra deve essere rivisto. Inoltre, le transazioni lunghe possono esaurire il pool e annullare il vantaggio in termini di concorrenza.

La mossa da fare lunedì

Lunedì non migrare l'applicazione. Verifica se ha ancora senso mantenere un bridge dedicato soltanto al database.

Intervieni questa settimana se il bridge serve esclusivamente ad accedere al database, l'app usa PostgreSQL o MySQL e la route è coperta da un driver testato. Aspetta se dipendi da SQLAlchemy asincrono, da un pacchetto non disponibile, da funzionalità SQL non supportate o da una coerenza read-after-write rigorosa che non hai ancora isolato. La novità non cambia nulla se l'app resta sul server attuale o se il bridge contiene logica di business che Hyperdrive non può sostituire.

Per trasformare anche la prossima novità di piattaforma in una decisione concreta da prendere lunedì, iscriviti alla newsletter.