Turso’s pitch to serverless teams is that its database is a file embedded where the function runs, not a shared server process you reach across a network. That removes the database round trip that serverless Postgres spends a connection pool managing. The catch sits underneath the marketing: the production-ready surface is the libSQL SQLite fork, while the Rust rewrite that actually delivers concurrent writes and cloud-native replication is explicitly BETA.
What “files, not processes” means in practice
Turso’s core architectural claim is that its databases are “files, not processes,” always on, with no cold start and no wake-up penalty. Read literally, that is a statement about lifecycle, not measured latency: a file does not boot, does not scale to zero, and does not need a pool to share connections to it. That lifecycle is what makes the many-database model the company sells economically possible, one database per agent, user, or tenant, because an idle file costs only storage rather than a running process.
This is vendor framing, not a benchmark. “No cold start” describes how the engine initializes, not a p50 you can put next to Neon’s or Supabase’s in a comparison table. Treat it as the reason the architecture is possible, and demand numbers before quoting a latency figure to a procurement team.
The embedding mechanism is what turns “file, not process” into an actual deployment. Turso ships in-process SDKs for Rust, JavaScript, Python, Go, Java, .NET, and WebAssembly, per the project’s homepage, and the engine runs in the browser through WebAssembly. In-process embedding is the load-bearing detail: a query that resolves inside the same process as the function has no network hop to remove with a pool, because there is no hop.
libSQL vs the Turso Database: which one are you shipping?
Turso is one name for two products, and the split is the detail that determines what a team actually deploys. libSQL, the SQLite fork, is the production surface. The new Turso Database, a ground-up Rust rewrite of SQLite, adds concurrent writes through MVCC, vector search, CDC, cloud-native replication, and async I/O via io_uring on Linux, but carries a BETA warning that recommends caution and independent backups for production data.
Third parties wiring up Turso today target libSQL: Hasura’s Turso connector explicitly binds to “a LibSQL/SQLite database or a Turso hosted LibSQL database,” confirming the production integration surface is the fork rather than the rewrite. The embedded-replica, many-database story that draws teams in is available now on libSQL, while the concurrent-write and async-I/O story that makes the architecture technically interesting lives in a codebase the project itself marks BETA.
The connection-pool problem that pooling exists to solve
Serverless functions are short-lived and concurrency-elastic, which is precisely the workload a pooled Postgres server process was not designed for. Each invocation can open its own connection, and left unchecked a fleet of them saturates the database’s connection limit and falls over. The pool, and the managed-Postgres product category around it, exist to broker a scarce resource: live connections to a shared server.
How hard this problem is can be measured by the academic attention it draws. PolarDB Serverless won the ICDE 2024 Industry Track Best Paper for achieving roughly 0.5-second transparent cross-machine migration, against Aurora Serverless’s approximately 15-second migration that drops all active connections. A 30x gap between two of the best-funded serverless databases, on a metric as basic as “does my connection survive a migration,” explains why an entire product category has grown up around managing connections rather than removing them.
Turso’s bet is the removal strategy. If the database is a file in the function, there is no shared server to saturate and no pool to broker. The pool problem does not get optimized; for the read path it gets category-eliminated.
Where embedded SQLite wins and where it bites
For read-heavy serverless workloads, the embedded model has a clear structural advantage: reads resolve against a local file with no network hop, and a fleet of functions can each carry their own replica without contending for a central process. That is the regime where removing the pool beats managing it.
Writes are where the model pays its tax, and the tax collector is Turso’s concurrency model. The Rust rewrite’s MVCC framework governs write semantics by detecting and aborting concurrent write conflicts at commit. Concurrent writers can conflict, and when they do, one aborts and retries. A pooled Postgres does not surface this failure mode for contended rows in the same way, because it serializes through a single shared buffer and lock manager.
Two structural consequences follow. Write-heavy or strongly-consistent workloads, anything where two functions writing the same row must not silently collide, pay in abort-and-retry cycles and replication lag that a pooled Postgres absorbs through its lock manager instead. And the read-side win only holds if replicas are actually co-located with the function and kept warm; an embedded replica that has to refresh over the network on every cold path is a pool with extra steps.
How to choose between embedded SQLite and pooled Postgres
Choose embedded SQLite for read-heavy, per-tenant-isolated workloads where you can tolerate the libSQL production surface while the Rust rewrite matures; choose pooled Postgres when writes are contended, when strong cross-row consistency is a hard requirement, and when the connection-management operations story is already paid for.
The decision falls out of the architecture rather than the marketing. For reads, the pool disappears and the round trip with it. For writes, a different problem appears in its place, conflict aborts and replica lag, on an engine that still tells you to keep your own backups. That is a genuine trade rather than a universal upgrade.
Frequently Asked Questions
How does Turso sit alongside Neon, Supabase, and Prisma Postgres on the Vercel Marketplace?
All four live under Storage integrations, but only Turso ships the embedded-SQLite path. Neon, Supabase, and Prisma Postgres are Postgres surfaces, so they still require the connection-pool plumbing that Turso’s in-process file model exists to remove. Upstash, the other marketplace sibling, is Redis rather than SQL.
What is the path for libSQL once the Rust rewrite graduates from BETA?
Turso’s own readme states the Rust rewrite replaces libSQL as the project’s intended direction. libSQL remains the production-ready fork today, but teams betting on the embedded-replica model are effectively on a surface the vendor plans to supersede, which makes long-term API stability the unpriced risk.
Does Turso’s no-cold-start claim also remove the function’s cold start on Vercel?
No. The no-cold-start claim covers only the database engine. The Vercel function that calls it still spins up under Fluid Compute’s serverless lifecycle, so a request can still pay a function cold start even when the database has none.
What write semantics does the Rust rewrite use, and what failure mode do they produce?
The Turso Database uses MVCC under a BEGIN CONCURRENT model with snapshot isolation, so concurrent writers operate against independent snapshots and conflicts surface at commit. When two functions write the same row, one transaction aborts and retries, a mode a pooled Postgres absorbs through its lock manager instead.
Which production apps already run on Turso despite the BETA warning on the Rust rewrite?
Turso’s readme lists Turso Cloud itself, the Kin AI assistant, and Spice.ai as production users. Those deployments run on libSQL, the production-ready fork, not the Rust rewrite that still carries the caution to keep independent backups.
