Lobste.rs is now running on SQLite
lobste.rsI don't understand why SQLite has become popular for stuff like a website where it is not really a good fit due to concurrency.
If HA, replication, etc isn't needed, installing and running PostgreSQL or MySQL isn't much more complicated than SQLite.
> where it is not really a good fit due to concurrency
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.
> it is not really a good fit due to concurrency.
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...