Supabase prépare son infrastructure à l’essor des applications créées par l’intelligence artificielle

EElias

D’après la lettre Latent Space, les cofondateurs de Supabase, Paul Copplestone et Ant Wilson, disent que la multiplication des logiciels créés par des agents d’intelligence artificielle modifie les besoins des infrastructures backend. Leur discussion porte sur la manière d’adapter les systèmes qui accompagnent ces logiciels, et pas seulement sur la génération du code. Ils abordent notamment les charges de travail exécutées près de la base de données, la fiabilité de Postgres et la capacité de cette base à monter en charge. Ils parlent aussi de schémas déclaratifs conçus pour être plus faciles à comprendre par les agents. Ce sont les axes évoqués dans l’entretien, enregistré avant l’événement Supabase Select 2026. Il s’agit donc d’une réflexion sur les besoins d’infrastructure associés à davantage d’applications créées par des agents, et non d’un bilan chiffré de leur déploiement ou de leurs performances.

EElias

Supabase Compute permet d’exécuter des charges de travail à proximité de la base de données. C’est l’une des pistes présentées dans l’entretien pour adapter l’infrastructure à un contexte où les agents produisent davantage de logiciels. Les cofondateurs abordent également les charges de travail qui fonctionnent pendant une longue durée, ainsi que la fiabilité de Postgres. L’entretien ne donne pas de mesure de performance associée à Supabase Compute, ni de comparaison avec une autre architecture. Il ne précise pas non plus les tarifs ou les conditions d’accès à cet outil. On peut donc décrire sa fonction telle qu’elle est présentée : exécuter des charges de travail près de la base de données. Les effets concrets de cette approche ne sont pas chiffrés dans les éléments de l’entretien.

EElias

Les discussions concernent notamment Postgres, que les cofondateurs abordent sous l’angle de la fiabilité et de la montée en charge. Un autre nom cité est Multigres, une infrastructure Postgres hautement disponible. Le projet est en alpha privée, ce qui signifie que l’entretien ne le présente pas comme un produit disponible à tous. Les éléments disponibles ne donnent ni tarif, ni capacité maximale, ni résultat mesuré pour cette infrastructure. Ils ne précisent pas davantage les conditions d’accès à cette phase privée. Il faut donc distinguer le projet décrit de ses éventuels résultats : son objectif annoncé concerne la haute disponibilité, tandis que son stade est celui d’une alpha privée. L’échange inscrit Multigres dans une discussion plus large sur la fiabilité de Postgres, sans fournir de bilan de fonctionnement en production.

EElias

Les éléments rapportés décrivent des sujets de travail, mais ne fournissent pas de résultats chiffrés permettant d’évaluer leur effet. C’est notamment le cas pour la fiabilité et la montée en charge de Postgres : ces thèmes sont abordés, sans qu’une capacité ou une amélioration précise soit donnée. L’entretien évoque aussi des schémas déclaratifs conçus pour être compréhensibles par les agents. Il ne présente pas de mesure montrant comment ces schémas influencent leur fonctionnement, ni de résultat permettant de comparer différentes méthodes. Alors, il faut garder la distinction entre une orientation technique et une performance démontrée. Supabase Compute a une fonction décrite, et Multigres est identifié comme une infrastructure hautement disponible en alpha privée, mais aucun chiffre de résultat n’est fourni. Les éléments présentés ne permettent donc pas de conclure que les enjeux de fiabilité ou de montée en charge sont résolus.

EElias

L’entretien aborde également Turso, l’open source et l’usage de l’intelligence artificielle en interne chez Supabase. Il mentionne l’acquisition de Turso et une possibilité de développement à grande échelle, sans détailler les modalités de l’opération dans les faits rapportés ici. Les schémas déclaratifs, eux, sont présentés comme conçus pour être plus faciles à comprendre par les agents. Ces thèmes s’ajoutent aux questions de Postgres, de fiabilité et de charges de travail proches de la base de données. Le fil conducteur, formulé par les cofondateurs, est la transformation des besoins d’infrastructure liée à la multiplication des logiciels créés par des agents. Supabase Compute et Multigres sont deux projets mentionnés dans ce contexte, avec des fonctions et des stades différents. En fait, le point à retenir est que Supabase décrit plusieurs axes de travail, mais que l’entretien ne donne pas de bilan chiffré de leurs effets pour les utilisateurs.