Is there a similar effort for Django? Django Sqlite driver is slow and not tested for production.
How (and why) to run SQLite in production
21–30 of 85 posts
Re: How (and why) to run SQLite in production
#22Earlier quoted context omitted.
What's wrong with PRAGMA journal_mode=WAL? It enables concurrent writes, at the expense of disk. Which to my understanding is the same as any other database backend with write ahead logging to enable concurrent writers. Anecdotally, I've seen the WAL file grow way too large even after all writes have finished and should shrink, but that's manageable.
WAL does not help with "database locked" situations. At some point you will see them even with WAL enabled, and your application frontend code has to deal with the timeout and retry or whatever.
Re: How (and why) to run SQLite in production
#23I went through this presentation looking for "how do you do backups" and it glosses over it. But the author blogged about that separately [1]. It seems he uses Litestream with DigitalOcean Spaces for this. Looks like they start at $5 per month for 250 GB [2]. Would that be the best way for a hobbyist to get started? [1] https://fractaledmind.github.io/2023/09/09/enhancing-rails-s... [2] https://www.digitalocean.com/p…
Re: How (and why) to run SQLite in production
#24another article praising sqlite in production and working around a known sqlite limitation: concurrent writes. As they link in the article: > But, my favorite feature of the gem is its improved concurrency support. > [..] https://fractaledmind.github.io/2023/12/11/sqlite-on-rails-i... Really. At the point you are experiencing database locked in your productive app that uses sqlite as backend, i would strongly suggest…
Do your writes really need to be concurrent if they run that fast?
Hard to get upset about waiting for the current write to complete before you get your turn when we are talking delays measured in thousandths of a second.
If you have more than 1000 writes per second then maybe this is something to worry about. The solution there is probably to run a slightly more powerful server!
Re: How (and why) to run SQLite in production
#25It's not immediately clear. How does this work over the network for multiple app servers (or does it)? Is the DB hosted on something like nfs, or are writes synced to all app servers or something else?
Re: How (and why) to run SQLite in production
#26another article praising sqlite in production and working around a known sqlite limitation: concurrent writes. As they link in the article: > But, my favorite feature of the gem is its improved concurrency support. > [..] https://fractaledmind.github.io/2023/12/11/sqlite-on-rails-i... Really. At the point you are experiencing database locked in your productive app that uses sqlite as backend, i would strongly suggest…
In my experience most SQLite writes take less than 1ms. Do your writes really need to be concurrent if they run that fast? Hard to get upset about waiting for the current write to complete before you get your turn when we are talking delays measured in thousandths of a second. If you have more than 1000 writes per second then maybe this is something to worry about. The solution there is probably to run a slightly mor…
Does SQLite support overlapping write transactions with locks on different rows?
Also do you know if WAL2 mode changes anything? https://www.sqlite.org/cgi/src/timeline?r=wal2
Re: How (and why) to run SQLite in production
#27another article praising sqlite in production and working around a known sqlite limitation: concurrent writes. As they link in the article: > But, my favorite feature of the gem is its improved concurrency support. > [..] https://fractaledmind.github.io/2023/12/11/sqlite-on-rails-i... Really. At the point you are experiencing database locked in your productive app that uses sqlite as backend, i would strongly suggest…
In my experience most SQLite writes take less than 1ms. Do your writes really need to be concurrent if they run that fast? Hard to get upset about waiting for the current write to complete before you get your turn when we are talking delays measured in thousandths of a second. If you have more than 1000 writes per second then maybe this is something to worry about. The solution there is probably to run a slightly mor…
ive just put it here: https://github.com/abbbi/sqlitestress
maybe its useful for some people to simulate their workloads.
Re: How (and why) to run SQLite in production
#28another article praising sqlite in production and working around a known sqlite limitation: concurrent writes. As they link in the article: > But, my favorite feature of the gem is its improved concurrency support. > [..] https://fractaledmind.github.io/2023/12/11/sqlite-on-rails-i... Really. At the point you are experiencing database locked in your productive app that uses sqlite as backend, i would strongly suggest…
I am no sqlite fanboy, although I might be, but I found the industry seems to run to postgres for just about anything. I prefer simplicity first.
Re: How (and why) to run SQLite in production
#29Re: How (and why) to run SQLite in production
#30another article praising sqlite in production and working around a known sqlite limitation: concurrent writes. As they link in the article: > But, my favorite feature of the gem is its improved concurrency support. > [..] https://fractaledmind.github.io/2023/12/11/sqlite-on-rails-i... Really. At the point you are experiencing database locked in your productive app that uses sqlite as backend, i would strongly suggest…
Before you even need to consider postgres, you can batch your writes to sqlite! I am no sqlite fanboy, although I might be, but I found the industry seems to run to postgres for just about anything. I prefer simplicity first.
To batch updates makes the code far more complex.
To install any full strength DB is trivial.
I don't get the 'simplicity'?