Live data from Hacker News

How (and why) to run SQLite in production

fractaledmind.github.io

1–10 of 85 posts

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

#2
Might want to proofread it. There are a few paragraphs that are repeating and out of place:

> Why? So, let’s explore that together. Who here is running or has run an application in production with SQLite? Who has experimented with SQLite for an app, but not shipped it to production? There are a couple hands up, but not many. So, let’s turn this question around.

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

#4

Might want to proofread it. There are a few paragraphs that are repeating and out of place: > Why? So, let’s explore that together. Who here is running or has run an application in production with SQLite? Who has experimented with SQLite for an app, but not shipped it to production? There are a couple hands up, but not many. So, let’s turn this question around.

I think this is paraphrased or exact copy from a conference talk. Not that I love the rhetorical question mode of communication, but it’s more understandable.

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

#5

Might want to proofread it. There are a few paragraphs that are repeating and out of place: > Why? So, let’s explore that together. Who here is running or has run an application in production with SQLite? Who has experimented with SQLite for an app, but not shipped it to production? There are a couple hands up, but not many. So, let’s turn this question around.

This pretty clearly seems to be a transcript of a conference talk, and redundancy and repetition are quite useful for getting a point across in spoken language.

Maybe it could be more accessible when rewritten as a blog post, but if it’s a useful talk I’d much rather have an official transcript than only a video link and maybe Youtube’s auto-transcript.

So much good content is buried in video form for me (I really don’t like watching technical videos and prefer reading that content).

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

#7
I've been using SQLite in production for years and am very happy with it. I believe it's sufficient for the vast majority of web use cases.

I have a bit of battle-tested code that gives me a nice key-value interface to SQLite files, perhaps others will find it useful: https://github.com/aaviator42/StorX

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

#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 to use another database backend that was designed with concurrent writes in mind.

Nothing against sqlite in production, its nice, as long as your workload meets its feature set.

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

#10
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…

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.

Post reply on HN