 | Newsletter · July 2026 |
| | Going beyond SQLite. 🚀 First, the one you have been waiting for: Turso, our ground-up rewrite of SQLite, is now available on Turso Cloud. That unlocks the feature SQLite users have wanted for two decades: concurrent writes, finally, while keeping everything you know and love. Pour one out for SQLITE_BUSY. Second, Turso is growing beyond its original scope. We are now the LLVM of databases: one modern, reliable core, with many database frontends compiled down onto it. SQLite was the first frontend. The initial code for a rewrite of Postgres is already merged. The internet noticed: Bytes.dev called the architecture “objectively cool,” and The Register wrote the whole story up. And it is not every day that AWS writes about your architecture. Their storage blog covers how we built a transactional database on Amazon S3 Express One Zone. That design is the secret sauce behind our BYOC story: with the database durable on S3, running Turso Cloud inside your own AWS account is just a deployment option. Also, our database runs Doom now. 🎤⬇ Yeah, I know it sounds weird. We explain below. Let’s get into it. | Concurrent writes.
Zero goodbyes.Turso, the database engine we have been building in the open for two years, now runs on Turso Cloud. Create a Turso database instead of the default SQLite one, and the single-writer bottleneck is gone: multiple transactions commit at the same time, natively, with no SQLITE_BUSY, no retry loops, and no capped throughput. The SQLite model you know and love stays intact, and a new family of SDKs built for this engine is ready to go in TypeScript, Rust, and Python. SQLite has always had a “graduation problem”: the moment your prototype becomes a product and traffic arrives, the single writer becomes painfully visible. That ceiling is now gone. Ask for it explicitly, one word does it: INSERT INTO users (name) VALUES ('Alice'); |
“Agents have cut app development from weeks to hours, making Turso more relevant than ever. Concurrent writes and scaling fears always kept me away from SQLite, Turso Cloud removed that ceiling. Plus, it costs me 10x less than Neon, my previous solution.” Tejas Kumar, international keynote speaker and podcast host, @TejasKumar_ |
|
| The LLVM of databases.
Postgres is next.Here is the thing about SQLite that most people don’t know: if you squint, it is not really a database. It is a virtual machine that compiles SQL to its own bytecode. Turso implements and extends that bytecode, so we asked the obvious question: what if the frontend were pluggable? Parse Postgres into a common AST, compile it down to the same core, and you have a modern, from-scratch Postgres in Rust. The initial code is already merged. MySQL? Possible. Redis? Also possible. Your crazy experimental database? Oh yes. Picture a real Postgres in a browser tab with no server behind it. A fresh Postgres per agent, a billion of them, each one just a file. Materialized views that update themselves. That is the end game, and we want to build it with you, in the open, as always. |
| It’s not a real compilation target until it runs Doom. So it runs Doom. 🔫Big claims require big proof, and the internet has exactly one accepted standard of proof for crazy experimental architectures and compile targets: does it run Doom? So we compiled actual, unmodified Doom to the SQLite bytecode language, and Turso’s query engine runs it exactly the way it runs a SELECT. Each frame is a result row. Memory is blobs. It is playable in your browser, because Turso also runs in your browser. We are calling this “research into the generality of our virtual machine.” You are welcome to call it work, since you found it on a tech blog during business hours. |
| // Also this month | | The release that made this month’s cloud launch possible. Concurrent writes got significantly faster, the engine no longer blocks the calling thread on I/O, and running out of memory is an error instead of a crash. Also: Postgres-style sequences, ICU collations, a SQLite-compatible .NET provider, and full-text search in Python. And we officially dropped the beta warning. | Simulation testing, Antithesis, fuzzing... what could possibly be left? Mathematical proof. We partnered with Aretta AI to bring formal verification into Turso’s testing arsenal, and it has already caught an fsync bug the rest of the gauntlet missed. | Most database scaling advice breaks the moment AI agents are involved. This guide makes the case for giving each agent its own database, and walks through four patterns for building exactly that on Turso. | A retrieval-plus-memory loop for AI agents that collapses the usual multi-service RAG stack into one embeddable Turso database and the Voyage AI API. No separate vector database, no glue infrastructure. | What local-first actually means, how Turso Sync works under the hood, three architecture patterns, and honest answers for the hard parts: conflicts, auth, storage, and partial sync. | // In the press | | AWS wrote up the architecture behind Turso Cloud: a transactional database running directly on object storage. This is the secret sauce behind our BYOC story. When your database is durable on S3, dropping the whole platform into your own AWS account stops being a heroic act and starts being a deployment option. | The Register covers the vision in full: one modern, reliable core with many database frontends compiled down onto it, why we are not here to “fix” Postgres but to modernize it for cloud-native environments, and what happens to the one-process-per-connection model. (It doesn’t survive.) | The Bytes.dev newsletter diagnosed us with a compulsion to rewrite popular projects in Rust. Guilty. But they also drew the line between this and your average slop port, calling the pluggable-frontend architecture “objectively cool.” We are framing that one. | Our CEO Glauber’s post on X announcing the Postgres work, if you prefer your database news with replies, quote posts, and at least one person asking us to rewrite it in Zig. | | | Unsubscribe |
|
|
|
|
|