Cloudflare Hyperdrive : Postgres Depuis L'edge

Cloudflare Hyperdrive existe à cause d’un problème précis et peu spectaculaire : un Worker qui tourne dans 200 villes et parle à une seule base Postgres située dans une seule ville est plus lent que la même requête émise depuis un serveur posé juste à côté de cette base. Pas un peu plus lent. Souvent plusieurs fois plus lent, et pour des raisons qui n’ont rien à voir avec la façon dont la requête est écrite.

Le réflexe, quand une application serverless semble poussive, est d’accuser le planificateur de requêtes ou d’ajouter un index. Sur des Workers qui parlent à une base régionale, la requête va généralement très bien. C’est la connexion qui pose problème.

Ce que Hyperdrive corrige réellement : le coût d’établissement d’une connexion à la base, payé à chaque requête sans exception. Une connexion Postgres exige une poignée de main TCP, une négociation TLS et un échange d’authentification avant qu’une seule ligne ne circule, et chacune de ces étapes est un aller-retour entre l’endroit où le Worker s’est réveillé et l’endroit où vit la base. Hyperdrive maintient des connexions chaudes près de votre base et les met en pool, si bien que le Worker emprunte une connexion déjà ouverte au lieu d’en construire une.

Pourquoi un Worker branché directement sur Postgres est lent

Un serveur applicatif classique ouvre un pool de connexions une fois au démarrage et les réutilise pendant toute la vie du processus. Le coût de la poignée de main est payé à l’amorçage, puis étalé sur des millions de requêtes jusqu’à ce que quelqu’un redémarre le service.

Les Workers ne fonctionnent pas ainsi. Chaque invocation est éphémère et peut s’exécuter dans n’importe quel emplacement Cloudflare. Aucun processus de longue durée ne détient de pool, donc sans aide chaque requête paie le coût complet d’établissement, et elle le paie sur la distance qui sépare l’edge de votre base d’origine.

Trois allers-retours avant le premier octet de données, ce n’est pas un problème de réglage. Un utilisateur à Sydney qui atteint un Worker parlant à Postgres à Londres paie cette latence quatre fois : TCP, puis TLS, puis authentification, puis enfin la requête. La requête elle-même prendra peut-être deux millisecondes.

Il existe une seconde défaillance, plus discrète. Postgres alloue un processus backend par connexion et son maximum est fini, en général quelques centaines. Un Worker qui monte à des milliers d’invocations simultanées épuisera ce pool et commencera à collecter des refus de connexion pendant exactement le pic de trafic pour lequel vous aviez construit l’edge.

Ce que Hyperdrive fait à ce sujet

Hyperdrive se place entre le Worker et la base comme un pooler de connexions que Cloudflare opère pour vous. Il maintient des connexions chaudes vers votre origine, de sorte qu’une invocation en emprunte une plutôt que d’en négocier une nouvelle depuis zéro.

Il met aussi en cache les résultats de requêtes. Les lectures qui se répètent peuvent être servies sans toucher l’origine du tout, ce qui transforme une question de latence en question de taux de cache pour une part significative du trafic. Les écritures et tout ce qui n’est pas déterministe passent directement.

La configuration tient dans une chaîne de connexion. Vous enregistrez la base auprès de Cloudflare, vous recevez un binding Hyperdrive, et vous pointez votre pilote Postgres existant vers ce binding au lieu de la base. Le pilote, le SQL et le schéma ne changent pas. Cela compte plus qu’il n’y paraît, car le changement est réversible et vous pouvez le mesurer face à une connexion directe sans rien réécrire.

Les chiffres qui décident si c’est adapté

Vérifié contre la documentation Cloudflare en août 2026, et à revérifier avant de vous engager, car ces valeurs bougent.

Hyperdrive ne facture aucun supplément sur l’un ou l’autre plan , et il n’y a pas de frais de sortie. Ce qui compte comme requête est large : un select, un insert, un update, un delete ou un changement de schéma comptent tous, et les requêtes servies depuis le cache comptent autant que les autres. Le quota quotidien gratuit se réinitialise à minuit UTC.

La documentation des limites indique un délai d’expiration de 15 secondes pour la connexion initiale et un délai d’inactivité de 10 minutes. Le plafond de 60 secondes par requête est celui qui piège les équipes migrant une charge de reporting : une requête analytique qui prend deux minutes dans une tâche planifiée échouera purement et simplement ici.

Quelles bases de données fonctionnent vraiment

Hyperdrive prend en charge PostgreSQL 9.0 à 17.x et MySQL 5.7 à 8.x , auto-hébergés ou managés. MariaDB est couvert par la compatibilité MySQL.

Les fournisseurs managés cités nommément incluent AWS Aurora dans ses variantes compatibles Postgres et MySQL, Neon, Supabase, Timescale, Materialize, CockroachDB et PlanetScale. Les instances managées sur Azure et Google Cloud fonctionnent également.

La contrainte pratique n’est pas le moteur, c’est l’accessibilité réseau. Votre base doit être adressable depuis le réseau de Cloudflare. Une instance Postgres enfermée dans un VPC privé sans point de terminaison public a besoin d’un tunnel ou d’un accord de peering avant qu’Hyperdrive puisse seulement la voir, et cela relève du projet réseau plutôt que du changement de configuration.

Quand Cloudflare Hyperdrive est la mauvaise réponse

Quand les données doivent vivre à l’edge. Si votre schéma d’accès se résume à des recherches clé-valeur, Workers KV est plus rapide et plus simple. Si vous voulez une petite base relationnelle qui vit près du Worker plutôt que dans une seule région, D1 est le produit conçu pour cela. Hyperdrive s’adresse au cas où vous avez déjà Postgres ou MySQL et comptez le garder.

Quand la charge est analytique. Le plafond de 60 secondes et la facturation par requête conviennent au trafic transactionnel. Les longues agrégations appartiennent à un exécuteur de tâches qui parle directement à la base.

Quand vous n’avez pas mesuré. L’échec que nous voyons le plus souvent est une équipe qui ajoute Hyperdrive à une application qui n’a jamais été limitée par ses connexions. Si un Worker est lent parce qu’il émet six requêtes séquentielles là où une seule suffirait, mettre ces six connexions en pool le rend marginalement moins lent et laisse le vrai problème intact.

Cette mesure mérite d’être faite correctement avant tout le reste. Notre comparaison entre Cloudflare Workers et AWS Lambda montre où l’exécution en périphérie gagne vraiment, et Cloudflare D1 traite le cas où déplacer la base vaut mieux qu’accélérer la route qui y mène.

Prendre la bonne décision

Chronométrez une requête de bout en bout sur une connexion directe, puis de nouveau via Hyperdrive, depuis un endroit éloigné de votre base. Si l’écart est faible, votre latence vit ailleurs et vous vous êtes épargné une dépendance. Si l’écart est grand, vous avez trouvé de l’argent bien réel.

Mecanik conçoit et audite des architectures edge via son équipe de développement logiciel , y compris la partie ingrate où quelqu’un mesure ce qui est réellement lent avant que quoi que ce soit ne soit réarchitecturé. Si votre application serverless est plus lente que le serveur qu’elle a remplacé, le chemin de connexion est le premier endroit à examiner.

À lire également : Créer une API Cloudflare Workers : guide serverless 2026 , Cloudflare Queues : tâches de fond en périphérie , Réduire la latence des LLM : caching et stratégies edge et Comment créer une application web en 2026 .

Questions fréquentes

Quel problème Cloudflare Hyperdrive résout-il ? Le coût d’ouverture d’une connexion à la base à chaque requête. Un Worker est éphémère et ne détient aucun pool de connexions, donc sans Hyperdrive chaque invocation paie une poignée de main TCP, une négociation TLS et un échange d’authentification sur la distance qui sépare l’edge de votre base, avant que la moindre donnée ne circule. Hyperdrive garde des connexions chaudes et mises en pool près de l’origine, de sorte que le Worker en emprunte une à la place.

Combien coûte Cloudflare Hyperdrive ? Rien au-delà de votre plan Workers. Il est inclus dans les plans Free et Paid, sans frais séparé ni frais de sortie. Le plan Free autorise 100 000 requêtes de base de données par jour, remises à zéro à minuit UTC, et le plan Paid est illimité. Les select, insert, update, delete et changements de schéma comptent tous comme des requêtes, et les requêtes servies depuis le cache comptent autant que les autres.

Quelles bases de données Hyperdrive prend-il en charge ? PostgreSQL 9.0 à 17.x et MySQL 5.7 à 8.x, auto-hébergés ou managés, MariaDB étant couvert par la compatibilité MySQL. Les fournisseurs cités incluent AWS Aurora, Neon, Supabase, Timescale, Materialize, CockroachDB et PlanetScale, ainsi que les instances managées sur Azure et Google Cloud. La base doit être joignable depuis le réseau de Cloudflare.

Quelles sont les principales limites d’Hyperdrive ? Dix bases configurées par compte sur le plan Free et 25 sur le plan Paid, environ 20 connexions à l’origine par configuration sur Free et 100 sur Paid, une durée maximale de requête de 60 secondes, une taille de réponse en cache de 50 Mo, un délai de 15 secondes pour la connexion initiale et un délai d’inactivité de 10 minutes. Le plafond de 60 secondes par requête est celui qui bloque les charges analytiques.

Faut-il utiliser Hyperdrive ou D1 ? Hyperdrive quand vous avez déjà une base Postgres ou MySQL que vous comptez garder et que le problème est la latence pour l’atteindre. D1 quand vous voulez une base relationnelle qui vit d’emblée sur le réseau de Cloudflare. Les deux résolvent des problèmes différents : l’un accélère la route vers une base existante, l’autre supprime la distance en déplaçant les données.