4 ms·

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

by runako 6mo ago

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.

crazygringo 6mo ago
> Backups are much more straightforward for SQLite. Not sure how? All of them can be backed up with a single command. But if you want live backups (replication) as opposed to daily or hourly, SQLite is the only one that doesn't support that.
- MitziMoto 6mo ago
  Litestream exists?
  - crazygringo 6mo ago
    That's a third-party tool. It's not part of SQLite. And it's a pretty hacky usage of the WAL. If it works for you, great, but if I need replication, I'm going to want a database that supports it natively.
jbrogers63 6mo ago
"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?