Les bases de données migrent vers le Edge — Turso, Neon et Cloudflare D1 réécrivent l'emplacement de vos données

Pendant la majeure partie de l'histoire des bases de données, la question de l'emplacement de votre base de données avait une réponse simple : dans un centre de données, probablement une ou deux régions pour la redondance, accessible à vos serveurs d'application via un réseau privé rapide. La base de données est centrale. Tout s'y connecte. La latence entre votre application et votre base de données se mesure en sauts réseau inférieurs à la milliseconde au sein de la même installation.

Le problème de ce modèle est qu'il ne tient pas compte de l'emplacement de vos utilisateurs. Si vos serveurs d'application sont dans us-east-1 et qu'un utilisateur à Singapour fait une requête, cette requête voyage de Singapour à la Virginie et retour — environ 200 millisecondes de latence aller-retour avant même d'avoir envisagé les requêtes de base de données. Les plateformes Serverless modernes et les Edge Runtimes ont rapproché le code applicatif des utilisateurs : Cloudflare Workers s'exécute dans plus de 300 emplacements, Vercel Edge Functions se déploie dans des dizaines de régions. Mais la plupart des applications interrogent encore une seule instance Postgres ou MySQL située dans une région, annulant le bénéfice de latence de l'exécution Edge dès qu'un appel de base de données est effectué.

Les bases de données Edge tentent de résoudre ce problème en déplaçant les données elles-mêmes — ou du moins les données fréquemment consultées — plus près des utilisateurs.

Les principaux concurrents

Turso est construit sur libSQL, un Fork de SQLite avec Replication ajoutée. L'architecture est simple : une base de données primaire stocke la copie autorisée de vos données, et Turso la réplique automatiquement vers des emplacements Edge proches de vos utilisateurs. Les lectures touchent la Replica la plus proche ; les écritures vont vers la primaire. Turso a déployé des réplicas Edge dans des dizaines de régions et fait ressembler le tout à une connexion SQLite standard du point de vue du développeur. Le modèle de prix est agressif — un niveau gratuit généreux, puis une tarification par base de données. Pour les applications avec de nombreux locataires isolés (produits SaaS où chaque client a sa propre base de données), le modèle de Turso est convaincant : vous pouvez avoir des milliers de bases de données pour très peu d'argent, chacune colocalisée près de son utilisateur principal.

Neon adopte une approche différente : c'est du Postgres Serverless, avec stockage et calcul séparés. Le calcul se réduit à zéro lorsqu'il n'est pas utilisé (éliminant les coûts d'inactivité) et monte en charge en quelques secondes lorsque le trafic arrive. La couche de stockage est durable, multi-locataire et répliquée globalement au niveau des blocs. Les réplicas de lecture peuvent être déployées dans n'importe quelle région. L'expérience développeur est très proche du Postgres standard — chaînes de connexion, psql, tous les outils habituels fonctionnent — ce qui réduit considérablement la friction de migration. La fonctionnalité de Branching de Neon, qui crée des instantanés instantanés Copy-on-Write de votre base de données pour le développement ou les tests, a été largement saluée.

Cloudflare D1 est également basé sur SQLite et profondément intégré à Cloudflare Workers. L'argument est simple : votre script Worker s'exécute sur le Edge, et D1 est juste là avec lui. Pour les requêtes qui ne nécessitent pas de cohérence globale, D1 élimine complètement le trajet aller-retour vers une base de données centrale. D1 est actuellement limité en fonctionnalités par rapport à un Postgres complet — pas de support de clé étrangère prêt à l'emploi, limité au système de types de SQLite — mais il est véritablement rapide pour les lectures lorsqu'il est colocalisé avec le Worker Edge traitant la requête.

PlanetScale mérite une mention pour une raison différente : il a annoncé en 2024 qu'il mettait fin à son niveau gratuit et se recentrait sur les clients entreprises. Plusieurs développeurs qui avaient construit des projets sur le service compatible MySQL de PlanetScale se sont empressés de migrer, et beaucoup ont atterri chez Neon ou Turso. L'architecture basée sur Vitess de PlanetScale offrait une mise à l'échelle horizontale à un prix qui s'est avéré insoutenable. L'épisode a été un rappel utile que les services de bases de données gratuits ne sont pas une base garantie.

Le problème de cohérence

Les bases de données Edge font un véritable compromis : distribuer les données pour des lectures à faible latence rend la cohérence forte plus difficile à garantir. Ce n'est pas un problème nouveau — le théorème CAP est un pilier de l'enseignement des systèmes distribués depuis deux décennies — mais il devient concret dans les conceptions de bases de données Edge d'une manière qui mérite d'être comprise.

Avec les réplicas Edge de Turso, une écriture validée sur la primaire peut prendre quelques centaines de millisecondes pour se propager à toutes les réplicas Edge. Si un utilisateur écrit des données et les lit immédiatement, et que la lecture touche une réplica qui n'a pas encore reçu l'écriture, il voit des données obsolètes. Pour de nombreuses applications — un blog, un catalogue de produits, un fil social — c'est acceptable. Pour les applications où la cohérence est critique — une transaction financière, une mise à jour de stock avec des contraintes strictes — ce ne l'est pas.

Neon gère cela différemment. Ses réplicas de lecture peuvent être configurées comme synchrones (cohérentes garanties) ou asynchrones (latence plus faible, potentiellement obsolètes). La plupart des applications peuvent utiliser des réplicas asynchrones pour les chemins à forte lecture et router les écritures et les lectures sensibles à la latence vers la primaire. L'architecture est plus flexible que celle de Turso mais nécessite une réflexion plus explicite sur les requêtes ayant besoin de quel niveau de cohérence.

Le modèle de cohérence de Cloudflare D1 est limité à une seule région : les écritures sur D1 sont immédiatement visibles pour les lectures dans la même région, mais la cohérence globale n'est pas garantie. Les Durable Objects de Cloudflare fournissent une primitive différente pour l'état globalement cohérent, mais les Durable Objects ne sont pas une base de données relationnelle.

La convergence vers SQLite

Un motif frappant dans le paysage des bases de données Edge est le nombre de ces produits qui convergent vers SQLite comme moteur de stockage sous-jacent. libSQL de Turso, Cloudflare D1, la base de données intégrée de Bun, et plusieurs autres utilisent SQLite ou un dérivé. Les raisons sont pratiques : SQLite est extrêmement rapide pour les charges de travail à un seul écrivain, il est intégré dans le processus applicatif (pas de serveur séparé), et il est extraordinairement bien testé. Le défi a toujours été la Replication, que SQLite standard ne supporte pas — libSQL, LiteFS et des projets similaires travaillent à combler ce vide.

L'émergence de SQLite en tant que moteur de base de données de production sérieux — au-delà de son rôle traditionnel de magasin local embarqué — est l'une des tendances d'infrastructure les plus intéressantes de ces dernières années. Il fonctionne sur tout, des appareils IoT aux fonctions Serverless Edge, et sa simplicité est de plus en plus une fonctionnalité plutôt qu'une limitation.

Quand l'utiliser

Les bases de données Edge sont adaptées aux applications où les utilisateurs sont distribués mondialement, les charges de travail à forte lecture sont la norme, et la cohérence éventuelle est acceptable pour la plupart des requêtes. Les produits SaaS avec des bases de données par locataire, les plateformes de contenu avec des audiences mondiales, et les backends API servant des applications mobiles dans de nombreuses zones géographiques sont tous des candidats raisonnables.

Elles sont moins adaptées aux applications avec des transactions complexes, des exigences strictes de cohérence entre de nombreux utilisateurs, ou des charges de travail analytiques lourdes. Un grand livre financier, un système d'inventaire de commerce électronique sous fortes écritures concurrentes, ou un entrepôt de données devraient probablement rester sur une base de données centralisée conventionnelle — au moins jusqu'à ce que l'écosystème des bases de données Edge mûrisse davantage.

La pression sous-jacente qui conduit ce changement ne disparaît pas : les utilisateurs attendent des applications rapides, et les applications rapides ont besoin de données proches des utilisateurs. La catégorie des bases de données Edge est encore jeune, l'outillage est moins mature que Postgres centralisé, et quelques aspérités subsistent. Mais pour la charge de travail appropriée, l'amélioration de la latence est tangible et réelle — et c'est généralement ainsi que commence l'adoption d'infrastructure.