database.build: A Browser-Resident Postgres Sandbox with AI Assistance

What database.build Solves and Who It Serves

database.build addresses the friction of spinning up a Postgres database for experimentation. Traditionally, you need a local install, a Docker container, or a cloud instance, all of which take time and configuration. This project eliminates that overhead by running Postgres entirely in the browser. The README states that you can 'instantly spin up an unlimited number of Postgres databases that run directly in your browser.' That promise targets developers who want to test SQL queries, data analysts who need to explore CSV files without setting up a server, and educators who want to demonstrate Postgres concepts without requiring students to install software. The AI pairing adds another layer: a large language model sits next to each database, enabling natural-language interactions like generating tables from a CSV drag-and-drop or producing charts and reports. The project is not aimed at production database workloads; it is a sandbox for exploration and learning.

Under the Hood: PGlite, WASM, and IndexedDB

The core mechanism is PGlite, a WebAssembly build of Postgres that runs client-side. The README explains: 'All queries in database.build run directly in your browser. There’s no remote Postgres container or WebSocket proxy.' Each database you create instantiates a new PGlite instance, exposing a fully functional Postgres database. Persistence is handled by IndexedDB, so your data survives page refreshes. This architecture is radically different from a typical hosted Postgres service. There is no network round-trip for queries, which means low latency but also means the database lives and dies with the browser tab. The browser proxy app in the monorepo can forward Postgres TCP connections to the browser via pg-gateway and WebSockets, which is useful for connecting external tools, but the default experience is self-contained. For anyone who has wrestled with local Postgres setup, this approach is a genuine time-saver, but it also introduces a hard boundary: if the browser is closed or the IndexedDB is cleared, the data is gone unless you explicitly export or deploy it.

Getting Started: Installation and Local Development

The repository is a monorepo with three main applications: a Next.js web app, a browser proxy, and a deploy worker. To run it locally, the README provides a sequence of commands. First, install dependencies with `npm i` from the root. Then start a local Supabase stack using `npx supabase start`, and capture the URL and anon key into `./apps/web/.env.local` with a command that uses `npx supabase status -o env`. You also need an OpenAI API key, which you add as `OPENAI_API_KEY` in the same env file. For rate limiting, the setup stores Redis variables with exact values: `KV_REST_API_URL="http://localhost:8080"` and `KV_REST_API_TOKEN="local_token"`. Then you start local Redis containers via `docker compose -f ./apps/web/docker-compose.yml up -d`. Finally, you fill in remaining variables from the `.env.example` files in each app. Development is initiated with `npm run dev`, which uses Turbo to handle inter-package dependencies. The README warns that bypassing Turbo means you must manually build each package in `./packages/*` before the apps can use them. This setup is not trivial; it requires Node, Docker, a Supabase CLI, and an OpenAI account, so the barrier to contributing is higher than simply cloning and running.

The AI Assistance: What It Actually Does

The README lists specific AI-driven features: drag-and-drop CSV import that generates a table on the fly, generating and exporting reports, generating charts, and building database diagrams. These are not just remote API calls; the LLM is paired with each in-browser database, meaning the model likely has access to the schema and can generate SQL or visualizations based on the data. The exact implementation details are not in the README, so it is unclear whether the AI runs locally or calls an external API (the setup requires an OpenAI key, which suggests a remote call). This is a point to verify if you plan to use the AI features extensively. The value proposition is clear: instead of writing SQL manually, you can ask questions in natural language and get results. However, the AI is only as good as the model and the context it receives. There is no mention of model selection, prompt tuning, or offline support, so you should expect variability in output quality and a hard dependency on the OpenAI API being available.

The Rename and the Project's Honest Positioning

The project was originally named postgres.new, but the team renamed it to database.build. The README explains: 'This project is not an official Postgres project and we don’t want to mislead anyone! We’re renaming to database.build because, well, that’s what this does.' This is a refreshingly candid statement. It shows the maintainers are aware of potential confusion with the official Postgres project and want to set expectations. The new name emphasizes the building aspect rather than implying a Postgres service. This honesty is a good sign for adoption, as it clarifies that this is a community tool, not a product endorsed by the Postgres developers. However, the rename also means that any documentation or tutorials referencing postgres.new may be outdated, and you should look for database.build resources.

Real Limitations and When It Is the Wrong Tool

The most obvious limitation is that the database is ephemeral and browser-bound. IndexedDB persistence works only as long as the user stays in the same browser and does not clear site data. If you need to share a database with colleagues or run a long-lived service, this is the wrong tool. The README mentions a deploy worker that can push databases to platforms like Supabase, but that is listed as 'soon' and currently supports only Supabase. So production use requires an extra step and is not yet fully realized. Another limitation is the AI dependency: you need an OpenAI API key, which costs money and requires internet. If you are in an offline environment or want to avoid third-party APIs, the AI features will not work. Also, the setup for local development is complex, requiring multiple services (Supabase, Redis, Docker), which may deter contributors who just want to try the hosted version at database.build. Finally, the project has no recent releases listed, so you are relying on the main branch for stability, which is a risk for production adoption.

Alternatives and How They Differ

The most direct alternative is running Postgres locally via a traditional installation or Docker. That approach gives you a persistent, server-grade database with full control, but it requires setup and maintenance. In contrast, database.build offers zero-install convenience but sacrifices persistence and server features. Another alternative is a hosted database service like Supabase itself, which provides a managed Postgres instance with a web UI and API. That gives you durability and scalability, but you pay for the infrastructure and have network latency. A closer conceptual alternative is PGlite standalone, which is the underlying engine. You could use PGlite directly in your own web app without the AI layer or the multi-app monorepo. That gives you the same in-browser Postgres capability but with more control over the UI and features. The difference is that database.build bundles PGlite with an AI assistant and a ready-made web interface, saving you development time but locking you into their design choices.

Maintenance and Licensing Considerations

The project is licensed under Apache 2.0, which is permissive for commercial use, but you should review the full license text for any specific obligations. The repository is actively maintained, with the last push on June 3, 2026, and it is not archived. However, there are no formal releases listed, which means you cannot rely on semantic versioning or release notes. You will need to track the main branch and monitor commit messages for breaking changes. The monorepo structure adds complexity to upgrades, as changes in `./packages/*` may require rebuilding dependent apps. The README does not mention a contribution guide or a code of conduct, so you should check the repository for those files before contributing. For production adoption, the lack of releases is a red flag; you are essentially using a moving target. The Apache 2.0 license gives you freedom, but you must take responsibility for maintaining your fork if the project changes direction.

Editorial conclusion

Adopt database.build if you are a developer or data analyst who wants a zero-infrastructure Postgres environment for prototyping, teaching, or quick CSV-to-table experiments, and you are comfortable with the browser as the runtime. Do not use it for production workloads or for any data that must persist beyond a single browser session, since storage is IndexedDB and there is no remote server by default. Before committing, verify that your target browsers support PGlite and WASM, that the AI features work with your chosen LLM provider (the README only shows OpenAI), and that the rate-limiting Redis setup is acceptable for your local development. The project is evolving quickly, so check the repository's commit history and open issues for current stability before building anything long-term.

Official sources

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