Introduction
Pendant des années, la question d'architecture était simple : une application, une base de données. Quelques équipes plus avancées ont ajouté des instances de lecture, mis en place du sharding, opté pour le multi-tenant dans un schéma partagé. Mais le paradigme n'avait pas fondamentalement changé. L'acquisition de Turso par Supabase, annoncée le 2 octobre 2026 en même temps qu'une levée de 150 millions de dollars, marque peut-être la fin de cette ère.
Le chiffre qui résume tout : Supabase provisionne désormais quatre millions de nouvelles bases de données chaque mois. Dont 70 % ne sont pas créées par des développeurs humains, mais par des processus automatisés — pipelines CI, outils d'intégration, scripts d'infrastructure. Ce basculement statistique dit quelque chose de profond sur l'évolution des architectures applicatives, bien au-delà du seul sujet de l'intelligence artificielle.
SQLite, le retour inattendu
Turso n'est pas simplement un hébergeur de bases de données : l'entreprise a construit libSQL, un fork de SQLite réécrit en Rust, qui maintient une compatibilité totale avec le format et l'API d'origine tout en ajoutant des fonctionnalités critiques pour les déploiements cloud — réplication régionale, mode embarqué, recherche vectorielle native.
L'architecture sous-jacente est là où ça devient intéressant du point de vue ingénierie. Turso a résolu un problème fondamental : comment faire cohabiter des millions de bases de données sur une même infrastructure sans que le coût explose ? Leur réponse tient en un mécanisme de suspension et chargement à la demande — une base inactive ne consomme quasiment rien, et peut être réactivée en quelques millisecondes. C'est exactement le modèle économique qui a rendu les fonctions serverless attractives : vous ne payez que l'usage réel, à la granularité du workload.
Ce que ça change pour les équipes de développement
Le pattern « une base par tenant » n'est pas nouveau — il circule dans les discussions d'architecture depuis des années. Ce qui change, c'est la faisabilité opérationnelle. Jusque-là, provisionner une nouvelle base de données impliquait un processus lourd : configuration, migration de schéma, gestion des connexions, monitoring dédié. Avec un provisionnement en millisecondes et un coût de base à l'arrêt proche de zéro, créer une instance isolée devient aussi simple qu'ouvrir un fichier.
Pour les équipes platform engineering et les développeurs backend, cela soulève des questions concrètes. L'isolation des données entre tenants, souvent gérée par du row-level security dans un schéma partagé, peut s'exprimer différemment. Les migrations de schéma — qui nécessitent des stratégies complexes en contexte multi-tenant — deviennent plus directes quand chaque tenant dispose de sa propre instance. Les stratégies de backup et de restauration s'alignent naturellement sur les limites du tenant. Ce sont des discussions que les architectes vont devoir rouvrir.
Le chemin vers Postgres reste ouvert
Supabase ne remplace pas Postgres par SQLite. La plateforme conserve sa base technique autour de PostgreSQL pour les charges de travail stateful et croissantes. Glauber Costa, cofondateur de Turso, rejoint Supabase en tant que Head of Agentic Services, avec pour mission de construire un pont cohérent entre ces deux mondes : SQLite pour le provisionnement ultra-léger et les workloads éphémères, Postgres pour la montée en charge et les usages pérennes.
Les deux stacks restent open source, ce qui est un signal important pour les équipes qui anticipent une intégration dans leurs propres pipelines. L'engagement de Supabase sur l'open source — la plateforme est elle-même construite sur des briques ouvertes — donne une certaine lisibilité sur la trajectoire du projet.
Un signal architectural à anticiper
Pour les responsables techniques et les architectes, cette opération mérite d'être analysée au-delà du contexte de l'automatisation. L'essor du provisionnement de bases de données à grande échelle suit une courbe similaire à celle des conteneurs il y a dix ans : marginal, puis incontournable en quelques années. Les équipes qui commencent dès maintenant à réviser leurs stratégies de multi-tenancy, à évaluer leurs outils de migration de schéma et à modéliser leur coût par workload auront une longueur d'avance quand ce modèle deviendra la norme de facto.