October 20, 2026
db4 runs real Postgres inside a browser tab, with vector search in plain SQL, so a local LLM can do RAG over your data and nothing leaves your machine. psql, ORMs and MCP clients connect too. Now MIT-licensed on GitHub.
Above: RAG with a model running locally in LM Studio, against a
database that lives in a browser tab, with psql first to show it’s real Postgres. I recorded and edited it with
rec4, the AI screen
recorder for Mac we’re building at lab4. If you ship developer tools, it’s built for exactly this kind of video.
What if your RAG stack were just a browser tab and a model on your laptop?
That’s db4. It runs real Postgres (PGlite,
Postgres compiled to WebAssembly) inside the tab and keeps it in the browser’s own storage. An MCP client like LM Studio or
Claude Desktop calls db4’s MCP server, which embeds your text with a local LM Studio
embedding model and stores the vectors in the tab. Search is cosine similarity written in
plain SQL, in a community app you can read in one sitting. There’s no vector database
service and no cloud account, and with a local model nothing leaves your machine. Because it speaks
the standard Postgres wire protocol, psql, DBeaver, TablePlus and your ORM can connect
to the same database.
Today db4 is open source under the MIT license, and the hosted service is retired.
github.com/maxabrahamsson/db4app →
How it works #
psql / DBeaver / ORM / MCP server
│ Postgres wire protocol
▼
relay (routes bytes, stores nothing)
│ WebSocket
▼
browser tab ── Postgres (PGlite, WASM) ── IndexedDB
The interesting part is the trust model. The browser tab is the owner of the data. The auth token, read-only mode, query guards and per-app schema isolation are all enforced in the tab, under the user’s control. The relay in the middle is plain transport: it matches a connection ID to the right tab and forwards bytes. It keeps no data and makes no access decisions. It does see the query traffic it forwards, which is one more reason to run your own.
That inverts the usual setup. Normally the server holds your data and your browser borrows a view of it. With db4 the browser holds the data, and servers only get to talk to it when you let them.
Why open source, and why now #
Since late 2025 I’ve run a public relay so anyone could open the site and connect psql
to their tab within seconds. On October 20, 2026 I shut it down.
db4 makes more sense as something you own than as something you rent from me. The relay is a single small Node process. When you run it yourself, on your laptop, your homelab or a $5 VPS, the whole chain from client to data is yours.
- Code:github.com/maxabrahamsson/db4app (MIT)
- Website:db4.lab4.app . The app still works there: the database, SQL editor and community apps all run in your tab. External clients need a relay, which you now run yourself.
- Your data: if you used the hosted version, your databases are where they always
were, in your browser. Nothing was stored on the relay, so nothing was lost. Old
*.pg.db4.appconnection strings no longer resolve, and the relay indicator shows offline. The fix is one step: run a relay (below), then setDatabase → Relay server → Custom relay URL tows://localhost:8787/agent.
Running it locally takes a minute:
git clone --recurse-submodules https://github.com/maxabrahamsson/db4app.git
cd db4app && npm install
npm run relay # relay: :8787 (WebSocket) + :6543 (Postgres)
npm run dev # web app: http://localhost:5173
Then copy the connection ID and token from the Database page:
psql "postgres://postgres:YOUR_TOKEN@localhost:6543/YOUR_CONNECTION_ID"
If you put the relay on a server: the auth token is the only thing standing between
the internet and your tab’s database, so treat it like a password. Put the relay behind
TLS (a reverse proxy serving wss://), and don’t open the Postgres port (6543) publicly
unless you need to. An SSH tunnel or a firewall allowlist is safer. The
self-hosting guide
covers TLS and rate limits.
There’s also a Dockerfile for the relay,
an MCP server (npx db4app-mcp-server) for
Claude Desktop, LM Studio and friends, and a small desktop app
that wraps a single-user relay.
What you can build with it #
A few things db4 is already good at, and a few I’d love someone to try:
- Local-first RAG. Store embeddings in the tab, query them from a local model through MCP. Your documents never touch a third-party service.
- A private database for an AI agent. Give an agent a real Postgres it can create tables in, query, and reset, inside a tab you can close. It’s a sandbox you can see.
- Teaching SQL. Every student gets a real Postgres with zero install, and they can
still practice with
psqland real GUI clients, not just a web textbox. - Prototyping and demos. Spin up a schema, point your ORM or BI tool at it, and throw it away. No containers, no cloud accounts.
- Offline field tools. The database lives with the app and works without a network. Connect a laptop’s tools to it when you’re back.
- “Bring your own database” web apps. Apps that store user data in the user’s browser, but still speak standard Postgres so power users can inspect and own it.
Some ideas that are wide open:
- pgvector. PGlite ships the extension; wiring it in would give the RAG app real vector columns and indexes instead of arrays. A good first PR.
- A browser-tab replica that syncs from a real Postgres for fast local analytics.
- Peer-to-peer relays , so two tabs can query each other with no relay in the middle.
- Per-app capability tokens , so you can grant an agent read access to one schema for one hour.
- More community apps : small, self-contained schemas plus instructions that anyone can install into their tab (community apps repo ).
Come build with it #
If any of this sparks something, clone it, break it, and tell me what you made. Issues and PRs are welcome, especially new community apps, relay hardening, and wild use cases I haven’t thought of.