Supabase is acquiring Turso

Supabase is acquiring Turso supabase.com

Supabase is acquiring Turso to build the database infrastructure for agentic AI

194 points•cvburgess•about 11 hours ago•101 comments•

#supabase #acquiring #turso #acquiring turso #infrastructure #agentic #database #ai

101 comments

f311aabout 11 hours ago

I hope they will put more resources into fixing issues. I remember there were multiple attempts to add it to ClickBench, but each time new bugs were found.

It should not be X times slower than SQLite.

https://github.com/ClickHouse/ClickBench/issues/336

https://github.com/ClickHouse/ClickBench/pull/1009

menaerusabout 10 hours ago

On 22nd of July

> It was loading the data for a week already, and the speed of loading data has dropped to 4 kilobytes per second, and it will take years to load the dataset.

And then on 2nd of August

> It loaded maybe 1% of the data so far.

And then one year after

> I didn't load the data after a year. > I tried it with the fsync removed, but even then it does not work

Ok, I find this more entertaining than I should and almost unbelievable. I know that this codebase was heavily written by LLMs but the execution can't be this bad?

What am I missing and why would Supabase buy the product which can't even load the dataset properly?

gpmabout 10 hours ago

You're looking at a software project months after its inception, saying it didn't work well then, and then asking why someone would buy it well over a year later...

ambicapterabout 10 hours ago

Also hilarious that the rebuttal comment after a year had passed was "why are you using this release which is a year old"

penbergabout 9 hours ago

We're aware of your woes with ClickBench. The first time you added it I even explicitly told you that it was way too early to even try that. The attempt you did recently was fair, but it's all in the ingestion before the benchmark, and does not show up anywhere, so we ended up spending time on this instead:

https://turso.tech/blog/turso-0.8.0

In any case, this is on our radar and we do intend to improve it but not the highest priority right now.

dangoodmanUTabout 9 hours ago

> Add Turso (it is unbelievably slow) (it also does not work)

Ah Alexey, never change

f311aabout 9 hours ago

Another PR:

> Turso - it is ridiculously slow, can't believe that: revert the single-transaction import, cap per-query wall-clock

JoshTriplettabout 9 hours ago

I really, really hope that Turso survives this, and doesn't become another "incredible journey". I'm excited about Turso as a technology, both as a better sqlite and as something theoretically capable of becoming an embeddable postgres-compatible database.

glommerabout 7 hours ago

I hear you Josh, and I don't blame you because this does happen a lot. All I can say is that everyone is excited about this, on both sides of the aisle. From our perspective we'll have resources now to turbocharge the development of Turso, and things will only get better from here.

JoshTriplettabout 7 hours ago

I wish you the best of luck in beating the odds and actually continuing to operate effectively post-acquisition for as long as possible. Turso is great, and I'm looking forward to the point where it feels like it crosses from "keep a close eye on" to "use in production with no qualms".

nazgulsenpaiabout 9 hours ago

I have only ever interfaced with sqlite querying databases created by other applications so I'm not really super familiar with the application development side of it, but I've only ever heard praise of sqlite. Out of pure curiosity, what would a better sqlite look like, aside from postgres compatibility mentioned?

JoshTriplettabout 8 hours ago

More async, more concurrency, more dialects (not just postgres), better defaults, ability to be called from safe languages without going by way of an unsafe FFI layer, open community...

theLiminatorabout 7 hours ago

Yeah, I've seen a lot of technology killed by acquisitions...

For example, https://github.com/Mooncake-Labs/pg_mooncake

bitgeistabout 9 hours ago

This is a really interesting idea. I had never considered this before.

This would allow you to write PostgreSQL queries that work against a flat file or a Postgres server. Am I understanding the potential benefit correctly?

rancar2about 9 hours ago

If you are interested in that specifically, you may be a bit more interested in DuckDB’s growing support in this area: https://duckdb.org/2026/08/20/duckdb-20-peg-parser

integrallisabout 10 hours ago

Supabase is a great product, we use it for all of our products, but we also need OSS solutions that can be self-hosted. For Supabase, I hope the platform improves. SQLite has become the standard, we need that standard (other than the SQL93 part) to be created and maintained so that other can drop a paid for product and handle the server-side themselves is the choose to.

apsurdabout 10 hours ago

Agree. supabase is a great product for prototyping. Their free tier is really helpful. But the value of instant access to a real postgres db is also where inevitable pain comes from. A prototype is fun until it's not and I've never managed to maintain app-based side projects longer than a few months. Only static deployments survive.

Supabase was really early in the "throwaway full-stack environments" space. Very helpful but I find myself moving to edge networks with sqlite in spite of my dislike for javascript.

kakugawaabout 10 hours ago

Isn't this what this sounds like? You self-host Turso at the start, and you can gracefully scale to managed Turso (cloud), then to managed Postgres (Supabase). And Turso has experimental support for a Postgres frontend (alongside the SQLite frontend).

saltcodabout 9 hours ago

^ this is exactly the plan. An appropriate stack for each part of your journey.

The blog post captures it really well:

> As agents build more software, we believe database demand will outpace the world’s current capacity to support them. So we need infrastructure that can scale to meet this growth and is suited to how we build with agents.

> Agents should be able to create a database as easily as creating a file, with just as little concern about cost. For smaller workloads, that shouldn’t require provisioning a dedicated machine every time. Databases should be cheap to create, available on demand, and have a clear path to production when needed.

> SQLite is well suited to these small, on-demand workloads. Postgres is what you want as your application scales. We want builders to have the same developer experience from prototyping to production.

parthdesaiabout 7 hours ago

> then to managed Postgres (Supabase)

And then hopefully sharded Postgres via Multigres :crossedfingers:

kviraniabout 10 hours ago

Sqlite has become the standard? I've been out for a couple years but this is news to me. What does it mean though? Standard for what?

apsurdabout 10 hours ago

anecdotally I think this applies more specifically for 0-1 side-projects. They can be serious attempts at startups, but they start small and with AI the feedback loop should be rapid and fierce. For this you want lightweight infrastructure that the agent can reason about and not create a mess. So an edge network with sqlite is pretty killer.

lukasschwababout 3 hours ago

SQLite/Turso probably offers a much better developer experience than Postgres for the overwhelming majority of projects on Supabase (especially for local testing and testing in ephemeral environments).

vmg12about 11 hours ago

This is great, I was a little worried that the turso project's future was tied to the success of turso the company and it has impacted a few of my technical choices and has resulted in me choosing sqlite over turso a few times.

I'll likely be choosing turso going forward for projects.

saltcodabout 9 hours ago

More to come, but Turso remains a product and SQLite remains their focus. Supabase/Postgres is the path as workloads grow and require it.

(disclosure: I work at supabase)

anicepersonabout 10 hours ago

? are you seriously preferring a vibe coded project over the war tested sqlite?

vmg12about 10 hours ago

1. I've looked at how Turso verifies the correctness of their db and I'm satisfied with it.

2. Turso supports features I want that don't exist and will not exist in sqlite.

I mean this is pretty obvious, I'm not using sqlite because it doesn't do what I want it to do. I also don't understand the repeated "sqlite is the best tested software" sentiment. I don't care if it's the best tested if it doesn't do what I want it to do.

glommerabout 7 hours ago

We started turso way before vibe coding became a thing, king. And these days we use AI, like most people, but still review all the code ourselves before it goes in.

Very disingenuous to call turso a vibe coded project.

Read the full thread on Hacker News →

101 comments

Related stories