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.
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.
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...
I honestly don't even know what to respond to this.
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:
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?
> 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?
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.
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.
yup — we see Turso/SQLite as complementary to Postgres for specific use cases. The blog post doesn't mention it yet, but this will power our smallest instance — "Spark" https://x.com/saltcod/status/2106078176464036044
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 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.
No, I truly don't understand that.
It is true that some acquisitions fail, but most of the ones you see failing are doomed from the start and are a way for the founder to exit, acquhire, etc.
I had a never-ending host of options at my hand. Turso grew revenue > 5x this year. I had no reason to accept an offer that wouldn't have a great chance of success.
SQLite/Turso fits my own agent/harness mental model very well but I am, as folks in the valley would say, a bit of an anti-capitalist.
I am working on my own agents that are anti-tokenmaxxers. SQLite/Turso is part of the deployed app architecture from my harness. Thanks a lot for taking the time.
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.
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.
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.
Thanks for the link, I watched it for myself and I can see where the wrong impression came from. The fuller transcript as I summarized it:
> Q: If a young developer said they wanted to fork SQLite and build something better, what would you tell them?
> A: ... lots of people have tried. You're welcome to try. But I think that the time has passed; it takes twenty five years, and it takes maniacal devotion to the cause.
I didn't include the hesitation, the pauses, the repeated words, incredulity, and carefulness. On that note, I think the original quip doesn't capture the spirit of wariness.
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.
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).
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.
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.
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?
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...
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?
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.
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".
99 comments
[ 0.54 ms ] story [ 20.1 ms ] threadI'll likely be choosing turso going forward for projects.
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.
That’s an interesting tradeoff, especially if this is a production grade application. Curious: what features is SQLite missing?
Very disingenuous to call turso a vibe coded project.
(disclosure: I work at supabase)
We are very excited to be a part of Supabase
It should not be X times slower than SQLite.
https://github.com/ClickHouse/ClickBench/issues/336
https://github.com/ClickHouse/ClickBench/pull/1009
> 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?
Ah Alexey, never change
> Turso - it is ridiculously slow, can't believe that: revert the single-transaction import, cap per-query wall-clock
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
Anyway, don't worry, I'm aware of this, we'll eventually fix it. But it's not the highest priority even if you talk crap on Hacker News. Sorry.
Penberg's earlier reply said the poster was (paraphrased) "talking crap on the internet" but it looks like they've edited the cussing out?
The core tech is open source so that is good. Will it stay? I guess Turso hosting was not making enough revenue?
(disclaimer, supabase employee)
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?
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...)
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
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 had a never-ending host of options at my hand. Turso grew revenue > 5x this year. I had no reason to accept an offer that wouldn't have a great chance of success.
SQLite/Turso fits my own agent/harness mental model very well but I am, as folks in the valley would say, a bit of an anti-capitalist.
I am working on my own agents that are anti-tokenmaxxers. SQLite/Turso is part of the deployed app architecture from my harness. Thanks a lot for taking the time.
Sqlite is excellent but I still have many gripes with it, especially around defaults.
Turso has a booming OSS community with many contributors from outside the company and is fully MIT.
Also, they're building a project that's more open to outsiders.
54min in was what I was thinking of.
“Lots of people have tried, you’re welcome to try”
I apologize if I gave a bad gloss, but I think it was roughly in the spirit of what you said.
> Q: If a young developer said they wanted to fork SQLite and build something better, what would you tell them?
> A: ... lots of people have tried. You're welcome to try. But I think that the time has passed; it takes twenty five years, and it takes maniacal devotion to the cause.
I didn't include the hesitation, the pauses, the repeated words, incredulity, and carefulness. On that note, I think the original quip doesn't capture the spirit of wariness.
And then hopefully sharded Postgres via Multigres :crossedfingers:
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.
Jarred is a copycat on that front.
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?
For example, https://github.com/Mooncake-Labs/pg_mooncake
I hope the highly talented people behind Turso will now build something new and beneficial to the world instead.