Cloudflare Hyperdrive ouvre vos bases existantes à Python

Avec Cloudflare Hyperdrive, la base reste en place

Tout l’intérêt de cette nouveauté tient à ce qu’elle évite de déplacer.

Hyperdrive est une couche de connexion managée entre un Cloudflare Worker et une base PostgreSQL ou MySQL existante. Ce n’est ni une nouvelle base de données ni un système qui recopie vos données chez Cloudflare. Le code Python ouvre une connexion TCP avec un driver classique, à partir des paramètres fournis par un binding Hyperdrive. En arrière-plan, Hyperdrive maintient un pool de connexions persistantes vers la base.

C’est ce qui fait disparaître le contournement habituel. Faute de pouvoir joindre directement sa base, un Python Worker pouvait appeler une petite API ou un serveur dont l’unique fonction consistait à exécuter du SQL. Le chemin ressemblait alors à ceci :

Avant : Python Worker → passerelle d’accès à la base → PostgreSQL ou MySQL

Maintenant : Python Worker → Hyperdrive → PostgreSQL ou MySQL

Cloudflare établit la connexion près du Worker et conserve les connexions du pool près de la base d’origine. Son guide Hyperdrive dénombre sept allers-retours avant la première requête dans une configuration classique : un pour TCP, trois pour TLS et trois pour l’authentification auprès de la base. La réutilisation du pool évite de reprendre toute cette séquence à chaque exécution éphémère du Worker.

Le périmètre pris en charge est précis. Les Python Workers doivent utiliser une date de compatibilité égale ou postérieure au 2026-09-08, et la fonctionnalité reste en bêta. Cloudflare a testé asyncpg, pg8000 et psycopg pour PostgreSQL, ainsi que aiomysql et pymysql pour MySQL. Les drivers recommandés sont asyncpg et aiomysql.

Selon Cloudflare, d’autres drivers TCP peuvent fonctionner. Cela ne garantit pas pour autant la compatibilité de chaque package, ORM ou application existante. La base franchit peut-être le premier filtre ; la migration, elle, reste à valider de bout en bout.

La ligne budgétaire qui peut disparaître

Le gain financier est le plus net lorsque l’application Python tourne déjà sur Workers et qu’une passerelle payante ne subsiste que pour lui donner accès à la base.

Le calcul est simple :

Coût mensuel actuel = base de données + Worker + hébergement de la passerelle

Coût mensuel possible = base de données + Worker

La facture de la base ne change pas. Sur Workers Paid, le pooling des connexions et le cache des requêtes intégrés à Hyperdrive n’entraînent aucun coût distinct, et Hyperdrive ne facture pas les transferts sortants. Si le compte reste déjà dans le volume inclus de Workers, le surcoût Cloudflare de ce chemin de connexion est donc de $0. L’économie réelle correspond à la facture d’hébergement de la passerelle qui disparaît effectivement.

La maintenance entre dans le même calcul. Retirer la passerelle, c’est aussi potentiellement retirer un déploiement, un contrôle de disponibilité, un jeu de secrets, un flux de logs et un point de défaillance. Mieux vaut ne pas valoriser ce travail avant de savoir qui l’assure et à quelle fréquence ce service pose problème.

Pour un nouveau compte payant, Workers Paid démarre à $5 par compte et par mois. L’offre comprend 10 millions de requêtes et 30 millions de millisecondes CPU par mois. Au-delà, chaque million de requêtes supplémentaire coûte $0.30 et chaque million de millisecondes CPU, $0.02. Sur cette offre, le nombre de requêtes vers la base via Hyperdrive est annoncé comme illimité.

L’offre Free suffit pour un petit test. Elle inclut 100,000 requêtes Worker et 100,000 requêtes Hyperdrive vers la base par jour, avec 10 millisecondes de CPU par invocation. Ces quotas sont comptabilisés séparément. Une seule requête qui exécute plusieurs instructions SQL peut donc consommer plusieurs requêtes de base de données.

Qui peut en profiter dès demain ?

Un fondateur solo avec un service FastAPI

Imaginons un fondateur qui exploite un Worker FastAPI devant une base PostgreSQL managée, accompagné d’un petit conteneur chargé de recevoir des appels HTTP et d’exécuter du SQL. Si ce conteneur ne contient aucune logique métier, un essai avec asyncpg permet de vérifier si Hyperdrive peut le remplacer.

Le bénéfice n’est pas de changer de base. Il consiste à conserver le schéma, les sauvegardes et le fournisseur actuels tout en supprimant un service qui n’existait que pour adapter la connexion. Il faut commencer par migrer une route, comparer son résultat et sa latence, puis retirer la passerelle une fois le comportement en production confirmé.

Une petite agence et les bases MySQL de ses clients

Une petite agence peut maintenir plusieurs API Python ciblées, chacune reliée à la base MySQL d’un client. Ce nouveau chemin lui permet de tester aiomysql ou pymysql dans le Worker, au lieu de déployer un proxy de base de données à côté de chaque application compatible.

Le gain est avant tout opérationnel : un même workflow de déploiement Worker et une configuration Hyperdrive par base. En revanche, la passerelle doit rester si elle gère l’autorisation des tenants, la traduction de schémas, l’audit ou toute autre tâche qui dépasse le simple transport des requêtes.

Une équipe plateforme qui déplace un endpoint à dominante lecture

Une équipe plateforme n’a aucune obligation de migrer tout son backend. Elle peut déplacer vers Workers un seul endpoint Python public qui effectue beaucoup de lectures, conserver la base régionale et confier à Hyperdrive le pool de connexions vers l’origine.

C’est aussi le moment de prendre une décision explicite sur le cache. Par défaut, Hyperdrive met en cache les lectures éligibles pendant 60 secondes et peut servir un résultat obsolète durant 15 secondes supplémentaires pendant la revalidation. Un catalogue public ou des contenus peuvent l’accepter. Pour l’authentification, les permissions, la facturation et les lectures qui suivent immédiatement une écriture, mieux vaut une configuration Hyperdrive distincte avec le cache désactivé.

Le précédent comparatif entre Django et FastAPI reste utile pour choisir un framework. Cette sortie modifie toutefois un volet de la décision : conserver PostgreSQL ou MySQL constitue désormais un chemin documenté pour un Python Worker, sans que cela certifie le reste d’une application Django ou FastAPI.

Monter le plus petit test de connexion fiable

Utilisez une base MySQL hors production et un compte de test aux droits limités. Il s’agit de valider le chemin de connexion avec SELECT 1, pas de simuler une migration complète sur les données de clients.

Créez une configuration Hyperdrive sans cache afin que le premier essai mesure un véritable aller-retour vers la base :

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

Copiez dans wrangler.toml l’identifiant de configuration renvoyé par Wrangler. La date ci-dessous est postérieure au minimum requis, 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>"

Ajoutez le driver dans pyproject.toml :

[project]
dependencies = [
    "aiomysql",
]

Reprenez ensuite dans src/main.py le test de connexion documenté par 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()

Déployez-le avec la commande Python Workers documentée :

uv run pywrangler deploy

La ligne ssl=None peut sembler suspecte. Dans l’exemple de Cloudflare, elle concerne la connexion du driver entre le Worker et Hyperdrive. La connexion d’Hyperdrive à la base d’origine exige toujours TLS ; les connexions en clair non sécurisées vers l’origine ne sont pas prises en charge.

La passerelle devient facultative, pas automatiquement obsolète

Cette sortie ouvre un nouveau chemin de connexion. Elle ne transforme pas les Python Workers en serveurs CPython sans contraintes.

La prise en charge des packages couvre les packages Python purs, les wheels PyEmscripten et les packages inclus avec Pyodide. Cloudflare considère encore le support des packages WebAssembly comme précoce : une dépendance manquante peut donc bloquer la migration. La documentation sur les drivers et les ORM ne prend actuellement en charge que SQLAlchemy synchrone. SQLAlchemy asynchrone ne fonctionne pas, car l’environnement Workers ne gère pas greenlet.

Le protocole de base de données impose ses propres limites. Hyperdrive prend en charge PostgreSQL 9.0 à 17.x et MySQL 5.7 à 8.x, ainsi que MariaDB. SQL Server et MongoDB ne sont pas compatibles. Les verrous consultatifs PostgreSQL et LISTEN ou NOTIFY sont exclus, tout comme les requêtes MySQL multi-instructions et les requêtes préparées au niveau du protocole. Sur Free comme sur Paid, une requête ne peut pas dépasser 60 secondes.

Le pooling change aussi les hypothèses liées aux sessions. Hyperdrive utilise le pooling par transaction : la connexion d’origine retourne au pool dès la fin de la transaction. Tout code qui suppose qu’un état de session persiste entre les transactions doit être réexaminé. Des transactions longues peuvent également épuiser le pool et annuler le gain de concurrence.

Le plan d’action du lundi

Ne migrez pas toute l’application lundi. Commencez par déterminer si une passerelle dédiée à la base mérite encore d’exister.

Agissez cette semaine si la passerelle ne sert qu’à accéder à la base, si l’application utilise PostgreSQL ou MySQL et si un driver testé couvre la route. Attendez si vous dépendez de SQLAlchemy asynchrone, d’un package indisponible, d’un comportement SQL non pris en charge ou d’une stricte cohérence après écriture que vous n’avez pas isolée. Rien ne change pour vous si l’application reste sur son serveur actuel ou si la passerelle porte une logique métier qu’Hyperdrive ne remplace pas.

Pour recevoir la prochaine évolution de plateforme traduite en décision concrète pour le lundi, inscrivez-vous à la newsletter.