Hyperdrive pour MySQL : accélérer sans perdre de vue la fraîcheur

Un service web peut consulter sa base de données à chaque affichage : retrouver un article, une disponibilité ou l’état d’un dossier. Réouvrir la connexion à chaque demande ajoute du travail. Hyperdrive sert d’intermédiaire entre une application exécutée sur Cloudflare Workers et une base existante, notamment MySQL. Un Worker est ici un petit programme hébergé sur le réseau Cloudflare. Le 14 octobre 2026, Cloudflare annonce la disponibilité générale de la prise en charge MySQL, après sa phase bêta.

Le service réutilise des connexions à la base au lieu de repartir de zéro pour chaque requête. Il peut aussi conserver temporairement certaines réponses de lecture : c’est le cache. Ces deux fonctions répondent à des questions différentes. La première concerne l’accès à la base ; la seconde permet parfois de répondre avec un résultat déjà obtenu. Désactiver le cache ne supprime pas l’intérêt de la réutilisation des connexions.

Une réponse rapide peut être une réponse plus ancienne

La documentation du cache indique qu’il est activé par défaut pour les lectures éligibles. Les réglages initiaux prévoient 60 secondes de durée de vie, puis une fenêtre de 15 secondes pendant laquelle une ancienne réponse peut encore être servie lors de son actualisation. Ces durées concernent les résultats mis en cache, pas le temps d’attente imposé à un visiteur. Surtout, une écriture dans la base n’efface pas automatiquement les lectures déjà conservées.

Prenons une situation hypothétique : votre application affiche des créneaux disponibles. Une réservation enregistre le dernier créneau libre, puis une lecture demande aussitôt la liste. Si cette lecture peut reprendre une ancienne réponse, l’écran risque de montrer encore le créneau. Il faut alors définir où l’information doit être fraîche et où un léger décalage est acceptable. Le contrôle final de disponibilité doit rester cohérent avec l’enregistrement de la réservation ; une simple accélération de l’affichage ne règle pas cette décision métier.

Pour un premier essai, choisissez une lecture peu sensible, comme un contenu public qui change rarement. Faites comparer le résultat avec et sans cache, puis après une modification autorisée de la donnée de test. Demandez au prestataire d’identifier séparément les lectures liées aux droits d’accès, à une confirmation ou à un état de paiement. La documentation prévoit une configuration sans cache pour les lectures devant être fraîches. Le but du pilote est de vérifier le comportement attendu, au-delà du seul temps d’affichage.

Compter des requêtes, pas des clients

Selon la tarification Hyperdrive, Workers Free comprend 100 000 instructions de base par jour, qu’il s’agisse de lectures ou de modifications, servies depuis le cache ou non. Le compteur repart à zéro à 00:00 UTC et un dépassement fait échouer les opérations concernées. Ce nombre ne représente ni des visiteurs ni des commandes : une seule action peut entraîner plusieurs instructions. L’offre Workers Paid lève ce quota Hyperdrive, mais ne rend pas gratuits l’hébergement de la base et l’ensemble de l’application.

Les limites de connexions à la base constituent encore une autre unité : elles s’appliquent par configuration et ne désignent pas le nombre de personnes connectées au site. Faites inventorier les appels réellement produits par un parcours représentatif, puis les connexions utilisées côté base. La sortie de bêta permet d’étudier le service disponible ; elle ne remplace pas l’examen de sa pertinence pour votre hébergement et votre application actuels.