Live data from Hacker News

SQLite in Production: Lessons from Running a Store on a Single File

ultrathink.art

131–135 of 135 posts

Re: SQLite in Production: Lessons from Running a Store on a Single File

#131

Earlier quoted context omitted.

You're confusing a workman's winking complaint about their tool, with, being unfair by not treating AI like a human.

I'm making a general observation about this frequent genre of complaint.

And I'm lucky enough to be making an observation about your general observation about this frequent genre of complaint

Re: SQLite in Production: Lessons from Running a Store on a Single File

#132

Earlier quoted context omitted.

Yeah, using cp to backup sqlite is a very bad idea. And yet, unless you know this, this is what Claude etc will implement for you. Every friggin' time.

It works fine as long as no one is writing to the sqlite file and you are not in WAL mode, which is not the default.

But we were talking server loads here: anyone runs sqlite server-side not in WAL mode?

Re: SQLite in Production: Lessons from Running a Store on a Single File

#133

Earlier quoted context omitted.

I'm making a general observation about this frequent genre of complaint.

And I'm lucky enough to be making an observation about your general observation about this frequent genre of complaint

I don't get what you're trying to say then.

Re: SQLite in Production: Lessons from Running a Store on a Single File

#135
post #43

> Would We Choose SQLite Again? Yes. For a single-server deployment with moderate write volume, SQLite eliminates an entire category of infrastructure complexity. No connection pool tuning. No database server upgrades. No replication lag. These are weird reasons. You can just install Postgres or MySQL locally too. Connection pool tuning certainly isn't anything you have to worry about for a moderate write volume. You…

Have run PG, MySQL, and SQLite locally for production sites. Backups are much more straightforward for SQLite. They are running Kamal, which means "just install Postgres" would also likely mean running PG in a container, which has its own idiosyncrasies. SQLite is not a terrible choice here.

"On our t3.small (2GB RAM), the web container uses ~780MB. Spawning an exec container for a quick database query adds another ~500MB. Two concurrent exec calls during a deploy? That's 2.5GB on a 2GB machine. OOM killer takes the web process down."

I suspect this is the reason for SQLite and not PG or some other DB. From my read of the article, it sounds like they're running lean (single host for web, db, etc). PG et. al. add overhead that they likely can't (or more likely won't want to) afford on that box. Maybe I'm wrong?

Post reply on HN