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...
Comments
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...