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...
2 comments
[ 0.27 ms ] story [ 13.0 ms ] threadIf HA, replication, etc isn't needed, installing and running PostgreSQL or MySQL isn't much more complicated than SQLite.
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...