Live data from Hacker News

How (and why) to run SQLite in production

fractaledmind.github.io

21–30 of 85 posts

Re: How (and why) to run SQLite in production

#21

Is there a similar effort for Django? Django Sqlite driver is slow and not tested for production.

It also seems to have the same concurrency issues as described in the article. At least from my experience the "database is locked" error appears quite often.

Re: How (and why) to run SQLite in production

#22
post #11
post #10

Earlier 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.

[deleted]

Re: How (and why) to run SQLite in production

#23

I 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…

I checked your blog and I am impressed you are still very curious to learn things which didn't exist before you retired (generative AI).

Re: How (and why) to run SQLite in production

#24
post #9

another 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 more powerful server!

Re: How (and why) to run SQLite in production

#25

It'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?

IIUC it does not work, the assumption here is that you can serve all your traffic with a single instance

Re: How (and why) to run SQLite in production

#26
post #24
post #9

another 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…

Sure the actual write might only take 1s but the transaction might lock for 10ms.

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

#27
post #24
post #9

another 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…

back in the days where we hit this issue (mostly on windows systems) i used to create a little stress tool, you would be surprised how fast you reach the database-locked state.

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

#28
post #9

another 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.

Re: How (and why) to run SQLite in production

#30
post #28
post #9

another 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.

How it that simplicity?

To batch updates makes the code far more complex.

To install any full strength DB is trivial.

I don't get the 'simplicity'?

Post reply on HN