I'm the first to admit that concurrency is and always has been a point of contention in SQLite. But, on the other hand, when your concurrency problem is "we have to co-ordinate many small-ish inserts from web site users" I'm being told that due to the in-process nature of SQLite and overall good performance of inserts you can do A LOT even with SQLite's concurrency model. IOW manages to be fast enough for concurrency not to be the problem.

I would split out read & write concurrency. With SQLite's WAL mode it supports many readers and one writer. Lobste.rs is a read heavy site so I think SQLite was a good call, especially since now that production is running on SQLite, the proof is in production. If the site was heavy on writes, I would agree with you.

As to why not postgresql or another database, SQLite was as simple as you could get on one box. It is simply a library call rather than a separate process that lives outside of your web application. https://lobste.rs/s/ko1ji1/lobste_rs_is_now_running_on_sqlit...