[HN Gopher] Beyond the SQLite Single-Writer Limitation with Conc...
___________________________________________________________________
Beyond the SQLite Single-Writer Limitation with Concurrent Writes
Author : syrusakbary
Score : 43 points
Date : 2025-10-07 20:32 UTC (7 days ago)
(HTM) web link (turso.tech)
(TXT) w3m dump (turso.tech)
| fragmede wrote:
| Can't use it locally (yet?) but it's definitely an interesting
| move in the space. For my personal projects lately I've been
| defaulting to sqlite in dev, and having a database wrapper layer
| to use something else in prod.
| stronglikedan wrote:
| > Can't use it locally
|
| 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.
| frumplestlatz wrote:
| I'm not in a rush to use a reimplementation of SQLite --
| particularly from startup bros that had a very public, one-sided,
| and unpleasant fight with SQLite over their contribution model.
|
| 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.
| bitpush wrote:
| I get where you're coming from, but isnt the whole idea of open
| source "if you dont like the approach, you're free to fork the
| code and do it the way you think is right?"
|
| 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"
| stronglikedan wrote:
| > Forking his project while using the name
|
| 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.
| frumplestlatz wrote:
| They state, plainly on their home page:
|
| "The next evolution of SQLite"
|
| That is a material misrepresentation and absolutely trading
| on the SQLite name
| bitpush wrote:
| "The next evolution of SQLite"
|
| 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.
| frumplestlatz wrote:
| The issue isn't that you're mentioning SQLite or
| acknowledging that it's a fork.
|
| 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.
| Permik wrote:
| I'd still give them the benefit of the doubt as most (all?) of
| the contributors are Finns who you can almost guarantee to have
| a "no bullshit" type of mentality to essentially everything.
| And what I'd guess, the team most probably has quite an
| academic background because of the local culture.
| tracker1 wrote:
| Kind of cool to see work on this. I do hope that the final db
| file result is still binary compatible with SQLite 3 in whatever
| direction Turso moves towards though... Rust or not.
|
| 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.
| simonw wrote:
| SQLite against S3 can work with some clever tricks. The neatest
| version of that I've seen is still this WebAssembly one:
| https://phiresky.github.io/blog/2021/hosting-sqlite-database...
|
| 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.
| huntaub wrote:
| > 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.
|
| 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.
| ncruces wrote:
| SQLite directly against S3 is workable if you mean querying a
| read-only database.
|
| 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.
| conradev wrote:
| The single-writer limitation in SQLite is per-database, not per-
| connection. You can shard your SQLite tables into multiple
| database files and query across all of them from a single
| connection.
|
| 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.
| asfs4fsdfadf wrote:
| Can someone explain what "ecological niche" this new Turso DB
| occupies in between SQLite and Postgres?
| SchwKatze wrote:
| TursoDB aims to be fully compatible with sqlite, so files you
| create with tursodb can be read by sqlite and vice-versa. Like
| sqlite, turso is in-process, so it runs alongside your
| application, which is quite different from postgres' client-
| server architecture.
|
| 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 :)
| spiffytech wrote:
| Don't forget that the SQLite team is working on their own multi-
| writer mode that blows BEGIN CONCURRENT' out of the water:
| https://news.ycombinator.com/item?id=34434025
|
| Though this stuff moves slowly (that announcement was almost 3
| years ago!), so I'm glad to see Turso giving us options today.
| simonw wrote:
| Looks like that branch is still under actively development -
| seven new commits this month:
| https://sqlite.org/hctree/timeline
___________________________________________________________________
(page generated 2025-10-14 23:00 UTC)