The database came with the download
A PoC asked whether the full stack (backend, database, MCP bridge) could ship as a native desktop app with no server. It booted in about 10 seconds: Postgres running in WebAssembly via PGlite, the backend as a Tauri sidecar, reusing the web build's migrations and protocol unchanged.
The Tauri desktop PoC started as a single question: could the full stack — backend, database, MCP bridge — ship as a native app, no server required? The answer was yes. ~10 seconds to first boot on arm64, 430 MB bundle, zero external dependencies at runtime.
Postgres without the server
PGlite runs PostgreSQL inside WebAssembly. The desktop app embeds it directly, so the client gets full SQL semantics (migrations, joins, indexed queries) without a Postgres process to manage. The migration files from the web backend ran unchanged. The contract held: same schema, same ORM, no compatibility shim between surfaces.
One binary, not a service
The backend compiles to a single Bun binary and runs as a Tauri sidecar, a subprocess the app spawns at launch and owns for its lifetime. The web backend becomes a portable executable. Feature parity between web and desktop follows naturally from this, because they run the same code, not a fork of it.
Same protocol, different transport
The MCP server attaches via stdio on the desktop instead of HTTP. On the web it’s a network endpoint; on the desktop it’s a process the app owns. The protocol is identical. Agents already connected to the web surface talk to the desktop one without configuration changes.
Desktop timescales, not agent timescales
430 MB on first download is the honest number. The 10-second boot is acceptable for a tool opened once and left running; it’s not viable for something invoked per request. The architecture holds at desktop timescales and breaks at invocation timescales. That boundary is where the PoC’s usefulness ends.