5 ms·
SQLite is ok if you don't have much traffic (for example personal blogs), but you can't replace a db like Postgresql with SQLite if you have lot of concurrent t
by iamd3vil 9y ago
SQLite is ok if you don't have much traffic (for example personal blogs), but you can't replace a db like Postgresql with SQLite if you have lot of concurrent traffic.
- hasenj 9y ago99% of the internet can use SQLite. Not just "personal blogs". Just about anything that's not facebook/twitter/google. I think you underestimate how much load it can handle.
- muxator 9y agoSupposing that your server-side tech uses multiple workers to render pages, I suppose you have to serialize the access to the SQLite file. What is the best way to do this?
- deafcalculus 9y agoSQLite can handle concurrent reads, but needs to lock the entire DB when writing. Multiple workers shouldn't be a problem per se, but if you need multiple workers to support the traffic, then maybe a client-server db like postgres is a better choice.
- hasenj 9y agoWriting does not lock readers if you use the WAL feature (Write-Ahead Log, introduced in 2010) https://sqlite.org/wal.html https://sqlite.org/wal.html > WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently.
- deafcalculus 9y agoRight. I meant it doesn't support concurrent writes.
- zaarn 9y agoOn any personal website, that shouldn't be much of a problem, most blogs have only a few writes at a time