Lobste.rs is now running on SQLite
lobste.rs
Lobste.rs is now running on SQLite
1–4 of 4 posts
Re: Lobste.rs is now running on SQLite
#2If HA, replication, etc isn't needed, installing and running PostgreSQL or MySQL isn't much more complicated than SQLite.
Re: Lobste.rs is now running on SQLite
#3I 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.
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.
Re: Lobste.rs is now running on SQLite
#4I 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.
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...