Hyperdrive est un service de pooling de connexions géré qui permet aux Workers de communiquer directement avec des bases de données PostgreSQL – y compris celles utilisant l'extension pgvector pour la recherche vectorielle. En maintenant un ensemble réutilisable de connexions à la base de données à proximité du serveur, Hyperdrive réduit la latence liée au handshake qui entrave depuis longtemps les charges de travail d'IA en périphérie (edge).

Pourquoi les Workers et PostgreSQL entrent en conflit

Les Cloudflare Workers s'exécutent sous forme de fonctions JavaScript éphémères dans des dizaines d'emplacements edge. Chaque requête entrante démarre un nouveau processus, et le modèle habituel consiste à ouvrir une nouvelle connexion TCP vers la base de données backend. PostgreSQL, cependant, attend une connexion stable par processus client et limite le nombre total de connexions simultanées. Il en résulte deux problèmes :

  • Coût de connexion élevé – l'établissement d'une connexion nécessite plusieurs allers-retours pour l'authentification et la négociation du protocole. Ces allers-retours ajoutent de la latence à chaque requête.
  • Limites de connexion – les Workers peuvent monter en charge jusqu'à des milliers d'exécutions simultanées, épuisant rapidement le pool de connexions de PostgreSQL et risquant de faire planter la base de données.

Comment Hyperdrive comble le fossé

Hyperdrive se situe entre un Worker et la base de données, maintenant un pool de connexions persistantes sur un serveur qui est, sur le plan réseau, proche de l'instance PostgreSQL. Du point de vue du Worker, le seul changement est une nouvelle chaîne de connexion. En interne, le proxy réutilise une connexion existante pour chaque requête entrante, éliminant ainsi le coût du handshake.

La configuration est intentionnellement légère :

  1. Exécutez l'interface de ligne de commande Wrangler (l'outil en ligne de commande de Cloudflare) pour créer une instance Hyperdrive, en fournissant l'URL d'origine de la base de données.
  2. Ajoutez le binding Hyperdrive généré au fichier de configuration wrangler.toml.
  3. Utilisez un driver compatible tel que node-postgres dans le code du Worker ; le driver voit le point de terminaison Hyperdrive comme un serveur PostgreSQL classique.

Comme le mot de passe de la base de données ne réside que dans la configuration Hyperdrive, il n'apparaît jamais dans le code source du Worker, ce qui réduit la surface d'attaque.

Conseils pratiques pour la recherche vectorielle

Les charges de travail de recherche vectorielle utilisant pgvector impliquent de grands tableaux de nombres à virgule flottante qui ont tendance à changer à chaque requête. Le comportement par défaut d'Hyperdrive inclut un cache de lecture, ce qui peut entrer en conflit avec des données en mutation constante. Pour maintenir des résultats frais, créez une seconde configuration Hyperdrive avec le cache désactivé.

Les transactions de longue durée sont un autre piège. Maintenir une connexion à la base de données en attendant la réponse d'un modèle d'IA externe occupe un emplacement dans le pool et annule l'intérêt du pooling. Le modèle recommandé est le suivant :

  • Ouvrez une transaction.
  • Exécutez la requête.
  • Validez (commit) immédiatement.
  • Appelez le modèle d'IA en dehors de la transaction.

L'ajustement des paramètres de pgvector (par exemple, le paramètre hnsw.ef_search qui contrôle la précision de la recherche) peut être effectué avec une instruction SET LOCAL à l'intérieur d'une transaction courte. Cela garantit que le changement ne s'applique qu'à la requête actuelle et n'affecte pas les autres Workers partageant le pool.

Les limites qui subsistent

Hyperdrive ne déplace pas la base de données elle-même. Si le serveur PostgreSQL se trouve dans une région cloud distante, la latence sera toujours limitée par cette distance physique. La fonctionnalité « Smart Placement » de Cloudflare peut aider en acheminant les Workers vers le nœud edge le plus proche disposant également d'une instance Hyperdrive, mais elle ne peut pas éliminer l'aller-retour réseau sous-jacent.

La couche de mise en cache, bien qu'utile pour les lectures statiques, échouera fréquemment sur les données vectorielles qui changent à chaque requête. Les développeurs doivent évaluer le compromis entre les succès de cache (cache hits) et la fraîcheur des résultats de recherche.

Quand choisir une alternative

Si une application n'a besoin que du stockage vectoriel pur sans jointures relationnelles, Cloudflare propose un service dédié appelé Vectorize. Vectorize stocke les vecteurs directement à l'edge et élimine le besoin d'un backend PostgreSQL. Hyperdrive reste le meilleur choix lorsque les vecteurs doivent être joints à des tables relationnelles existantes, telles que des profils d'utilisateurs ou des historiques de transactions.

À retenir

Hyperdrive offre aux développeurs edge un outil pratique pour exécuter des recherches vectorielles pilotées par l'IA sans faire exploser les limites de connexion PostgreSQL. Il réduit la latence du handshake, centralise les identifiants et offre un contrôle précis sur la mise en cache et la durée des transactions. Le service n'efface pas la distance fondamentale entre l'edge et la base de données, et les échecs de cache (cache-misses) restent une préoccupation, mais pour les charges de travail nécessitant à la fois des jointures relationnelles et une similarité vectorielle, Hyperdrive est la voie la plus directe vers une pile edge évolutive et à faible latence.