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...
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 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 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".
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?
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).
^ 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.
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.
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.
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.
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.
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.
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.
For existing, mature projects like SQLite, the tests are human-written.
Even if they weren’t, LLMs are pretty good at writing tests because of Github being in their training sets. I rarely find that their tests are bad unless I underspecified what the project is supposed to do.
Disclaimer that I only vibe-code for personal projects, so I haven’t tested this at business scale.
Thanks for the link, I watched it for myself and wrote a fuller transcript.
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. I think that the time has passed; it takes twenty five years, and it takes maniacal devotion to the cause.
This transcript doesn't include the hesitation, pauses, repeated words, incredulity etc. I got the vibe of beware wasted effort not an enthusiastic go do it quip.
It's not odd at all if you understand the purpose of SQLite's governance model. Much better than letting VC + SV rat fuck everything for solitary monetary gain.
That explains why they don't accept code contributions. The test harness thing is just strange, they put out "certified" binaries for free but keep the test code closed.
That's basically the opposite of any other project where you pay to get support and a certified official build of the exact same code as open source releases, and if there's a private part it's paperwork you can show as proof of compliance for safety critical systems.
No, this is just sour grapes because you clearly disagree with people that don't adhere to your ideology. Thank fuck for that, people like you are why devs get burnt out.
I haven't heard a cult literally defined as "any group that filters based on their religion". The definition most people have is https://www.merriam-webster.com/dictionary/cult which implies coercion, manipulation, extremism.
Can you explain your view more? Otherwise, this sounds like a motte-and-bailey game.
A church is commonly expected to filter on religion (somewhat, many welcome respectful outsiders). A software project filtering on religion is very different. One common aspect of cults is pervading every aspect of people's lives, including their work ("company store" style).
Full acknowledgement for the fact that the line between "religion" and "cult" is blurry, but "all developers of this project must share a common religion and agree to these monastic religious tenets" sure ticks some boxes on "extremism".
They are, of course, free to do so; freedom of association is their right. Others are free to judge them for it, and to question whether they should be using the resulting software. The license is open, the community is not. So, seeing a project come along that looks to build something more open (and it's really saying something when "project whose governance is owned by a company, but open to pull requests" is more open) seems like a positive step.
(Also, as a database project, surely they shouldn't be mixing church and state. ;) )
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).
Had big issues where in certain regions we started seeing 100+ ms latency from networking issues on their side. These were not "beta" regions or anything and it lasted long without anything on the status pages. That they apparently don't have automated monitoring for this made us move off the platform. I get that 99% of their revenue came from businesses who only hosted their data in US regions but if you're only going to properly support them, don't bother offering the others.
Sorry to hear about that. That’s definitely not the norm, especially if this wasn’t on the free tier. We expect very low latency, but if it is a local isolated problem with a small group of servers our status page won't pick up. Though hard to say much more without the specifics.
I’ve been watching Turso for a while. A very exciting project, and I’m excited to see what comes with the acquisition (especially seeing as Glauber’s stoked by it.)
I certainly am! A large part of the reason this happened is that I sat down with Paul, and he shared his vision with me for what he wanted to do with Turso and how that would fit the supabase story. Very exciting!
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.
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.
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.
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
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).
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.
Ummm, what's wrong with the current database infrastructure? Agentic AI having problems with it? Anybody knows why does it need it's own infrastructure?
Im not that familiar with agentic ai or supabase or turso, just curious about their tagline.
Personally, I think SQLite is good enough, but in the current agent era, it doesn’t seem good enough anymore. For example, while I was writing semquery (https://github.com/lichuang/semquery), I kept looking for an embedded database that could simultaneously support SQL queries, vector queries, and graph database functionality. SQLite makes this a bit difficult. Maybe this Turso is worth looking into.
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.
I hope they don't. Of the many projects in the world, SQLite is one of the very top in the list of "do not rewrite".
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.
Why do you think f311a is alexey?
I also want to know that; it's a weird accusation.
Penberg's earlier reply said f311a was (paraphrased) "talking crap on the internet" but it looks like they've edited out the cussing.
I'm not affiliated in any way.
> Add Turso (it is unbelievably slow) (it also does not work)
Ah Alexey, never change
Another PR:
> Turso - it is ridiculously slow, can't believe that: revert the single-transaction import, cap per-query wall-clock
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 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".
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...
Yeah, I've seen a lot of technology killed by acquisitions...
For example, https://github.com/Mooncake-Labs/pg_mooncake
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?
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
I hope not.
I hope the highly talented people behind Turso will now build something new and beneficial to the world instead.
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).
^ 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.
> then to managed Postgres (Supabase)
And then hopefully sharded Postgres via Multigres :crossedfingers:
Also, https://supabase.com/docs/guides/self-hosting :)
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.
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?
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.
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.
> 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?
Support for multiple concurrent writers and a better search extension.
Why would you rewrite something that’s widely considered one of the best written and tested pieces of software in the world?
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.
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.
it's funny, because money is the number 1,000 or even lower thing on my priorities.
Turso has a booming OSS community with many contributors from outside the company and is fully MIT.
What you believe versus what outcomes your decisions actually lead to are two totally different things.
That's how you push the field forward. Good isn't good enough.
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.
For existing, mature projects like SQLite, the tests are human-written.
Even if they weren’t, LLMs are pretty good at writing tests because of Github being in their training sets. I rarely find that their tests are bad unless I underspecified what the project is supposed to do.
Disclaimer that I only vibe-code for personal projects, so I haven’t tested this at business scale.
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!”
I do not recall ever saying that.
https://m.youtube.com/watch?v=x8_ZZhRL3YU&ra=m
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.
Thanks for the link, I watched it for myself and wrote a fuller transcript.
This transcript doesn't include the hesitation, pauses, repeated words, incredulity etc. I got the vibe of beware wasted effort not an enthusiastic go do it quip.Best tested..? The test data/suite is private. That alone is quite odd.
It's not odd at all if you understand the purpose of SQLite's governance model. Much better than letting VC + SV rat fuck everything for solitary monetary gain.
That explains why they don't accept code contributions. The test harness thing is just strange, they put out "certified" binaries for free but keep the test code closed.
That's basically the opposite of any other project where you pay to get support and a certified official build of the exact same code as open source releases, and if there's a private part it's paperwork you can show as proof of compliance for safety critical systems.
[flagged]
No, this is just sour grapes because you clearly disagree with people that don't adhere to your ideology. Thank fuck for that, people like you are why devs get burnt out.
I meant "cult" quite literally, not hyperbolically. They literally filter acceptable developers based on religion.
I haven't heard a cult literally defined as "any group that filters based on their religion". The definition most people have is https://www.merriam-webster.com/dictionary/cult which implies coercion, manipulation, extremism.
Can you explain your view more? Otherwise, this sounds like a motte-and-bailey game.
A church is commonly expected to filter on religion (somewhat, many welcome respectful outsiders). A software project filtering on religion is very different. One common aspect of cults is pervading every aspect of people's lives, including their work ("company store" style).
Full acknowledgement for the fact that the line between "religion" and "cult" is blurry, but "all developers of this project must share a common religion and agree to these monastic religious tenets" sure ticks some boxes on "extremism".
They are, of course, free to do so; freedom of association is their right. Others are free to judge them for it, and to question whether they should be using the resulting software. The license is open, the community is not. So, seeing a project come along that looks to build something more open (and it's really saying something when "project whose governance is owned by a company, but open to pull requests" is more open) seems like a positive step.
(Also, as a database project, surely they shouldn't be mixing church and state. ;) )
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.
I shaved my head first, though.
Jarred is a copycat on that front.
Congrats! The team is very based and I've learned a lot contributing to Turso, amazing people
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).
Had big issues where in certain regions we started seeing 100+ ms latency from networking issues on their side. These were not "beta" regions or anything and it lasted long without anything on the status pages. That they apparently don't have automated monitoring for this made us move off the platform. I get that 99% of their revenue came from businesses who only hosted their data in US regions but if you're only going to properly support them, don't bother offering the others.
Sorry to hear about that. That’s definitely not the norm, especially if this wasn’t on the free tier. We expect very low latency, but if it is a local isolated problem with a small group of servers our status page won't pick up. Though hard to say much more without the specifics.
I use Turso for a small project. Seems to work well. Hope this doesn’t change
I'm very of this announcement, and I believe in the Turso Founders made this movement to start a new paragraph in Turso history, let's go!!
I’ve been watching Turso for a while. A very exciting project, and I’m excited to see what comes with the acquisition (especially seeing as Glauber’s stoked by it.)
I certainly am! A large part of the reason this happened is that I sat down with Paul, and he shared his vision with me for what he wanted to do with Turso and how that would fit the supabase story. Very exciting!
I know it’s hard. My previous Postgres startup did fail.
IMHO, Turso spent a lot of time on rewrites and what’s possible instead of finding PMF.
I feel like this makes a lot of sense and is a rare win-win-win (supabase-turso-customers being the parties).
Any guesses on how much they paid?
Always been a fan of Supabase, but didn't expect this. Curious to see what comes of it!
Congrats team! Turso pulled me out of OS contribution slumber. I learned a lot about sqlite internals and rust while contributing to it.
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.
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.
Thanks again, I have hope.
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.
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?
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
> 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?
I has happened, but supabase has a history of keeping things open source and Turso keeping its sqlite-focused mission is the plan.
(disclaimer, supabase employee)
Rob told me you were at Supabase now and I am STOKED to work together again, Paul!
same!!
> 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.
Open source never pays the bills, nor do users here ever pay for open source.
our cloud pays the bill just fine though.
We're seeing a lot of acquisitions in this space. First Electric (pglite) was acquired by DataBricks (Neon) now this.
We use Turso for async in Rust projects. It's performance has been very good. Looking forward to what comes from this
I didn't know the company, but it turns out they have a great mindset.
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?
Ummm, what's wrong with the current database infrastructure? Agentic AI having problems with it? Anybody knows why does it need it's own infrastructure?
Im not that familiar with agentic ai or supabase or turso, just curious about their tagline.
[flagged]
it's glommer
Congrats Glauber!
thank you!
nide for a rust project !
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
[dead]
Hayırlı olsun
Allah bereket versin.
Nooooooooo
[flagged]
Personally, I think SQLite is good enough, but in the current agent era, it doesn’t seem good enough anymore. For example, while I was writing semquery (https://github.com/lichuang/semquery), I kept looking for an embedded database that could simultaneously support SQL queries, vector queries, and graph database functionality. SQLite makes this a bit difficult. Maybe this Turso is worth looking into.
[dead]
[dead]
[flagged]