Supabase is acquiring Turso
supabase.com
supabase.com
It should not be X times slower than SQLite.
> 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?
So, I think my curiosity still stands.
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...
Ah Alexey, never change
> Turso - it is ridiculously slow, can't believe that: revert the single-transaction import, cap per-query wall-clock
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.
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 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.
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.
I'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)
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.
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?
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 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.
The purpose of SQLite's governance model is to be a cult, that only accepts members who share the same religion.
The software happens to be good. Getting it away from that governance and turning it into an open community sounds great. And that can happen while still maintaining high standards.
Can you explain your view more? Otherwise, this sounds like a motte-and-bailey game.
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?
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.
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.
Sqlite is excellent but I still have many gripes with it, especially around defaults.
Also, they're building a project that's more open to outsiders.
We are very excited to be a part of Supabase