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.

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.

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?