D. Richard Hipp is a genuinely fantastic human being, and SQLite is a project developed at literally the level of planetary infrastructure given how broadly and everywhere it appears.
Forking his project while using the name to garner recognition and attention is poor form, and it is difficult to have faith in the results.
As long as the fork doesnt violate trademark (turso vs sqlite) it is working-as-intended?
I, for one, encourage this kind of behavior. We should have more forks. More forks = more competition = better results for everyone.
---
To make an analogy. Would you say the same thing if this were a for-profit company?
"I cant believe someone else is competing the same space as $x. $x is hugely successful, and so many people use it. I dont know why there's an alternative"
The don't use the name. They use Turso. Even the HN title is wrong - the article title doesn't mention SQLite.
They refer to SQLite, but how could you not if that's what you forked from, and that's what has the functionality you're changing. That would be a very weird article if we didn't have that context.
“The next evolution of SQLite”
That is a material misrepresentation and absolutely trading on the SQLite name
How? The whole point of trademark is to avoid confusing users that an alternate product is the same as the original product.
By explicitly saying "Next evolution of SQLite", or "A fork of SQLite", or a "Better SQLite" .. all of this is saying our product is distinct and different from SQLite.
If the fork were called "nue-sqlite" or "sqlitest" or "fastsqlite", there's an argument to be made.
The problem is that the phrase “the next evolution of SQLite” conveys continuity and endorsement.
A reasonable reader could conclude that Turso is an official successor or the next release of SQLite — that it represents the official lineage of the project.
Phrasing like “SQLite-compatible,” or “a fork of SQLite” would be clear and factual.
Calling it “the next evolution of SQLite” isn’t factual; it’s marketing positioning, and it implies ownership of SQLite’s identity and lineage.
This reflects a broader pattern in how the fork has been presented publicly.
The messaging often treats the original project as something to be fixed rather than a foundation to be respected.
Referring to Turso as a product while leveraging the SQLite name reinforces that framing — co-opting a public-domain engineering gift into a commercial asset.
I've been advocating with several projects over recent years to get SQLite3 as an archive/export/interchange format for data. Need to archive 2019 data from the database, dump it into a SQLite db with roughly the same schema... Need to pass multiple CSVs worth of data dumps, use a SQLite file instead.
As a secondary, I wonder if it's possible to actively use a SQLite interface against a database file on S3, assuming a single server/instance is the actual active connection.
I also got sqlite-s3vfs working from Python a few months ago: https://simonwillison.net/2025/Feb/7/sqlite-s3vfs/
Both of these are very much read-only mechanisms though.
You could achieve this today using one of the many adapters that turn S3 into a file system, without needing to wait for any SQLite buy in.
For example, from Go, you could use my driver, and point it to a database file stored in S3 using this: https://pkg.go.dev/github.com/ncruces/go-sqlite3/vfs/readerv...
For read-write it's a terrible idea. Object storage assumes objects are immutable. There may be some support for appends, but modifying the middle of an object in place involves copying the entire thing.
What is on the verge of becoming viable is to use Litestream to do asynchronous replication to S3, and have read replicas that stream the data directly from S3. But what's stored in S3 isn't a database file, but a format created for the purpose called LTX.
I agree that "the single-writer limitation isn't just a theoretical concern", but it's also solvable without forking SQLite. ulimit's the limit! If your goal is resource maximization of a given computer, though, Postgres is likely a better fit.
The only think turso has in common with postgres is mvcc, which is a rather standard concurrency control model across modern databases. Idk if I answered your question :)
Though this stuff moves slowly (that announcement was almost 3 years ago!), so I'm glad to see Turso giving us options today.
fragmede•4h ago
stronglikedan•3h ago
I'm imagining some insane replication behind the scenes, where every write is happening concurrently on a different SQLite DB, and then merged together sequentially into some master DB.