pgmicro: The Database That Speaks PostgreSQL and Sleeps Like SQLite
An embeddable Rust engine that parses real Postgres syntax, compiles straight to SQLite-style bytecode, and makes one file feel like two databases.
- pgmicro treats SQL dialect as a front-end choice, so PostgreSQL syntax and SQLite deployment stop fighting each other.
- Its core trick is parsing real Postgres trees and mapping them into a shared execution engine, not rewriting SQL text between dialects.
- Catalog emulation is what turns a clever parser into something tools can actually use, from psql to schema-aware clients.
- The project reads as serious systems work, not a demo, because its testing and reliability stack is built for failure, not applause.
Most embedded databases force a compromise. You either get SQLite’s simplicity or PostgreSQL’s language, but not both without paying in complexity, runtime weight, or compatibility gaps. pgmicro is trying to erase that tradeoff.
The unusual part is not that it is a small database. It is that the same .db file can be reached through two dialects, while both paths collapse into one shared execution core. That makes SQL dialect feel like a connection-layer decision, not a storage-layer one.
Why This Database Feels Impossible
The project’s promise sounds almost too neat: PostgreSQL syntax when you want it, SQLite-style deployment when you need it. That is not a proxy server trick and it is not string rewriting. It is a Rust engine that accepts real Postgres parse trees, maps them into Turso’s internal shape, and executes from there.
AI agents are driving an explosion of databases. Many of them are ephemeral, low-touch, short-lived, and small — a scratch database for a task, a session store that lives for minutes, a per-user sandbox.
That framing matters. If the workload is an agent, a test harness, or a short-lived sandbox, the server itself can become the wrong abstraction. pgmicro is built for the cases where the database should feel disposable, local, and still familiar to Postgres users.
The Trick: Parse Trees, Not String Rewrites
The key pipeline is simple to describe and hard to build: SQL text enters through libpg_query, becomes a PostgreSQL parse tree, then flows through parser_pg into Turso’s AST, and finally compiles into VDBE bytecode. The important detail is what is missing. There is no intermediate SQL string translation step, so fewer dialect quirks leak through.
That distinction is easy to miss, but it is the whole game. If you translate SQL into SQL, you inherit the target dialect’s blind spots. If you translate parse trees into a shared internal AST, you preserve intent much more faithfully.
Why Catalog Emulation Makes It Feel Real
A database can parse queries and still feel fake to tools. The invisible test is whether clients can inspect schema, discover tables, and ask metadata questions the way they do against PostgreSQL. That is why pg_catalog, pg_class, and pg_type matter here.
| Tool expects | pgmicro provides | Why it matters |
|---|---|---|
| psql schema introspection | pg_catalog views and PostgreSQL-shaped metadata | The client can behave normally instead of falling back to brittle special cases. |
| ORM table discovery | pg_class and pg_type compatibility surfaces | Schema-aware tools can infer structure without custom adapters. |
| Application queries | PostgreSQL syntax at the connection layer | Developers keep the language they already know. |
| Embedded deployment | Single-file local engine | The database stays lightweight enough for sandboxes and ephemeral tasks. |
pgmock runs an x86 emulator with the original Postgres inside, while pglite compiles a Postgres fork to native WASM directly and is hence much faster and more lightweight.
That comparison sharpens the point. The question is not whether the database can speak Postgres in some abstract sense. The question is whether it can do so while still looking enough like Postgres to keep everyday tooling happy.
The Other Half of the Story Is Reliability
A project this ambitious can collapse into a demo if the test story is thin. pgmicro pushes hard in the opposite direction. The repository points to deterministic simulation, strict lints, differential fuzzing, sqlancer, and Antithesis, which signals a team trying to trap edge cases before users do.
That is the right posture for an engine that wants to sit under AI agents and disposable sandboxes. The workloads are messy, stateful, and often impossible to reproduce by hand. Reliability is not a nice-to-have there. It is the product.
Where pgmicro Fits in the Embedded Database Wave
The embedded database landscape is full of different compromises. PostgreSQL proper gives you the strongest compatibility, but it comes with a server. PGLite keeps PostgreSQL semantics by going through WebAssembly. pgmock keeps full fidelity by emulating a machine and running the original database inside it. SQLite gives you the easiest deployment, but not the Postgres surface area many teams want.
| Project | Runtime model | SQL compatibility | Deployment weight | Best use case |
|---|---|---|---|---|
| PostgreSQL | Server process | Highest | Heavy | Full production server workloads |
| PGLite | PostgreSQL in WASM | High | Moderate | Browser and portable Postgres environments |
| pgmock | x86 emulator with Postgres | Very high | Heavy | E2E tests and fidelity-first emulation |
| SQLite | Embedded native engine | Different dialect | Very light | Local apps and simple single-file storage |
| pgmicro | Embedded Rust engine with shared core | High for PostgreSQL syntax, SQLite-style deployment | Light | Agents, sandboxes, and local-first Postgres-like workflows |
pgmicro’s slot in that field is unusually specific. It is not trying to out-Postgres PostgreSQL. It is trying to make the Postgres experience local enough that the server stops being the main event.
Who Built This and Why It Matters
The project comes from Glauber Costa, the founder of Turso, and that lineage is visible in the architecture. This is not a casual wrapper around an existing server. It is built on a serious engine core, then pushed in a new direction by adding a PostgreSQL front door.
That matters because the credibility of the stack comes from the layers underneath the experiment. A small database can be clever. A small database with mature storage, bytecode execution, catalog emulation, and a heavy test harness starts to look like infrastructure.
What pgmicro Suggests About the Future of Databases
The broader signal is bigger than one repository. More software now wants short-lived databases, private sandboxes, per-user state, and local execution that feels production-like. In that world, the best database may be the one that behaves like Postgres at the edge while staying as easy to ship as SQLite.
That is the real thesis here. pgmicro treats dialect as presentation, not destiny. If that idea keeps spreading, the next wave of databases may be judged less by how much server they expose and more by how little compromise they impose.
