database.build : un Postgres WASM dans l'onglet, avec un LLM branché dessus
In-browser Postgres sandbox with AI assistance (formerly postgres.new)
En bref
- De quoi s’agit-il ?
- Le dépôt supabase-community/database-build combine PGlite, IndexedDB et un modèle de langage pour créer des bases Postgres jetables dans le navigateur. Voici comment l'ensemble tient debout, et où il coince.
- À qui s’adresse-t-il ?
- database.build s'adresse aux développeurs qui veulent prototyper un schéma ou importer un CSV sans provisionner de serveur, et à ceux qui évaluent PGlite comme cible d'exécution. Il faut passer son chemin si vous avez besoin de rôles, d'extensions serveur ou de plusieurs sessions concurrentes sur la même base : le README ne décrit qu'une instance PGlite par base, stockée dans IndexedDB.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 104 jours.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : une base Postgres jetable sans rien installer
Le README annonce la couleur : « instantly spin up an unlimited number of Postgres databases that run directly in your browser ». Le point important n'est pas la rapidité, c'est l'absence de serveur. Aucun conteneur Postgres distant, aucun proxy WebSocket, selon la formulation du dépôt. Pour un développeur qui veut tester une contrainte de clé étrangère, importer un CSV pour voir à quoi ressemblent les données, ou dessiner un schéma avant de le committer, provisionner une instance devient un coût inutile. Le public visé est donc double : celui qui explore un modèle de données, et celui qui veut montrer quelque chose à quelqu'un d'autre sans lui envoyer un dump. La mention « (and soon, deploy them to S3) » indique que la persistance au-delà du navigateur n'est pas encore la promesse tenue, seulement une direction affichée.
PGlite, IndexedDB et le proxy TCP : la mécanique réelle
Le README est explicite sur le mécanisme : « Every database that you create spins up a new instance of PGlite that exposes a fully-functional Postgres database. Data is stored in IndexedDB so that changes persist after refresh. » PGlite est une compilation WASM de Postgres, et c'est elle qui exécute les requêtes dans l'onglet. La persistance ne passe donc pas par un fichier de données classique mais par IndexedDB, ce qui a une conséquence directe : vider le stockage du navigateur, c'est perdre la base. Le monorepo comporte trois applications. apps/web est l'application Next.js principale. apps/browser-proxy fait quelque chose de moins évident : il « Proxies Postgres TCP connections back to the browser using pg-gateway and Web Sockets ». Autrement dit, un client Postgres classique peut se connecter en TCP à ce proxy, qui retransmet vers l'instance PGlite de l'onglet. C'est le pont entre l'écosystème Postgres habituel et un runtime qui vit dans une page web. apps/deploy-worker, enfin, « Deploys in-browser databases to database platforms (currently Supabase is supported) ». Un seul backend de déploiement est pris en charge à ce jour.
L'LLM comme interface, pas comme moteur de requête
Le README précise que « Each database is paired with a large language model (LLM) », et liste quatre usages : import CSV par glisser-déposer avec génération de table à la volée, génération et export de rapports, génération de graphiques, construction de diagrammes de base. Le modèle ne remplace pas Postgres : il produit du SQL ou des artefacts que PGlite exécute ensuite. Cette séparation est saine, mais elle déplace le risque. Une table générée à partir d'un CSV peut avoir des types approximatifs, et rien dans le matériel fourni ne décrit de validation ou de revue du SQL produit avant exécution. Sur une base jetable, l'erreur coûte peu. Le jour où l'on branche le deploy-worker vers une instance Supabase réelle, elle coûte davantage. Le README ne documente pas de garde-fou à ce niveau, et c'est un manque à noter plutôt qu'à combler par supposition.
Mise en route : les commandes du README
L'installation part de la racine du monorepo. npm i installe les dépendances. Ensuite npx supabase start lance la pile Supabase locale, puis on récupère l'URL et la clé anonyme dans ./apps/web/.env.local via npx supabase status -o env avec les options --override-name api.url=NEXT_PUBLIC_SUPABASE_URL et --override-name auth.anon_key=NEXT_PUBLIC_SUPABASE_ANON_KEY, filtrées par grep NEXT_PUBLIC. Il faut une clé OpenAI à écrire dans le même fichier sous OPENAI_API_KEY. Le rate limiting passe par un Redis local : KV_REST_API_URL="http://localhost:8080" et KV_REST_API_TOKEN="local_token", valeurs que le README demande de reprendre telles quelles. Les conteneurs se lancent avec docker compose -f ./apps/web/docker-compose.yml up -d. Le reste des variables se lit dans ./apps/web/.env.example, ./apps/browser-proxy/.env.example et ./apps/deploy-worker/.env.example. En développement, npm run dev depuis la racine. Un avertissement mérite d'être lu deux fois : cette commande passe par turbo, qui comprend les dépendances entre paquets du monorepo et les construit dans le bon ordre. Si vous contournez turbo, vous devez construire vous-même chaque ./packages/* avant que les ./app/* puissent s'en servir. C'est le genre de détail qui transforme une heure de debug en dix minutes si on l'a lu.
Ce que le navigateur ne fera pas
Le stockage dans IndexedDB est la limite la plus concrète. Une base qui vit dans le stockage d'un navigateur n'est pas une base partagée : le README ne décrit pas de synchronisation entre plusieurs onglets ou plusieurs postes sur la même instance. Les extensions serveur ne sont pas mentionnées non plus, ce qui est cohérent avec un Postgres compilé en WASM. La gestion des rôles et des privilèges, la réplication, les sauvegardes planifiées : rien de tout cela n'apparaît dans le matériel fourni, et il serait imprudent d'affirmer que cela fonctionne. Le deploy-worker lui-même n'a qu'un backend, Supabase. Si votre cible est un Postgres auto-hébergé ou une autre offre managée, le chemin de déploiement n'existe pas encore dans ce dépôt. Enfin, la dépendance à une clé OpenAI signifie que la génération assistée s'arrête sans réseau ou sans quota : le reste de l'application continue, mais la partie qui justifie le nom du projet, non.
Face à un Postgres local ou à un service managé
L'alternative la plus directe reste un Postgres installé localement, lancé avec initdb puis pg_ctl, ou un conteneur Docker. La différence d'approche est nette : un Postgres local vous donne les rôles, les extensions, les connexions concurrentes et un vrai fichier de données sur disque, au prix d'une installation et d'un cycle de vie à gérer. database.build troque ces capacités contre l'absence totale d'installation et une base par onglet. Un service Postgres managé se situe à l'opposé : persistance et accès multi-clients garantis, mais latence réseau et coût dès la première instance. Le créneau de database.build est l'intervalle entre les deux, celui où l'on veut une base pendant vingt minutes pour vérifier une idée. Le browser-proxy est d'ailleurs ce qui rend la comparaison intéressante : il permet de brancher psql ou une bibliothèque cliente existante sur une base qui n'existe que dans un onglet, ce qu'aucun Postgres local ne fait.
Licence, maintenance et coût de mise à jour
Le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et du fichier de licence. Ce texte n'est pas un conseil juridique : pour un usage en entreprise, faites relire la notice Apache-2.0 par qui de droit. Sur la maintenance, le dépôt n'est pas archivé et le dernier push est daté du 3 juin 2026, ce qui indique une activité récente. Aucune release n'a été récupérée, donc il n'existe pas de version étiquetée à épingler : vous suivez la branche main, avec ce que cela implique de suivi manuel. Le coût de mise à jour se concentre sur trois points : la version de PGlite, qui conditionne ce que votre SQL peut faire ; les variables d'environnement, réparties sur trois fichiers .env.example ; et la clé OpenAI, dont le coût d'usage vous incombe à chaque appel. Le renommage depuis postgres.new, expliqué dans le README par le fait que le projet n'est pas un projet Postgres officiel, n'a pas d'incidence technique mais casse les anciens liens et les notes de blog qui pointaient vers l'ancienne URL.
Conclusion éditoriale
database.build s'adresse aux développeurs qui veulent prototyper un schéma ou importer un CSV sans provisionner de serveur, et à ceux qui évaluent PGlite comme cible d'exécution. Il faut passer son chemin si vous avez besoin de rôles, d'extensions serveur ou de plusieurs sessions concurrentes sur la même base : le README ne décrit qu'une instance PGlite par base, stockée dans IndexedDB. Avant d'adopter quoi que ce soit en production, vérifiez trois points précis : le contenu réel de ./apps/web/.env.example, la version de PGlite verrouillée dans le package.json, et le fait que le worker de déploiement ne prend en charge que Supabase d'après la description du monorepo.
Notes de la communauté