Supabase rachète Turso parce que les agents ont besoin d'une base de données par tâche

Supabase a annoncé le 2 octobre avoir levé 150 millions de dollars et racheter Turso, une société de bases de données fondée sur SQLite. Le tour a été mené par GIC, le fonds singapourien, avec la participation de CapitalG, le fonds de croissance d'Alphabet, d'IronArc et de SquarePeg. Le montant de l'acquisition n'a pas été divulgué, et l'annonce de financement ne doit pas être interprétée comme le prix d'achat.

Le pari architectural qui sous-tend l'opération est la partie intéressante. Supabase a bâti son activité autour de Postgres, un système relationnel conçu pour des applications qui partagent un même dépôt cohérent. Turso a réécrit SQLite de zéro et supprimé sa contrainte d'écriture unique, puis l'a livré via une architecture sans disque, le journal de pré-écriture (write-ahead log) étant conservé sur S3. Le résultat : une base de données qui peut être provisionnée à la demande, par agent, pour une fraction du coût de l'instanciation d'une machine pour chacun d'eux.

Les chiffres avancés par Supabase

Supabase affirme qu'il accueille désormais plus d'un million d'utilisateurs et environ quatre millions de bases de données chaque mois. L'entreprise indique qu'environ 70 % des nouvelles bases de données de la plateforme sont créées par des agents ou des outils pilotés par l'IA. En juin, elle faisait état d'une augmentation de 600 % d'une année sur l'autre du nombre de bases de données et affirmait que les agents étaient déjà responsables de la plupart des nouveaux déploiements. La société déclare que plus de 13 millions de développeurs utilisent la plateforme.

Il s'agit de chiffres d'adoption rapportés par l'entreprise, et la création de bases de données n'est pas la même mesure que le chiffre d'affaires ou la rétention. Une base de données qu'un agent instancie pour une tâche et abandonne une heure plus tard compte tout de même dans ce total mensuel. Ce que ces chiffres montrent, c'est la forme de la courbe de la demande : le volume de bases de données créées croît plus vite que le nombre d'humains qui les créent, ce qui est précisément le signal qu'un modèle de base de données par application est sous tension.

Pourquoi une base de données par agent casse l'ancienne arithmétique

L'unité d'infrastructure est en train de changer. Lorsqu'un développeur humain construit une application, une seule base de données sert de nombreux utilisateurs, et le coût de son provisionnement est amorti sur un projet de longue durée. Lorsqu'un agent exécute une tâche, il peut avoir besoin de son propre espace de stockage temporaire pour l'état, la mémoire ou les résultats intermédiaires, et il peut n'en avoir besoin que quelques minutes.

Provisionner une instance par agent dans un modèle de base de données managée classique ne fonctionne pas à cette échelle. La surcharge liée à l'allocation d'un serveur, à sa configuration et à sa facturation éclipse la valeur de la petite charge de travail qui s'y exécute. L'argument de Turso est qu'une base de données devrait coûter presque rien à créer et presque rien à laisser inactive, de sorte que lancer un million de bases soit une opération banale plutôt qu'un événement comptable.

Parmi les clients de Turso cités par Supabase figurent Superhuman, CTO.new, Sauna.ai et Mastra. Le fondateur de Turso, Glauber Costa, rejoint Supabase en tant que Head of Agentic Services, aux côtés du cofondateur Pekka Enberg et du reste de l'équipe.

Un détail mérite d'être signalé à quiconque utilise déjà Turso. L'ancien fork libSQL de l'entreprise et son moteur Rust plus récent sont des implémentations différentes, et les deux n'offrent pas le même ensemble de fonctionnalités. Turso a expliqué cette transition dans une annonce de réécriture en janvier 2025. Une équipe devrait vérifier sur quel moteur tourne son déploiement avant de supposer qu'une fonctionnalité listée sur la page marketing est disponible en production.

La concurrence visée

L'acquisition clarifie aussi ce à quoi Supabase se mesure. Son offre payante comprend l'authentification, le stockage, les fonctions edge, les abonnements temps réel et la recherche vectorielle, ce qui la place face à Firebase, MongoDB Atlas et AWS Aurora sur le marché du backend managé, plutôt que face à un seul fournisseur de bases de données.

Chacun d'eux présente une faiblesse différente au niveau de la couche agent. Firebase lie les développeurs à un modèle documentaire et au cloud de Google. MongoDB Atlas modélise les données de façon flexible, mais facture un cluster plutôt qu'une unité de travail d'agent. Aurora est puissant et coûteux à petite échelle, avec un provisionnement qui ne convient pas à une tâche qui ne dure que quelques minutes.

L'apport de Turso, c'est la plus petite unité de stockage possible. Elle offre des écritures concurrentes, une recherche vectorielle native et une exécution dans le navigateur, ainsi qu'une réplication embarquée entre les appareils et le cloud. Cette dernière capacité compte pour une catégorie d'applications qui s'exécutent en partie sur la machine de l'utilisateur, où un aller-retour vers une base de données cloud ne correspond pas à la forme du problème.

Le parcours de montée en gamme est le mécanisme commercial. Un projet qui commence comme une simple base SQLite et devient une véritable application migre vers Postgres, et avec lui vers une offre payante. L'argument de Supabase est qu'il est moins coûteux de capter le projet au moment où un agent le crée que d'acquérir le développeur plus tard.

L'historique de financement est un signal en soi

Ce tour intervient quatre mois après la clôture par Supabase d'une série F de 500 millions de dollars en juin 2026, qui valorisait l'entreprise à 10,5 milliards de dollars post-money et était également menée par GIC. Ce tour faisait suite à une série E de 100 millions de dollars en octobre 2025, sur une valorisation de 5 milliards de dollars. Le capital total levé dépasse désormais le seuil du milliard de dollars.

Une nouvelle levée aussi rapprochée suggère que l'entreprise voulait soit du capital, soit un titre dans l'actualité, et le communiqué indique qu'une partie du tour apporte des liquidités aux employés. Une composante secondaire destinée au personnel est normale à ce stade, et il convient de la distinguer de la trésorerie opérationnelle qu'une entreprise déploie réellement.

La logique stratégique est plus claire que la logique financière. Supabase veut être l'endroit vers lequel un développeur ou un agent se tourne en premier lorsqu'un projet a besoin d'un backend. Si la première version de ce projet est une minuscule base SQLite créée par un agent, alors maîtriser le moment de la création revient à maîtriser la relation avant même qu'un concurrent voie le projet. À partir de là, Supabase propose un parcours de montée en gamme vers Postgres standard lorsqu'une application dépasse le niveau léger. Turso continue de fonctionner comme plateforme, et son code reste open source.

Le schéma de consolidation

Supabase n'est pas seul à faire ce mouvement. Restate a levé ce mois-ci une série A de 20 millions de dollars menée par Singular pour une infrastructure durable qui empêche les workflows d'agents de longue durée d'échouer en cours de tâche. LlamaIndex a lancé un outil d'extraction de documents basé sur des schémas, destiné aux pipelines de données d'agents. Le thème commun à ces opérations est que la plomberie qui sous-tend les agents devient une catégorie à part entière, et que les éléments qui étaient auparavant une réflexion après coup sont désormais financés.

Pour les constructeurs, la question pratique est de savoir ce qui change. On assure aux utilisateurs actuels de Supabase qu'ils ne verront aucune différence, ce qui est la bonne réponse pour une plateforme qui fait désormais tourner deux moteurs sous un même toit. Le changement le plus lourd de conséquences concerne les choix par défaut. Si Postgres et SQLite vivent dans le même écosystème, choisir entre les deux devient une décision liée à la forme de la charge de travail plutôt qu'au fournisseur, et l'option bon marché devient disponible au moment où un agent en a besoin, plutôt qu'après un cycle d'achat.

La question reste ouverte de savoir si l'économie tient. Un modèle de base de données par agent n'est viable que si les coûts de stockage, de provisionnement et de support restent inférieurs au prix qu'un client est prêt à payer, et si un nombre suffisant de ces bases de données évolue vers des charges de production payantes. Supabase a parié que la réponse est oui, et que les projets qui méritent d'être conservés commenceront petits.