That gave it away for me. I still appreciate the information contained in the reply but it was obvious. FWIW I don’t mind LLM content as long as I’m learning something.

Your later advice about "VACUUM INTO (backupfile)" is good, though: the SQLite manual guarantees that that's safe. But it's not safe to back up with `cp` if there are transactions currently writing to the DB: that has a chance of copying files in an inconsistent state, resulting in a corrupt DB and data loss you don't realize has happened until you restore the backup and find out there are some rows missing, or some rows have an invalid mix of old and new data.

It really wouldn’t have taken much effort to cut out the worst of the AI fluff, and maybe add some human touches

* is in the article

It's Claude.

Inspired me to finally build (well, vibe code) a cliché detector https://tools.simonwillison.net/llm-cliche-highlighter

https://blog.osull.com/2026/07/06/cliches-in-the-age-of-the-...

apps appear much faster because db is on the same server

So lunchtime in America there will be multiple people posting comments at the same time

And Sqllite only allows one writer, so what happens if multiple people send their comments at once

So are they using ultra fast storage on the host or queues or other

That means you also don't apply updates to the server/kernel that require a reboot until then? Or you accept the downtime? And what happens if it doesn't boot properly?

Generally I target enterprise b2b customers, they use the application from 9-5 generally. Weekly scheduled downtime is not the end of the world.

If it doesn't boot properly, which has never happened, I build a new server - takes 10 minutes max. Litestream keeps database relatively fresh, so it gets pulled on boot. Floating IP points at new server. We do this in dev regularly, the only difference in prod is a few variables.

Even if your target is higher uptime or bigger scale, you can go far further than you think on sqlite - it's multitudes of magnitude quicker than postgres for most general use cases.

Most software projects go nowhere. YAGNI. Build something valuable and people will put up with bullshit for a while.

These posts need to stop comparing their contrived use-cases for SQLite to Postgres. Sure, SQLite is all you need if it really is all you need. But Postgres does so much more than just act as a data dump with an SQL engine on top.

Dr. Hipp himself even said that SQLite does not, and will never, compete with the likes of Postgres. It competes with fopen.

most use cases are really capable of being satisfied by sqlite, but the "architect" imagines they need more (or is preparing for the potential).

I guess I am one of those "architects" that imagines they need an actual date/time storage class instead of some stringly-typed text column that I hope will contain a parsable ISO8601 datetime string when I try to read it back.

Hipp said that it will never be added because it will bloat the size of the embedded object. Because that is what SQLite was designed for: single-user embedded databases. Like the address book on your phone.

To be honest if you're using JSON at any point in your stack you have the same issue.

SQLite will gladly store a u64::MAX as a "unix timestamp" despite it being about 300x larger than the number of seconds that the universe and everything in it has existed.

Try reading that back in any application date/time code and your app probably crashes immediately.

And if your app crashes on an input like that, you should pick a different date Library or stop and rethink your coding skills.

SQLite does not support unsigned integers.

> Try reading that back in any application date/time code and your app probably crashes immediately.

Postgres will happily ingest and produce dates in the 280th millenium, which will also crash your application if its datetime type can’t handle that shrug.

You can add a check constraint that your field passes through SQLite’s datetime functions and it’ll be clamped between the years 0 and 9999. Or you can put in your own limits matching your application layer, or your application’s business logic. That’s what check constrains are for (amongst other things).

omg you're right. Another example of SQLite's type-flimsyness.

> You can add a check constraint

So now we're just layering on our own brittle validation and runtime checks to make up for sqlite's woeful deficiency supporting even basic domain data types.

You're just firing on all the bullshit cylinders in your little motorised gish gallop aren't you?

The only RDBMS in widespread use which supports unsigned integers is mysql. Not postgres, not oracle, not sql server, not db2, not snowflake, not databricks.

> So now we're just layering on our own brittle validation and runtime checks to make up for sqlite's woeful deficiency supporting even basic domain data types.

Ah yes, the "brittle validation" of actually validating the thing you purported to care about two comments ago. Amazing.

So I had to migrate the production db under live load from sqlite to mysql which was a quite ...intense week. I still like sqlite but I'd be wary of using it again for a usecase like mine.

Sqlite does support multi-process access correctly, but the performance is abysmal as it locks the entire file for any write transaction. Client/server databases have much smarter concurrency.

No, it actually competes with Excel.

At least in the finance world, there are still a million small processes driven by an Excel spreadsheet put together in an afternoon by an intern 20 years ago. If it is a really business critical process, then the input is usually a csv file, read by an Excel macro.

Because Excel is user friendly, and "is good enough". Mostly...

But also also, if you have higher concurrency requirements - e.g. multiple servers, one database - or a more write-heavy use case, sqlite is no longer the right choice.

"SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites). The amount of web traffic that SQLite can handle depends on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.

The SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Dynamic content uses about 200 SQL statements per webpage. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time."

How are people solving that issue with SQLite? Everytime I’ve investigated it, it seems like the state of the art is not very battle tested WAL shipping solutions.

If I’m setting something like that up, suddenly running Postgres with its battle tested replication starts to look not so much more complicated in comparison.

"Backups are a file copy. [...] you can back up a live SQLite database, under write load, without stopping anything."

This is straight out of section 1.2 of https://www.sqlite.org/howtocorrupt.html. Yes, you can do that, and sometimes you will end up with a valid, non-corrupt backup. But it's timing-dependent: lose the race and you'll end up backing up a partially written transaction, making the backup corrupt. They didn't end up losing that race when they wrote the article, but that doesn't mean it is safe 100% of the time.

The section later on about running "VACUUM INTO backup-$(date +%F).db" is 100% safe, though: SQLite guarantees that you'll get consistent state if you do that.

Ran into 2.2. https://www.sqlite.org/howtocorrupt.html -- the backup was close()ing the database file descriptor and canceling the SQlite locks.

I use Litestream for offsite backups. SQLite also has a .backup command:

sqlite3 /path/to/db '.backup /path/to/backup'

or

sqlite3 /path/to/db "VACUUM INTO '/path/to/backup'"

Overall premise is wrong though. Moving the database out of process will change performance characteristics and data architecture too much and will cause massive headaches at exactly the time when you are trying to scale with success. You should have out of process performance tests early to catch these issues, even if you do deploy a single node.

If success can be satisfied with a single node and you are satisfied with availability and recovery that gives you then great, but it isn't all I need.

The above article was what convinced me to use SQLite in my new business. 5 years later, serving 120+ million requests per month and still working great. To be fair, most of those requests are served out of redis, but I’m still running off of cheap digital ocean droplets.

You are right to push back on that.