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 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?
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...
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.
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).
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.
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.
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.
Could be fun.made product on top of it.Pro plan is still too much, but free quota is too little.having a hard time balancing my hobby project.Still there's not really many alternatives, so probably we'll stick with it.Decent service.
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.
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?
Rewriting in Rust is usually an exercise in reducing serious security vulnerabilities and memory bugs, not improving speed or stability.
But with LLMs and massive, human-written test suites, rewrites aren’t a bad idea like they used to be. Rust is a perfect target language because it’s compiler is so strict and surfaces issues in a way that’s easy for either humans or LLMs to use.
I do not feel good about this. I really want SQLite (and the Turso re-write of it) to win for tiny apps that people will build more and more with LLMs. Desktop or server. Even serverless.
The core tech is open source so that is good. Will it stay? I guess Turso hosting was not making enough revenue?
Thanks but you do understand this makes it hard for folks to select Turso. With all good intentions parent companies kill acquisitions.
Supabase is hosted Postgres with wings. Turso seemed like it would be the same but using SQLite based approach.
So either Supabase now uses the Turso sync + Postgres or something that needs Turso or abandons it. Not sure and I am not asking, just sharing my thoughts.
I also have my own doubts about this acquisition, but as I explore sqlite-per-user models I'm also seeing benefits to having some central control plane. I thought they would've made a natural fit on Cloudflare.
Did you check out the post? Supabase sees Turso as the answer to workloads not well-suited for Postgres. This seems like a decent Yes, And proposition.
I am fully onboard with LLM generated code if that is what you mean. I literally get client work titled "Need Claude led Engineer". SQLite is a great option for the LLM enabled future.
> 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?
Because they don't want to self-host/manage it. It looks like this is an acquisition, not an acquihire, so it's unclear whether or not Turso was making enough to sustain itself or not. There are plenty of companies out there who release open source software and make money off of hosted/managed offerings of it.
Liability. Compliance. Chain-of-responsibility. Risk. This has always been the case in business, and it will continue to be the case (at least until artificial intelligence actually replaces that need).
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
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?
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...
1st commit of the project was in August 2023 so not quite few months old. And the performance problem according to https://github.com/ClickHouse/ClickBench/pull/1159 has not been yet solved.
So, I think my curiosity still stands.
> 1st commit of the project was in August 2023
Yeah, ok, I took the date from [1] but you're right the project did in some sense exist before then.
[1] https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-go...
Also hilarious that the rebuttal comment after a year had passed was "why are you using this release which is a year old"
That rebuttal comment was posted in response to a comment that was 4 days old, not a year old.
GGs to the team!
I'm a big fan of Glauber's work. He gives me the same neo-hacker vibe as Jarred, of Bun.
So this is pleasant news to me.
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.
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?
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.
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.
? are you seriously preferring a vibe coded project over the war tested sqlite?
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.
Could be fun.made product on top of it.Pro plan is still too much, but free quota is too little.having a hard time balancing my hobby project.Still there's not really many alternatives, so probably we'll stick with it.Decent service.
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?
Any guesses on how much they paid?
I use Turso for a small project. Seems to work well. Hope this doesn’t change
Why would you rewrite something that’s widely considered one of the best written and tested pieces of software in the world?
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.
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.
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?
Rewriting in Rust is usually an exercise in reducing serious security vulnerabilities and memory bugs, not improving speed or stability.
But with LLMs and massive, human-written test suites, rewrites aren’t a bad idea like they used to be. Rust is a perfect target language because it’s compiler is so strict and surfaces issues in a way that’s easy for either humans or LLMs to use.
Something tells me the test suites won't be human written, for most of them. They probably won't be fully human reviewed even.
That's how you push the field forward. Good isn't good enough.
Best tested..? The test data/suite is private. That alone is quite odd.
I didn't know the company, but it turns out they have a great mindset.
Always been a fan of Supabase, but didn't expect this. Curious to see what comes of it!
We use Turso for async in Rust projects. It's performance has been very good. Looking forward to what comes from this
I feel like this makes a lot of sense and is a rare win-win-win (supabase-turso-customers being the parties).
I do not feel good about this. I really want SQLite (and the Turso re-write of it) to win for tiny apps that people will build more and more with LLMs. Desktop or server. Even serverless.
The core tech is open source so that is good. Will it stay? I guess Turso hosting was not making enough revenue?
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
Thanks but you do understand this makes it hard for folks to select Turso. With all good intentions parent companies kill acquisitions.
Supabase is hosted Postgres with wings. Turso seemed like it would be the same but using SQLite based approach.
So either Supabase now uses the Turso sync + Postgres or something that needs Turso or abandons it. Not sure and I am not asking, just sharing my thoughts.
Love what you folks have been doing.
I also have my own doubts about this acquisition, but as I explore sqlite-per-user models I'm also seeing benefits to having some central control plane. I thought they would've made a natural fit on Cloudflare.
Did you check out the post? Supabase sees Turso as the answer to workloads not well-suited for Postgres. This seems like a decent Yes, And proposition.
Or Supabase starts offering "SQLite" (Turso) as they are offering PG today?
> 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...)
I am fully onboard with LLM generated code if that is what you mean. I literally get client work titled "Need Claude led Engineer". SQLite is a great option for the LLM enabled future.
lol
> Turso will continue operating, with a clear path into the broader Supabase ecosystem as workloads grow.
You mean, it has never happened that an acquiring company said this and then closed the acquired tech?
> 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?
Because they don't want to self-host/manage it. It looks like this is an acquisition, not an acquihire, so it's unclear whether or not Turso was making enough to sustain itself or not. There are plenty of companies out there who release open source software and make money off of hosted/managed offerings of it.
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
Liability. Compliance. Chain-of-responsibility. Risk. This has always been the case in business, and it will continue to be the case (at least until artificial intelligence actually replaces that need).
Huh? Supabase is also that. Lots of tech is like this. Parent company makes money from hosting, services, enterprise feature seats, etc.
it's glommer
Open source never pays the bills, nor do users here ever pay for open source.
our cloud pays the bill just fine though.
Congrats Glauber!
thank you!
Nooooooooo
Hayırlı olsun
UGH as a turso customer, I do not want this.
Write me a message to my email directly or hit me up on Discord.
We are very excited to be a part of Supabase