SQLite in Production: Lessons from Running a Store on a Single File (ultrathink.art)

> json_extract returns native types. json_extract(data, '$.id') returns an integer if the value was stored as a number. Comparing it to a string silently fails. Always CAST(json_extract(...) AS TEXT) when you need string comparison.

More simply:

    sqlite> select typeof('{a:1}'->>'a') ;
    ╭──────────────────────╮
    │ typeof('{a:1}'->>... │
    ╞══════════════════════╡
    │ integer              │
    ╰──────────────────────╯

vs:

    sqlite> select typeof('{a:1}'->'a') ;
    ╭──────────────────────╮
    │ typeof('{a:1}'->'a') │
    ╞══════════════════════╡
    │ text                 │
    ╰──────────────────────╯

> The technical fix was embarrassingly simple: stop pushing to main every ten minutes.

Wait, you push straight to main?

> We added a rule — batch related changes, avoid rapid-fire pushes. It's in our CLAUDE.md (the governance file that all our AI agents follow):

> Avoid rapid-fire pushes to main — 11 pushes in 2h caused overlapping Kamal deploys with concurrent SQLite access.

Wait, you let _Claude_ push your e-commerce code straight to main which immediately results in a production deploy?

> Backups are cp production.sqlite3 backup.sqlite3

I use gobackup[0] as another container in compose.yml file which can backup to multiple locations.

[0]: https://gobackup.github.io/

I've a busy app, i just deploy to canary. And use loadbalancer to move 5% traffic to it, i observe how it reacts and then rollout the canary changes to all.

how hard and complex is it to roll out postgres?

The fix appears to nicely asking the forgetful unreliable agent to please (very closely pretty please!) follow the deploy instructions (and also please never hallucinate or mess up, because statistics tells us an entity with no long term memory and no incentive to get everything right will do the job right 99.99999999% of the time, which is good enough to run an eshop) not deploy too often per hour.

With one simple instruction the system (99.9999% of the time) gains the handy property that “only” two processes end up with the database files open at once.

Thanks for the vibes!

> embarrassingly simple

This is becoming the new overused LLM goto expression for describing basic concepts.

llm generated article.

please consider writing it yourself. quirks in human writing is infinitely more interesting than a next-token-predicted 500 word piece

Redis, four dbs, container orchestration for a site of this modest scope… generated blog posts.

Our AI future is a lot less grand than I expected.

The LLM prose are grating read. I promise, you'd do a better job yourself.

SQLite has a ".backup" command that you should always use to backup a SQLite DB. You're risking data loss/corruption using "cp" to backup your database as prescribed in the article.

https://sqlite.org/cli.html#special_commands_to_sqlite3_dot_...

> 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 don't ever need to upgrade the database if you don't want to, since you're not publicly exposing it. There's obviously no replication lag if you're not replicating, which you wouldn't be with a single server.

The reason you don't usually choose SQLite for the web is future-proofing. If you're totally sure you'll always stay single-server forever, then sure, go for it. But if there's even a tiny chance you'll ever need to expand to multiple web servers, then you'll wish you'd chosen a client-server database from the start. And again, you can run Postgres/MySQL locally, on even the tiniest cheapest VPS, basically just as easily as using SQLite.

I still haven't figured out a good way to due blue/green sqlite deploys on fly.io. Is this just a limitation of using sqlite or using Fly? I've been very happy with sqlite otherwise, rather unsure how to do a cutover to a new instance.

Anyone have some docs on how to cutover gracefully with sqlite on other providers?

I don't know if it's just me, but this whole post seems to have time traveled forward from about 3-4 days ago.

It's not just a repost. The thread includes a comment I made at the time which now from "1 hour ago".

Makes me wonder if it's an honest bug or someone has hacked the hacker news front page to sell their t-shits, mugs, and AI starter kits.

[dead]

could have used firebird embedded, also a simple deployment such as sqllite, but better concurrency and more complete system, also a tad faster

If Nico send him an email. The AI CEO should take his offer.

NIH syndrome, almost mental health issues.

I took three weeks off from tech, read books from last century, and travelled Europe. Coming back, reading LLM generated content and code feels like nails on a chalkboard. Taste, it does not have taste.

[flagged]

[dead]

Just use a 4gb server and install Postgres

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

None of these is needed if you run sqlite sized workloads...

I like SQLite but right tools for right jobs... tho data loss is most likely code bug

Slopcoded article for a Slopcoded website

I use SqLite for a small hobby project, fine for that. Wanted to read the article to see why I should not, but it attacked me with a "subscribe" popup, so I stopped there. The comments here seem to be based on daydreaming on scaling to a lot of users who need 24/7 uptime, which is not always the case.