Turso + LibSQL: The $0 Edge Database Killing Enterprise Postgres Bills

One line described this project on GitHub. A SQL database in Rust compatible with Isqolite. That was the pitch. In the middle of July, that line changed. It now reads, "Now also speaking Postgress, the LLVM of databases. Same repository, same engine. 23,000 stars and one extra front end bolted onto the front. Behind it are Glowber Kusta and Pekka Enberg, Linux kernel people who went on to build Silb together. They already pulled this off once. They rewrote is qualite from scratch in rust and the thing actually works. Postgress is a heavier target. Just under 56% of developers reported using it last year. Rewriting that should take a decade. Their claim is that most of the work was finished before they started because the hard part they argue was the machine underneath the ISQL, not the ISQL itself. And they own that machine. Here is the scoreboard though. Their Postgress front end lists 41 features as fully supported. 345 are marked not supported. I counted both out of their own file this morning. So, this sits somewhere between a compiler breakthrough and a very early demo. And I want to pin down where that starts with a mess they made themselves because three separate products answered to the name Turso. The oldest is lib Isquil. Isquelite is open source, but it will not take outside patches. So in 2022, this team forked it. Open source and open contributions. In their words, 17,000 stars written in C, embedded replicas, and a network server on top. And it runs in production today. The second is Terso database, a clean room rewrite of Isqualite in Rust rather than a fork of it, announced in December 2024 under the code name Limbo. 23,700 stars as of this morning. The third is Terso Cloud, the managed service you actually pay for. Their own docs say lib SQL has powered it for years and that the Rust engine only arrived on the platform this April in a private beta. One fork, one rewrite, one cloud, all wearing the same word. Their CTO ended up posting a public thread just to explain the difference and said outright that AI agents keep getting it wrong, too. Their own guidance is split down the middle. New project, take the rewrite. Mission critical system that has to work tonight. Take the fork. The rewrite dropped its beta warning on the 13th of July and it still has not shipped a 1.0. Hold on to that because the Postgress work is happening in the rewrite, not in the fork that runs the paying customers. So the question is what the rewrite did to earn that kind of ambition. It went public on the 10th of December 2024. A thousand stars and 30 contributors before a single article was written about it. 6 weeks later, Costa published a post titled, "We will rewrite Isquite and we are going allin." 8,000 stars landed in one week and the contributor count doubled. The first alpha shipped in July 2025, and it was blunt about the holes. Indexes, triggers, views, and vacuum were all still listed as work in progress. The beta warning came off on the 13th of July this year, 19 months after that first announcement. The readme still tells you to keep your own backups until 1.0. What they built in that window goes past Equalite. Begin concurrent gives you multiple writers instead of one right lock with conflicts detected per row rather than per page. And their own measurement puts it at up to four times faster on rights. Materialized views update themselves live which Postgress itself still does not do. Async input and output on IO_ing change data capture vector search full text search on Tantev encryption at rest. Every one of those is missing from plain is equalite. The number I keep coming back to is connection time. Opening a SQLite connection against a 10,000 table schema took 23 milliseconds. Theirs takes 40 micro no matter how big the schema is. That is a factor of 575. None of that matters if the thing corrupts your data. So they came at reliability sideways. Deterministic simulation testing, antithesis, fuzzing, and a formal specification written in quint that found more than 10 bugs in Isqualite itself. A query rewrite that dropped rows check constraints that could be bypassed. My favorite piece of that program is the strangest. They pointed coding agents at the engine in a loop, checking every answer against real is qualiting nothing. So they told the agent to think and act like Edgar Allan Poe. three new bugs in the next 5 minutes. So they had a serious database. That still does not explain Postgress. The thing that opened that door was a property of Isqualite that most people who use it everyday rarely have to think about. Isquelite does not interpret your query. It compiles it into a bite code language of its own called the VDBE and then runs the bite code. The instructions are database shaped things like seek and a B tree and the language is not documented or exposed. It is an implementation detail. Terso copied that design and then somebody asked the question a compiler person would ask. If this really is a virtual machine, what else can it execute? They answered it in July with a doomport C source through LLVM into VDB byte code using a compiler they wrote for the occasion. The whole 64 megabyte address space lives in one blob column. So pointers are bite offsets into a database value. Each frame comes back through the same up code a select uses to return a row. The input handler is a wear clause. It runs over 60 frames a second in a browser tab. It is a stunt and it is also the argument. If that bite code can express a first person shooter, expressing another database stops sounding impossible. So they made the front end pluggable. Parse Postgress into a shared syntax tree. Compile that tree to the same by code. Run it on the same storage and the same B trees. The reason to bother is architectural, not linguistic. Postgress forks a separate operating system process for every connection 5 to 10 megabytes each which is why so many teams run a pooler in front of it that made sense in the 1990s. It is expensive to rent in 2026. It started as a side experiment called PG Micro sitting in Costa's own personal GitHub account. It is now merged into the main tree MIT licensed and an official intry front end from day one. Go and look at the repository and the postress directory is right there. a parser built on lib pgquery which is the real Postgress grammar so effectively all Postgress syntax parses a catalog layer a wire protocol server a psql style shell called tersopg and its own conformance and regression test directories that means your existing tools connect not a translation shim in front of isolite which is how the earlier attempts at this worked the postgress grammar goes in the front and the same engine executes it now the awkward half select joins set operations, recursive common table expressions, upsert sequences, returning clauses, array operators, and enough catalog emulation for a client to introspect the schema. 41 features tested working against that 345 entries marked not supported. No procedural language, so no PLGSQL and no stored functions, no triggers, no explain, no extensions at all, no replication, no partitioning, no rowle security. It also has no authentication and no encryption on the wire. Their compatibility file says it trusts every connection that arrives and speaks plain text only. Whatever this is right now, it is not something you point at the public internet. And there's a third category that worries me more than the missing one. Their own document flags statements that parse, run, return a result, and give you the wrong answer. Distinct on collapses into a plain distinct. Temp is thrown away, so your temporary table is permanent. Partition by is thrown away too. They publish that list themselves which is more than most projects at this stage manage and they are explicit that 100% is not the goal. Compatible enough is the phrase. Costa told the register there is nothing fundamentally wrong with Postgress and if there were they would not be rewriting it. One week before all of this a different Postgress in Rust turned up. P Rust from Michael Malice public on the 9th of July. Machine translate the C source then send coding agents through it crate by crate. It passes all 46,066 tests in the Postgress 18.3 regression suite. Two teams one week apart aiming at the same target from opposite directions. Terso answered that in their own FAQ and I think this is the line the whole project rests on. A database is not the place to move fast and break things. Their timeline is deliberately unglamorous. A useful subset of Postgress in a couple of months full coverage whenever. Both founders are around 44 and they wrote that they have at least 20 more years and are not in a hurry. The whole company has raised $7 million in one seed round and that is it. The sharpest objection came from a reader on the register and it lands. Put every database on one shared engine and a bug in that engine takes all of them down at the same time. And on Hacker News, someone answered the slogan directly. If you want the LLVM of databases, Apache Dataf Fusion already has a claim on that title. Ask Costa where this ends and he will tell you. Meccal works the same way. So does Reddis. One core, one bite code and as many frontends as people care to write. That is what LLVM of databases actually means. So let me correct the framing this video was nearly built on. Nothing here is coming for an enterprise Postgress bill. A database with no authentication and no wire encryption cannot take that job and it is not trying to. The territory it is actually fighting for is where isolite already lives. a file, a phone, a browser tab, one database per user or per agent. Cloudflare D1 caps a paid database at 10 gigabytes and a free one at 500 megabytes. Terso's free tier is 100 databases, 5 GB, and 500 million rows read a month. So, the claim to test is not Postgress in Rust. It is one engine, many frontends. And the only evidence that settles it is whether the second front end costs less to build than the first one did. that is measurable in public in a directory called posgress.