database.build: Postgres im Browser, mit PGlite und einem LLM daneben

Welches Problem database.build löst und für wen

Wer eine Datenbank nur kurz braucht, um eine CSV-Datei zu prüfen, ein Schema zu skizzieren oder ein Diagramm zu zeichnen, zahlt normalerweise den vollen Preis eines Servers: Container starten, Verbindung konfigurieren, aufräumen. database.build verschiebt diesen Aufwand in den Browser. Laut README lassen sich unbegrenzt viele Postgres-Datenbanken starten, die direkt im Browser laufen. Die Zielgruppe sind damit nicht Betriebsteams, sondern Menschen, die mit Daten arbeiten und dabei schnell zu einem Ergebnis kommen wollen. Das README nennt vier Anwendungsfälle: Drag-and-drop-Import von CSV mit automatisch erzeugter Tabelle, Generierung und Export von Reports, Erzeugung von Charts und Aufbau von Datenbankdiagrammen. Jeder dieser Fälle beginnt mit einer leeren Datenbank und endet mit einem Artefakt, nicht mit einem laufenden Dienst. Wer eine Datenbank für eine Anwendung im Dauerbetrieb sucht, ist hier falsch; das Projekt positioniert sich als Sandbox, und der Name database.build beschreibt genau diese Rolle. Die Umbenennung von postgres.new wird im README damit begründet, dass es sich nicht um ein offizielles Postgres-Projekt handelt.

PGlite in IndexedDB statt Container und Proxy

Die zentrale Entscheidung ist, dass alle Abfragen im Browser ausgeführt werden. Das README formuliert es so: es gibt keinen entfernten Postgres-Container und keinen WebSocket-Proxy. Stattdessen läuft PGlite, eine WASM-Version von Postgres, direkt in der Browser-Umgebung. Jede angelegte Datenbank startet eine eigene PGlite-Instanz, die eine vollständige Postgres-Datenbank bereitstellt. Die Persistenz übernimmt IndexedDB, sodass Änderungen einen Neuladen der Seite überstehen. Dieses Modell hat eine klare Konsequenz: die Datenbank lebt in dem Browserprofil, in dem sie erzeugt wurde. Es gibt keinen Server, der die Daten hält, und damit auch keinen Ort, an dem ein zweiter Rechner ohne Weiteres auf dieselbe Instanz zugreift. Das Monorepo enthält allerdings eine Browser-Proxy-Anwendung, die Postgres-TCP-Verbindungen über WebSockets zurück in den Browser leitet und dafür pg-gateway nutzt. Das README beschreibt diesen Pfad, ohne ihn im Setup durchzuspielen; wer eine native Postgres-Verbindung von außen braucht, muss sich die Konfiguration selbst aus apps/browser-proxy/.env.example erschließen. Ein Deploy-Worker existiert ebenfalls und kann Datenbanken zu Datenbankplattformen ausrollen, aktuell wird laut README Supabase unterstützt. Das README erwähnt außerdem, dass ein Deployment nach S3 geplant ist, was die aktuelle Grenze der Persistenz noch einmal verdeutlicht.

Das LLM als Teil der Datenbank, nicht als Chatfenster daneben

Jede Datenbank ist laut README mit einem großen Sprachmodell gekoppelt. Das ist mehr als eine Oberfläche zum Fragenstellen, denn die vier genannten Anwendungsfälle setzen darauf auf: aus einer CSV-Datei eine Tabelle erzeugen, Reports generieren, Charts bauen, Diagramme zeichnen. Der Mechanismus ist in der Beschreibung implizit: das Modell erhält den Datenbankkontext und erzeugt daraus SQL oder Struktur. Welche Schritte im Einzelnen ablaufen, welche Prompts verwendet werden und wie das Schema an das Modell übergeben wird, geht aus dem README nicht hervor. Wer das beurteilen will, muss den Code in apps/web lesen. Klar ist nur, dass das Setup einen OpenAI-API-Schlüssel verlangt, der in apps/web/.env.local als OPENAI_API_KEY abgelegt wird. Damit ist auch die Datenhaltung berührt: die Sandbox ist lokal, der Modellaufruf nicht. Wer mit Daten arbeitet, die den Browser nicht verlassen dürfen, muss diesen Punkt vor dem ersten Import klären. Ein lokales Modell ist im beschriebenen Setup nicht vorgesehen; das README nennt ausschließlich den OpenAI-Schlüssel.

Vom Klon zum laufenden Stack: die sieben Setup-Schritte

Das README beschreibt das Setup aus dem Monorepo-Wurzelverzeichnis in sieben Schritten. Zuerst npm i für die Abhängigkeiten. Dann npx supabase start für den lokalen Supabase-Stack. Anschließend werden URL und anon key in ./apps/web/.env.local geschrieben, und zwar mit einem Befehl, der die Werte direkt aus npx supabase status -o env bezieht und über --override-name auf NEXT_PUBLIC_SUPABASE_URL und NEXT_PUBLIC_SUPABASE_ANON_KEY umbenennt, gefiltert mit grep NEXT_PUBLIC. Danach folgt der OpenAI-Schlüssel als OPENAI_API_KEY. Für das Rate Limiting kommen zwei KV-Variablen mit festen lokalen Werten hinzu: KV_REST_API_URL auf http://localhost:8080 und KV_REST_API_TOKEN auf local_token. Der zugehörige Redis-Container wird mit docker compose -f ./apps/web/docker-compose.yml up -d gestartet und stellt seine API auf Port 8080 bereit. Der siebte Schritt verweist auf die verbleibenden Variablen in ./apps/web/.env.example, ./apps/browser-proxy/.env.example und ./apps/deploy-worker/.env.example. Für die Entwicklung genügt danach npm run dev. Das README warnt ausdrücklich: dieser Befehl nutzt turbo, das die Abhängigkeiten im Monorepo kennt und die Pakete in ./packages/* automatisch baut. Wer turbo umgeht, muss jedes Paket vor jeder App manuell bauen. Das ist keine Fußnote, sondern der häufigste Stolperstein beim Einstieg in ein Monorepo dieser Form.

Wo die Sandbox an ihre Grenzen stößt

Die erste Einschränkung steckt in der Speicherung. IndexedDB gehört zum Browserprofil, nicht zu einem Server. Ein Wechsel des Geräts, ein gelöschtes Profil oder ein anderer Browser bedeutet den Verlust der Datenbank, sofern sie nicht zuvor über den Deploy-Worker ausgerollt wurde. Das README verspricht, dass Änderungen ein Neuladen überstehen, nicht mehr. Die zweite Einschränkung ist die Modellabhängigkeit. Ohne OPENAI_API_KEY bleibt der zentrale Vorteil, die KI-Unterstützung, außer Betrieb; das Setup verlangt den Schlüssel explizit. Die dritte betrifft den Umfang: das README nennt Supabase als einzige unterstützte Zielplattform für den Deploy-Worker, und das S3-Deployment wird als zukünftige Erweiterung beschrieben. Wer heute auf einen anderen Anbieter ausrollen will, findet dafür im Material keinen Beleg. Viertens ist das Projekt ausdrücklich keine offizielle Postgres-Sache, was das README selbst zum Anlass der Umbenennung nimmt. Wer eine Datenbank mit mehreren gleichzeitigen Schreibern, Zugriffskontrolle und serverseitigen Backups braucht, sollte database.build nicht als Ersatz für eine gehostete Instanz betrachten. Es ist ein Werkzeug zum Ausprobieren und Erzeugen, nicht zum Betreiben.

Was eine gehostete Postgres-Instanz anders macht

Der naheliegende Vergleich ist eine gehostete Postgres-Instanz, etwa der lokale Supabase-Stack, den database.build im Setup ohnehin startet. Der Unterschied liegt nicht in der SQL-Schicht, denn beide führen Postgres aus, sondern im Ort der Daten und im Lebenszyklus. Eine gehostete Instanz hält die Daten unabhängig vom Browser, erlaubt Verbindungen von mehreren Clients und überlebt das Schließen eines Tabs. database.build dreht das um: die Datenbank existiert nur, solange das Browserprofil existiert, und der Zugriff erfolgt über die Weboberfläche. Die Browser-Proxy-Anwendung mit pg-gateway und WebSockets ist der Versuch, diese Grenze zu mildern, indem TCP-Verbindungen zurück in den Browser geleitet werden. Damit wird der Browser zur Datenbank, nicht der Server. Für den skizzierten Anwendungsfall ist das ein Vorteil, weil kein Container verwaltet werden muss. Für alles, was einen zweiten Nutzer, einen Cronjob oder eine Anwendung mit dauerhafter Verbindung einschließt, ist es der falsche Ansatz. Der Deploy-Worker ist die Brücke zwischen beiden Welten: er schiebt eine im Browser erzeugte Datenbank auf eine Plattform. Das README beschreibt ihn, ohne den Ablauf im Detail zu erklären, sodass die Frage, welche Objekte übertragen werden und was dabei verloren geht, offen bleibt.

Wartung, Monorepo und Apache-2.0

Der letzte Push auf den main-Branch datiert auf den 3. Juni 2026, das Repository ist nicht archiviert. Releases wurden für diese Auswertung nicht abgerufen, sodass sich Versionsstände nicht beurteilen lassen. Der Wartungsaufwand beim Selbsthosten ergibt sich aus dem Monorepo: drei Anwendungen unter apps/ und mehrere Pakete unter packages/, die über turbo zusammenhängen. Das README macht klar, dass ein Umgehen von turbo manuelle Builds jedes Pakets erfordert. Wer die Anwendung selbst betreibt, übernimmt damit auch die Pflege des Supabase-Stacks, des Redis-Containers für das Rate Limiting und der OpenAI-Anbindung. Das sind drei bewegliche Teile, die unabhängig voneinander aktualisiert werden. Die Lizenz ist Apache-2.0, also eine permissive Lizenz mit einer ausdrücklichen Patentgewährung und den üblichen Pflichten zur Beibehaltung von Copyright- und Lizenzhinweisen sowie zur Kennzeichnung geänderter Dateien. Wer die Anwendung weiterverbreitet oder verändert, sollte diese Hinweise prüfen; das ist keine Rechtsberatung, sondern ein Hinweis auf die Stellen, an denen die Lizenz greift. Ob der Name database.build oder die frühere Bezeichnung postgres.new in eigenen Forks weiterverwendet werden darf, regelt die Lizenz nicht, weil Markenrechte außerhalb ihrer Reichweite liegen.

Für wen sich der Einstieg lohnt und was zuerst zu prüfen ist

Der Aufwand für den Einstieg ist überschaubar, aber nicht trivial. Sieben Setup-Schritte, ein OpenAI-Schlüssel, ein Supabase-Stack und ein Redis-Container stehen zwischen dem Klon und der ersten Datenbank. Wer diesen Aufwand scheut, kann die gehostete Instanz unter database.build nutzen, ohne etwas zu installieren. Wer selbst hostet, sollte mit npm i und npx supabase start beginnen und danach die drei .env.example-Dateien vollständig ausfüllen, bevor npm run dev gestartet wird. Besonders die Dateien für browser-proxy und deploy-worker sind im README nur als Verweis vorhanden. Wer die KI-Funktionen nicht braucht, kann auf den OpenAI-Schlüssel verzichten, verliert dann aber genau die Funktionen, die das Projekt von einer gewöhnlichen Postgres-Instanz unterscheiden. Wer Daten mit externem Modellaufruf nicht teilen darf, sollte vor dem ersten Import prüfen, welche Inhalte an das Modell gehen. Und wer eine Datenbank für den Dauerbetrieb sucht, sollte beim Deploy-Worker ansetzen, weil die Sandbox im Browserprofil endet.

Redaktionelles Fazit

Wer schnell CSV-Dateien in Tabellen verwandeln, Diagramme erzeugen oder Reports ausprobieren will, ohne einen Server aufzusetzen, findet in database.build ein passendes Werkzeug, vorausgesetzt, ein OpenAI-Schlüssel und die lokale Supabase- und Redis-Umgebung stehen bereit. Wer persistente Mehrbenutzer-Datenhaltung, serverseitige Backups oder Daten ohne LLM-Kontakt braucht, sollte es nicht als Produktionsdatenbank einsetzen. Vor dem ersten Start sind die drei .env.example-Dateien in apps/web, apps/browser-proxy und apps/deploy-worker zu prüfen, weil das README nur die Variablen für Web auflistet und die übrigen Apps ausdrücklich dem Leser überlässt.

Offizielle Quellen

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. supabase-community/database-build on GitHub