By ByteBot
Turso rewrote SQLite from scratch in Rust. In roughly a year. Now they want to do the same thing to Postgres.
On July 29, Turso CEO Glauber Costa announced the company is building a Postgres-compatible database on top of the same Rust VM engine that powers their SQLite rewrite. The framing: one unified core — the “LLVM of databases” — with SQLite and Postgres as the first two frontends. MySQL and Redis are explicitly named as future targets.
This is either the most ambitious database play of 2026, or a well-timed fundraising story. Probably both. But the underlying technical insight is real, and worth understanding before you dismiss it.
What Turso Actually Built First
Before the Postgres announcement makes sense, a quick recap: Turso started as libSQL — a C-language fork of SQLite that added replication, embedded replicas, and HTTP-based access. That’s what powers Turso Cloud today and is production-ready.
Separately, the team built a clean-room Rust rewrite of SQLite (codenamed Limbo, now just called Turso). This adds MVCC for concurrent writes — SQLite’s most painful limitation — plus native async I/O via io_uring, built-in vector search, and a deterministic simulation testing suite. It’s currently in beta.
The Rust rewrite is what the Postgres work builds on.
The Mechanism: One VM, Many Frontends
Here’s the technical core of the “LLVM of databases” claim. SQLite doesn’t execute SQL directly — it compiles SQL into database-specific bytecode, which then runs on a virtual machine. Turso’s Rust rewrite preserves this architecture.
Turso’s team ran an experiment: what if you compiled Postgres SQL to the same bytecode VM? That experiment was called pgmicro. The code is on GitHub. According to Costa, it worked well enough that it’s now merged into the main Turso tree as an official project.
This is not a Postgres fork. It’s a Postgres frontend sitting on top of Turso’s storage engine. The distinction matters: you get Postgres’s SQL dialect and wire protocol, but the storage and execution layer is Turso’s Rust VM — not a line of PostgreSQL C code.
Why Embedded Postgres Is Actually Interesting
Postgres has two structural constraints that have never been solved without workarounds.
The first is the process-per-connection model. Every Postgres client connection spawns a full OS process. At scale, this is a resource problem — which is why PgBouncer and connection poolers exist. Serverless and edge deployments hit this ceiling fast.
The second is that Postgres cannot run embedded. It’s a server. SQLite can run as a library, inside your app, in a browser, as a single file. Turso’s goal is a database that speaks Postgres but runs like SQLite — embedded, file-native, edge-deployable without a server process.
No one currently owns “embedded Postgres.” That’s the gap Turso is targeting.
Is the LLVM Comparison Credible?
LLVM works because compilers for vastly different languages (C, Rust, Swift, Kotlin) can all target the same intermediate representation, and LLVM handles the machine-code generation. The abstraction holds because IR is language-agnostic.
The database equivalent is harder to pull off. Postgres supports row-level security, CTEs, window functions, JSONB, and 80+ extensions including pgvector. Whether Turso’s VM can faithfully represent all of that is an open question. The Hacker News thread raised the CockroachDB comparison — CockroachDB also speaks Postgres wire protocol on top of a custom storage engine. Turso’s differentiator is the embedded-first architecture and Rust foundation, not the multi-frontend concept itself.
The “LLVM of databases” framing is bold marketing with a real technical kernel. Keep the caveat in mind.
Current State and Realistic Timeline
To be direct: the Postgres implementation is experimental today. The libSQL C fork is what runs in production. The Rust rewrite is beta. Postgres on top of that Rust rewrite is an experiment that just became an official project.
Turso spent approximately one year achieving SQLite compatibility at production quality. Postgres is a more complex target. A realistic estimate for production-ready Turso-Postgres is 12–18 months — putting it in early-to-mid 2027 territory.
That said, the Turso GitHub repo already describes the project as “SQLite-compatible, now also speaking Postgres (experimental).” The Postgres wire protocol is wired in. It’s not vaporware.
What to Do Right Now
Don’t migrate your Postgres workloads. Do follow the pgmicro repo and the main Turso repo if you care about the edge database space. If you’re building an AI agent platform where per-tenant isolation and low connection overhead matter, Turso’s current SQLite offering already solves real problems — the Postgres angle is the longer bet.
The database market doesn’t need another Postgres fork. But a Postgres-compatible embedded database built on a memory-safe Rust VM? That’s a different product. The Register’s coverage frames it as ambition, and that’s fair. Turso earned some credibility by shipping the SQLite rewrite. The Postgres chapter is still being written.
