huh? That is clearly not the case. memory bugs - sure. Not having a public test suite, not accepting public contributions, weakly typed columns and lack of concurrency has nothing to do with the language. They're governance decisions, that's it.
>I see this situation trhough the prism of the innovator's dilemma: the incumbent is not willing to sacrifice a part of its market to evolve, so we need a new player to come and innovate.
I don't think the innovators dilemma quite applies in the open source world. Projects are tools, that's it. Preserving a project for the sake of preserving it isn't a good idea.
If people need to run a sqlite db in these exotic places, shedding it means someone else has to build their own tool now that can do it. Sqlite has decided that they care about that, so they support it, so they can't use rust. Seems sound.
Projects coming and going is a good thing in open source, not a bug.
That's an extraordinary claim for any C codebase.
Unless it ships with code enabling concurrency that is commented out, we should assume that "concurrency in C ain't easy" was a factor in that design choice.
See the features and roadmap at https://github.com/tursodatabase/turso
In the past I've reached for FirebirdSQL when I needed local + external databases and wanted to limit the technology spread... In the use case, as long as transactions synched up even once a week it was enough for the disparate remote connections/systems. I'm honestly surprised it isn't used more. That said, SQLite is more universal and lighter overall.
The RIIR-benchmark: rewrite CPython in Rust, pass the complete test suite, no performance regressions, $100 budget. How far away are we there, a couple months? A few years? Or is it a completely ill-posed problem, due to the test suite being tied to the implementation language?
We've all been around long enough to know that "free" VC-backed software always means "free... until it's in our interest to charge for it". And yet users will still complain about the rugpull in 2026, no matter how many times they've been through it. "Fool me once, shame on you"
1) It's MIT licensed. Including the test suite which is something lacking in SQLite:
https://github.com/tursodatabase/turso
2) They have a paid cloud option to drive income from:
That says enough.
I’ve been confused by this for a while. What is it competing with? Surely not SQLite, being client server defeats all the latency benefits. I feel it would be considered as an alternative to cloud Postgres offerings, and it seems unlikely they could compete on features. Genuinely curious, but is there any sensible use case for this product, or do they just catch people who read SQLite was good on hacker news, but didn’t understand any of the why.
Unless you are Amazon which has the resources to maintain a fork (which is questionable by itself with all the layoffs), you probably shouldn't touch this.
I'm not ready to entertain Turso as an alternative to something that is as battle tested as Sqlite.
I think it's time for a new law of headlines: anything labeled a "deep dive" isn't.
It looks like some parts are open source and other not. Does anyone know more about the backstory? (It looks like one is a custom program that generate fuzz test. Do they sell it to others SQL engines?)
it's free
but if you want the compliance paperwork, you pay for it
9rx•1h ago
Why not Postgres? https://pglite.dev
causalscience•1h ago
Because I don't want another server/service.
Is this a good enough justification in your opinion, or did you just want to say the meme?
avhception•1h ago
roywiggins•1h ago
duped•41m ago
edit: it looks like pglite is only useful for web apps
rudedogg•1h ago
I’m excited to see things improve though. Having a more traditional database, with more features and less historical weirdness on the client would be really cool.
Edit: https://pglite.dev/benchmarks actually not looking too bad.. I might have something new to try!