database.build: A PGlite-Powered In-Browser Postgres Sandbox with AI Assistance

What database.build Does and Who It Is For

database.build lets anyone create a Postgres database in a browser tab with no account and no server configuration. Each database is independent and persists across page refreshes because data is stored in IndexedDB. Creating multiple databases is supported, each running as a separate instance.

The tool is for developers who want a Postgres sandbox for quick schema experiments, for data analysts who receive CSV files and want to query them immediately, and for anyone who wants to demonstrate or prototype a database design without access to a hosted database service. It is also a reference implementation for how PGlite can be embedded in a web application alongside an LLM.

How Postgres Runs in the Browser: PGlite and IndexedDB

The engine behind database.build is PGlite, a WebAssembly build of Postgres that runs entirely within the browser process. The README states explicitly that there is no remote Postgres container and no WebSocket proxy for query execution. Queries run against a local WASM instance.

Persistence works through IndexedDB, the browser's built-in structured storage API. When the page is refreshed or closed and reopened, the database state is recovered from IndexedDB. Each new database in database.build creates a new PGlite instance.

One application in the monorepo, `apps/browser-proxy`, handles a different scenario: it proxies Postgres TCP connections back to the browser using pg-gateway and WebSockets. This allows a standard Postgres client to connect to the in-browser database as if it were a remote server.

The LLM Integration: CSV Import, Reports, and Diagrams

Each database in database.build is paired with an LLM. The README describes four concrete use cases: dragging and dropping a CSV file to generate a table on the fly, generating and exporting reports, generating charts, and building database diagrams.

The CSV import path uses the LLM to infer column types and generate a CREATE TABLE statement and INSERT statements based on the file's contents. This means a CSV with no predefined schema can be imported as a properly typed Postgres table without manual DDL work.

The local development setup uses OpenAI's API for the LLM component. The setup instructions include creating an OpenAI API key and storing it as `OPENAI_API_KEY` in the web app's environment file.

Running database.build Locally: Setup Steps

The local setup requires Node with npm, Docker for Redis, and a running Supabase instance. From the repository root:

npm i

Then start the local Supabase stack:

npx supabase start

Extract the local Supabase URL and anon key into the web app's environment file:

npx supabase status -o env \
  --override-name api.url=NEXT_PUBLIC_SUPABASE_URL \
  --override-name auth.anon_key=NEXT_PUBLIC_SUPABASE_ANON_KEY |
    grep NEXT_PUBLIC >> ./apps/web/.env.local

Store the OpenAI API key:

echo 'OPENAI_API_KEY="<openai-api-key>"' >> ./apps/web/.env.local

Start Redis for rate limiting on port 8080 with Docker Compose:

docker compose -f ./apps/web/docker-compose.yml up -d

After filling in the remaining variables from each app's `.env.example` file, start the development server with `npm run dev` from the root. The root package.json uses Turborepo to manage build order across the monorepo.

The Monorepo Structure: Three Applications

The repository is organized as a Turborepo monorepo with three applications in `apps/` and shared code in `packages/`.

The primary application, `apps/web`, is a Next.js frontend. It handles the database creation interface, the AI chat interaction, and the query editor. The Turbo configuration in `turbo.json` defines the relationship between the packages, so running `npm run dev` from the root correctly builds shared packages before starting the apps.

The browser proxy application, `apps/browser-proxy`, exposes a WebSocket endpoint that translates standard Postgres TCP protocol connections into calls to the PGlite instance running in the browser. This allows external tools like psql or a local GUI client to connect to an in-browser database.

The deploy worker, `apps/deploy-worker`, handles pushing an in-browser database to a hosted platform. The README states that Supabase is currently the supported target. Deployment to S3 is mentioned as forthcoming.

Limitations: API Key Costs, Offline Use, and Export

Running database.build locally requires an OpenAI API key, which means the AI features incur per-token costs against the OpenAI account. The README does not document any alternative local model configuration.

PGlite runs in the browser, which means its performance is constrained by the JavaScript engine and available memory in the tab. Very large tables or complex analytical queries will be slower than they would be on a dedicated Postgres server.

Data stored in IndexedDB is tied to the browser's origin. Moving a database to another machine or browser requires exporting it. The README mentions generating and exporting reports as an LLM-assisted feature, but does not describe a direct database dump or restore mechanism in the current implementation.

The repository has no GitHub releases, meaning there is no versioned stable build to reference for reproducibility.

How database.build Differs from Neon's SQL Editor

Neon is a serverless Postgres service with a web-based SQL editor. Neon's editor connects to a remote database running on Neon's infrastructure, which means queries go through the network to a real server. Database storage and compute are remote.

database.build runs Postgres entirely inside the browser. There is no network round-trip for query execution. This makes it work fully offline for query execution after the initial page load, and means databases are private to the browser session by default with no data leaving the local machine unless the deploy feature is used.

The trade-off is capability: Neon supports extensions, persistent storage on Neon's infrastructure, and connection from external clients as a first-class feature. database.build's PGlite environment is more constrained, as not all Postgres extensions are available in a WASM build.

Maintenance, Rename History, and License

The project was previously known as postgres.new before being renamed to database.build. The README explains the reason: the name postgres.new implied an official affiliation with the Postgres project, which the team wanted to avoid. The URL changed but the repository notes it remains 100% Postgres-focused.

The last push to the repository was on 2026-06-03. The repository is not archived. There are no GitHub releases. The Fly.io deployment configuration files (`fly.browser-proxy.toml`, `fly.deploy-worker.toml`) in the root indicate the browser proxy and deploy worker components are hosted on Fly.io.

The license is Apache 2.0, documented in the root LICENSE file.

Editorial conclusion

database.build is a useful tool for developers who want to test a schema, prototype a query, or explore a CSV file against Postgres without spinning up a server. The hosted version at database.build is immediately accessible. Self-hosting requires an OpenAI API key, a running Supabase stack, a Redis instance for rate limiting, and Node with npm. The last push to the repository was on 2026-06-03, and there are no GitHub releases; track the main branch for the latest code. Apache-2.0 licensing applies. The deploy-to-S3 feature mentioned in the README was listed as forthcoming as of the last repository update.

Frequently asked questions

Official sources

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