Rewriting SQLite in Rust was always an audacious opening move. Turning around and using that same Rust core to target Postgres is an entirely different level of ambition.
That is exactly where Turso finds itself today. Cloud database provider Turso, having already completed a ground-up rewrite of SQLite in Rust, is now building a Postgres-compatible engine on top of the exact same virtual foundation. They aren't trying to patch Postgres or ship yet another cloud wrapper. They want to turn their engine into the "LLVM of databases"—a single, blazingly fast execution core that can host Postgres, SQLite, MySQL, and Redis frontends without changing how data hits disk.
This pivot comes at a critical moment for enterprise infrastructure. As organizations navigate the economics of AI self-reliance and deploy fleets of autonomous software, the underlying data stack has to change. But before evaluating why a file-based Postgres engine matters, we need to answer a fundamental operational question: what is an enterprise ai platform?
At its core, an enterprise AI platform is the unified software architecture that orchestrates foundation models, contextual data stores, autonomous agent workflows, and enterprise-grade security controls. It acts as the operational bridge between non-deterministic language models and deterministic enterprise record systems. Without a storage layer capable of spawning thousands of isolated, lightweight state engines on demand, these platforms choke on traditional process-heavy databases. That is why next-generation agentic data platforms are ditching legacy database assumptions from the ground up.
From libSQL Fork to an LLVM-Style Execution Engine
Turso didn't start with a multi-engine blueprint. Co-founders Glauber Costa and Pekka Enberg stumbled into the architecture while building ChiselStrike, a San Francisco startup they launched after leaving technical engineering roles at ScyllaDB. They needed a lightweight online database, and SQLite was the obvious answer.
There was just one catch. SQLite author D. Richard Hipp has famously kept the original project minimal and tightly controlled since creating it in 2000. Much like Andrew Tanenbaum maintained strict control over Minix, Hipp refuses external code contributions to protect SQLite's razor-thin scope. That tight governance kept SQLite stable, but it made adding cloud-native capabilities nearly impossible without forking the codebase.
Costa and Enberg initially created libSQL as an open-source, open-contribution fork of SQLite. Developers could finally add custom features like WebAssembly user-defined functions and virtual write-ahead logs. But hacking on a C codebase from 2000 quickly hit architectural walls when trying to introduce rich type systems or concurrent multi-writer models.
That pushed the team to start a complete ground-up rewrite in Rust, initially codenamed Limbo. As ChiselStrike pivoted into a dedicated cloud database platform, the company renamed itself Turso—after the mythical Finnish sea creature Iku-Turso—and adopted the Limbo rewrite as its core engine.
While building Turso, Costa and Enberg realized something fundamental about database internals. SQLite compiles SQL queries into bytecode for a Virtual Database Engine (VDBE), which executes queries against underlying B-Trees. As Costa put it, every SQL database is effectively a collection of B-Trees with indexes wrapped in execution logic. If your execution engine sits directly above the storage layer, you can run almost any query dialect over it. To prove how flexible VDBE bytecode actually is, the team ran DOOM in WebAssembly inside the engine, rendering game frames directly as SQL result rows.
That breakthrough turned Turso into a universal database substrate. Rather than building separate database engines for every dialect, Turso compiles multiple SQL frontends down to a shared Rust core.
Building the LLVM of Databases for Agentic Data Platforms
The traditional database landscape is filled with process-heavy monoliths. When you spin up a standard Postgres instance, the engine spawns dedicated operating system processes for incoming connections. That architecture worked brilliantly for web applications with predictable connection pools. It falls apart when thousands of ephemeral AI agents start creating and destroying databases in real time, compounding architectural bottlenecks where data fragmentation stalls enterprise AI.
Turso flips this model upside down by treating databases as files rather than long-running processes. Because databases are files, they remain instantly available with zero cold-start penalties and zero wake-up latency. An idle database costs only its raw storage on disk.
This architectural shift directly powers modern agentic data platforms. In an environment where autonomous agents perform multi-step reasoning, each agent requires its own isolated state store to track task histories, vector embeddings, and working memory.
Consider how production teams run this today:
- Companies like Adaptive.ai use Turso Cloud to generate millions of ephemeral, isolated databases for autonomous AI agents, relying on rapid branching and instant rollbacks.
- Device-level AI setups, such as Kin, run local-first vector searches directly on-device so user data never leaves the hardware.
- Developer platforms like Val Town spin up thousands of tenant databases on demand using simple API calls without racking up cloud process bills.
By decoupling execution from process management, Turso enables a many-database pattern where every user, tenant, or agent gets a dedicated file-backed database engine.
Why Running Postgres as a File Engine Changes the Rulebook
To bring Postgres into this file-based world, Enberg and Costa built pgmicro, a prototype frontend that speaks the Postgres protocol over Turso's Rust engine. According to The Register, the project aims to run standard Postgres applications transparently while ditching legacy overhead.
The biggest casualty in this redesign is Postgres's legacy one-process-per-connection execution model. In standard Postgres, managing thousands of concurrent client connections requires poolers like PgBouncer to prevent memory exhaustion. By running Postgres logic inside Turso's async-first Rust engine—backed by modern Linux kernel primitives like io_uring—Turso handles concurrent connections and non-blocking I/O natively.
Turso isn't promising 100% byte-for-byte protocol parity with legacy Postgres, nor should it. Instead, the team is targeting pragmatic application compatibility while fixing long-standing Postgres developer pain points. For example, Turso plans to introduce automatically updated materialized views, a feature Postgres users have requested for years.
Because every feature added to the core engine feeds back into the lower VDBE layer, improvements made for Postgres immediately benefit Turso's SQLite frontend and future frontends like MySQL or Redis.
Memory Safety Meets Practical Database Execution
It is tempting to frame Turso's pivot as another chapter in the software industry's obsession with Rust rewrites. Developers have spent recent years rewriting everything from Kubernetes control planes to JavaScript runtimes in Rust, often crediting the language's strict memory safety and compatibility with AI coding tools.
Costa remains refreshingly pragmatic about the language choice. While Rust eliminates entire classes of memory corruption bugs and integrates smoothly with modern AI agents, he insists that Rust itself is not a silver bullet for database architecture. Most catastrophic database bugs come from flawed transaction logic, improper isolation levels, or broken query planners—none of which Rust prevents automatically.
"I never understood the fascination programmers have with programming languages," Costa noted. For Turso, Rust is simply a reliable tool for crafting a low-level virtual machine.
The real innovation isn't the language syntax. It is the decision to strip away forty years of process management bloat and sit exactly one abstraction layer above storage. As enterprise AI workloads scale from millions to trillions of autonomous tasks, the databases powering them won't look like giant monolithic servers. They will look like lightweight, composable virtual engines that speak whatever dialect your application needs.
