Hacker News Reader

Comment by catmanjan | Hacker News Reader

10K users isn’t much, but 10k concurrent writer’s is a different proposition - I’d be surprised if 100k users had 10k concurrent writers

View on HN

That's a fair point. AFAIK SQLite uses a queue (in WAL mode) in order to handle concurrent writes. I imagine it basically couldn't handle 10K concurrent writes to begin with in a practical application since newly read data would be out of date pretty quickly.

I’m not sure as I’ve never used it but if the writes were fast enough perhaps it wouldn’t be a problem

idk, the author themselves don't recommend it:

>If many threads and/or processes need to write the database at the same instant (and they cannot queue up and take turns) then it is best to select a database engine that supports that capability, which always means a client/server database engine.

https://www.sqlite.org/whentouse.html

That reads to me like a somewhat-sarcastic way to make fun of people who think SQLite can't handle their write load.

Not a lot of applications have many processes that need to write at the same instant in time and cannot be put in a queue instead.

Why build a queue before you really need it when you can just use postgres?

To be explicit, SQLite doesn't support concurrent writers. In WAL mode it can handle a single writer with concurrent readers. In "vanilla" mode, a writer requires exclusive access to the database.

Reply on news.ycombinator.com