3 ms·
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
by catmanjan 4y ago
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
- endisneigh 4y agoThat'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.
- catmanjan 4y agoI’m not sure as I’ve never used it but if the writes were fast enough perhaps it wouldn’t be a problem
- endisneigh 4y agoidk, 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 https://www.sqlite.org/whentouse.html
- simonw 4y agoThat 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.
- antifa 4y agoWhy build a queue before you really need it when you can just use postgres?
- deleted 4y ago[deleted]
- pdw 4y agoTo 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.