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?

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.

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

Ah Alexey, never change

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.

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

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

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?

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?

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.

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).

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?

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)

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

I shaved my head first, though.

Jarred is a copycat on that front.

Turso CEO here. We were doing fine.

This is a strategic acquisition and I fell in love with the vision Supabase had for how they would use Turso going forward.

More to come

> I guess Turso hosting was not making enough revenue?

I would guess it's more that the founders want to exit before AI replaces them. (Based on the doom-and-gloom narrative in tech right now...)

> Turso will continue operating, with a clear path into the broader Supabase ecosystem as workloads grow.

> The core tech is open source so that is good. Will it stay? I guess Turso hosting was not making enough revenue?

You just answered your own question. Why would anyone pay for Turso if the core of the software is available for free and being licenced permissively under MIT?

Among many other things, they built a system that can provide substantially better concurrency and a better async story.

Also, they're building a project that's more open to outsiders.

They were aiming for better concurrency, I believe. If you're rewriting something regardless, might as well use a more modern language that's easier to reason about during development.

That's how you push the field forward. Good isn't good enough.

If yiu had the resources/time, why wouldn't you challenge or improve status quo?

Sqlite is excellent but I still have many gripes with it, especially around defaults.

I think Richard Hipp has quipped “if you think you can build a better SQLite by god you’re welcome to try!”

Best tested..? The test data/suite is private. That alone is quite odd.

The Rust rewrite? I had the same question.

It’s fast, with unparalleled stability, arguably better managed than any other software on earth, deployed on literally everything, so let’s… fork it for street cred?

Another way of describing Turso is a SQLite-compatible (same file format and C API) embedded database. If you start with SQLite but find you need async i/o, concurrent writers, and local replicas then Turso is a good option.

Because they wanted something like this story to happen. It's what VC does to open source, they aren't here to help or build communities they are here to make money. Nothing else matters.

By "it" you mean Turso? Maybe you can help since I don't understand what they offer. What does Turso do that SQLite doesn't?

our cloud pays the bill just fine though.

thank you!

Write me a message to my email directly or hit me up on Discord.

We are very excited to be a part of Supabase