database.build is an in-browser Postgres sandbox with AI assistance — formerly named postgres.new — for developers who want to spin up disposable Postgres databases without provisioning or paying for a server.

What it is

database.build is an open-source tool, licensed under Apache-2.0 and written in TypeScript, that runs a fully functional Postgres database directly inside the browser tab. It lives in the Postgres and browser-tooling ecosystem and is built on PGlite, a WebAssembly build of Postgres. Every database created in the app starts a new PGlite instance, and data is written to IndexedDB so that changes survive a page refresh. There is no remote Postgres container and no WebSocket proxy sitting between the user and the database — queries execute locally in the browser process.

The concrete problem it replaces is the setup cost of a throwaway Postgres instance. Instead of installing Postgres, running a container, or opening a hosted database just to test a schema, import a CSV, or sketch a diagram, a user gets an unlimited number of databases on demand. The project also carries an LLM alongside each database, which turns those short-lived instances into a workspace for generating tables from dropped CSV files, exporting reports, producing charts, and drawing database diagrams collapsed from the schema.

Repository layout is a monorepo with three applications: apps/web (the Next.js web app), apps/browser-proxy (proxies Postgres TCP connections back to the browser through pg-gateway and WebSockets), and apps/deploy-worker (deploys in-browser databases to database platforms, currently Supabase).

Key capabilities

• Runs real Postgres in the browser through PGlite, a WASM build of Postgres, with no remote container or WebSocket proxy for normal queries.
• Persists database state in IndexedDB so data survives a page refresh.
• Drag-and-drop CSV import that generates the target table on the fly.
• LLM-assisted report generation and export.
• LLM-assisted chart generation from query results.
• Database diagram generation from the existing schema.
• Deployment of an in-browser database to an external Postgres platform via apps/deploy-worker, with Supabase supported today and S3 deployment stated as coming soon.
• Postgres TCP connectivity from external clients via apps/browser-proxy, which bridges pg-gateway over WebSockets.

Who uses it and how

• Individual developers who need an instant scratch Postgres for schema experiments, query testing, or one-off analysis without touching a shared server.
• Teams doing demos and prototyping, since each participant can hold their own unlimited set of databases in the browser instead of sharing one staging instance.
• Data-curious users who want to drop a CSV file in and immediately get a table, a chart, and a report without writing DDL first.
• Users who prototype locally in the browser and then promote the result to a hosted Postgres platform through the deploy worker.
• Tool builders integrating apps/browser-proxy when they need a Postgres endpoint that reaches a browser-hosted database over WebSockets.

Getting started

From the monorepo root, run npm i, start the local Supabase stack with npx supabase start, populate ./apps/web/.env.local with the Supabase URL and anon key, an OPENAI_API_KEY, and the local KV (Redis) values, bring up Redis with docker compose -f ./apps/web/docker-compose.yml up -d, then run npm run dev (which uses turbo to build the ./packages/* dependencies automatically). A hosted version is available at database.build.

How it compares

No comparable products are named in the facts provided, and no list of paid alternatives is supplied, so this project stands alone in this registry on those axes. What the facts do establish is the licence — Apache-2.0 — and the architecture: the database engine runs in the client, not on the vendor's infrastructure.

When to use it — and when not

A self-hoster must operate more than the web app: the development flow expects a local Supabase stack, Redis containers for rate limiting, an OpenAI API key, and environment files for apps/web, apps/browser-proxy, and apps/deploy-worker (see each .env.example). Anyone needing durable server-side Postgres with guaranteed backups, multi-user access control, or stable long-lived connections should not pick this, since storage is browser IndexedDB and the app is explicitly a sandbox; deployment off the browser currently supports Supabase only. The project also carries a recent rename from postgres.new — and states it is not an official Postgres project — so documentation and third-party references may still use the old name.

npm run dev