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)
We are very excited to be a part of Supabase
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.
Penberg's earlier reply said f311a was (paraphrased) "talking crap on the internet" but it looks like they've edited out the cussing.
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.
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.
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.
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. ;) )
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.
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.
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. I think that the time has passed; it takes twenty five years, and it takes maniacal devotion to the cause.
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.
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.
IMHO, Turso spent a lot of time on rewrites and what’s possible instead of finding PMF.
Im not that familiar with agentic ai or supabase or turso, just curious about their tagline.