On 2 October 2026, Supabase announced it was acquiring Turso. The post is short and reassuring: “For existing users, nothing changes. Supabase will continue building around Postgres, while Turso will continue its work on SQLite.”
If you have Turso, libSQL or @libsql/client in a production stack, that sentence is the entire basis on which you are being asked to do nothing. Rather than evaluate the sentence, we evaluated the company making it: we pulled the commit history of every codebase Supabase has acquired since 2021 and counted what happened after each announcement.
TL;DR
- Supabase has acquired six companies: Logflare (Dec 2021), Oriole (Apr 2024), Triplit (Oct 2025), BKND (Feb 2026), Hydra (Feb 2026) and Turso (Oct 2026).
- Two of the five prior codebases have stopped, and both had already stopped before the acquisition was announced. Triplit’s last commit to
mainlanded 27 days before the blog post; Hydra’s landed 365 days before. - Three are demonstrably alive. Logflare took 576 commits in the last 180 days, OrioleDB took 796.
- One repository, BKND, looks dead on its default branch and is not. Its release branch moved on 24 September and it published a release candidate on 1 October.
- Turso’s Rust rewrite took 4,302 commits in 180 days. libSQL, the fork underneath the client package doing 3.8 million downloads a week, took 39.
- Acquisition news is a lagging indicator. The commit log is free, public, and months earlier.
What we measured
We took the six announcement posts from the Supabase blog, pulled the date off each, then used the GitHub API to count commits on the acquired project’s default branch in the 180 days before the announcement and the 180 days after it. We then counted commits in the last 180 days to establish the current state, and cross-checked each project against the npm registry, because a frozen repository and a frozen package are different problems.
Every figure below is first-hand and reproducible. None of it required a login, a vendor briefing, or a conversation with anyone’s account manager.
The scoreboard
| Project | Announced | 180d before | 180d after | Last 180d |
|---|---|---|---|---|
| Logflare | 2 Dec 2021 | 481 | 200 | 576 |
| OrioleDB | 15 Apr 2024 | 146 | 49 | 796 |
| Triplit | 8 Oct 2025 | 377 | 0 | 0 |
| BKND | 3 Feb 2026 | 387 | 46 | 0 on main |
| Hydra (columnar) | 10 Feb 2026 | 0 | 0 | 0 |
| Turso (Rust) | 2 Oct 2026 | 4,302 | n/a | n/a |
The two that stopped had already stopped
This is the finding that changed how we think about acquisition risk.
Triplit was a syncing offline-first database with 3,116 stars. In the 180 days before the 8 October 2025 announcement it took 377 commits. In the 180 days after, it took zero. But the last commit on main is dated 11 September 2025, which is 27 days before the announcement went up. The acquisition did not stop Triplit. Triplit had already stopped, and the acquisition was the public notice.
The only pushes to that repository since are two unmerged agent-authored branches, claude/supabase-postgres-adapter from 30 December 2025 and claude/setup-tcp-c-benchmark from 19 January 2026. Someone did try to bridge Triplit to Supabase Postgres. It never landed. Meanwhile the published client package has not moved past version 1.0.50, released 31 July 2025, and is still pulling 210,747 downloads a week.
Hydra is starker. Supabase announced on 10 February 2026 that it would “take over the maintenance of Hydra’s existing repos.” The main Hydra repository, now hydradatabase/columnar, has 3,042 stars and its last push is dated 10 February 2025, exactly twelve months before that promise. Eight months on, no repository in the hydradatabase organisation has received a commit since 1 May 2025, and none has been migrated into the supabase organisation. The announcement also committed to helping MotherDuck with pg_duckdb contributions. That project has taken 17 commits since, nine of them from Jelte Fennema-Nio at MotherDuck and exactly one from a Supabase storage engineer. Its own last commit is 17 July 2026.
Three are alive, and the pattern is in the wording
It would be lazy to conclude that acquisition kills code. Logflare was acquired in December 2021 and took 576 commits in the last 180 days, the most recent on the day we ran this. OrioleDB was acquired in April 2024 and took 796, with a further 350 on its patched Postgres fork. Both dipped sharply across the acquisition, 481 to 200 and 146 to 49, and both recovered. Logflare is now Supabase Analytics, with its own Terraform and Pulumi providers in the Supabase organisation. OrioleDB is a storage engine Supabase ships.
The difference is visible in the announcements themselves. Logflare and Oriole were announced as products: “build a faster storage engine for Postgres.” Triplit, BKND and Hydra were announced as people. The Triplit post says “this move is about Matt’s expertise and collaboration, not about immediately using Triplit.” The BKND post says “this move is about Dennis’s expertise and collaboration, not a product announcement.”
That is honest acqui-hire language, and it is a reliable instruction to go and check. It is not a reliable prediction, which brings us to the one that nearly fooled us.
The default branch lied
BKND carries exactly the same person-first framing as Triplit, and its main branch has not moved since 28 March 2026. On a default-branch check it scores as dead.
It is not. The release/0.21 branch tip is dated 24 September 2026, a feature branch moved on 23 September, and the published package shipped release candidates on 29 September and 1 October. Development carried on in the open, just not where a casual check looks.
If you are building a dependency health check, this is the trap to design around. Query branch tips and the package registry, not just HEAD on the default branch.
So what does this say about Turso
Nothing alarming about the acquisition, and something worth knowing about the project.
tursodatabase/turso, the SQLite-compatible rewrite in Rust, has 24,491 stars, 1,071 open issues and took 4,302 commits in the last 180 days. That is not a codebase anyone is about to abandon.
But that is not the code most production systems are running. tursodatabase/libsql, the C fork of SQLite that the native bindings are built from, took 39 commits in the same window, the most recent on 23 August 2026. The libsql package those bindings ship as has not had a stable release since version 0.5.29 on 25 March 2026. Its successor has been in pre-release since May and is now on its forty-third release candidate. Between them, libsql and @libsql/client are downloaded about 3.8 million times a week.
The honest reading is that attention moved from the fork to the rewrite months before Supabase was involved, and the acquisition is likely to accelerate that rather than reverse it. “Turso will continue its work on SQLite” is true. It just does not mean the SQLite fork you are currently linking against.
Run this before you sign, not after
The method above takes about twenty minutes against any vendor and needs nothing but the GitHub and npm APIs.
- Score the acquirer, not the deal. Pull every prior acquisition the buyer has announced and count commits on each acquired repository before and after. A buyer with a record of absorbing products is a different risk from a buyer with a record of hiring founders.
- Check the commit log before the announcement date. In two of five cases here, the code had already stopped. If you only react to acquisition news, you are reacting months late to a signal that was public the whole time.
- Read the announcement for product language versus people language. “We are welcoming X to the team” and “we are shipping X” are different commitments, and companies are generally candid about which one they are making.
- Measure branch tips and the registry, not the default branch. One of the five projects here fails a naive check and passes a real one.
- Separate the project from the artefact. A healthy monorepo tells you nothing about whether the specific package in your lockfile is still being released.
None of this says avoid Turso; it is an outstanding piece of engineering. It says that “nothing changes for existing users” is a statement you can check rather than accept, and that the check is cheap enough that there is no excuse for skipping it.
At REPTILEHAUS we run this analysis as part of technical due diligence, both for clients evaluating a vendor and for teams who have just discovered a core dependency changed hands. If you have a database, an auth provider or an AI supplier whose roadmap just became someone else’s decision, get in touch and we will tell you what the commit log says.
📷 Photo by Peter Herrmann (@tama66) on Unsplash
