Running instances, not machines. There's like 15 years of architectural advancement in running web apps that says that more than one copy of stateless software is the best practice. SQLite was not designed to be used for web apps.
HN's bizarre groupthink occasionally decides to subvert architectural norms for fun, and any blog post that's trending on the front page suddenly counts as "good advice". Even if it's literally insane, if it's on the front page it's considered sage wisdom, and naysayers are downvoted for being negative about the insanity.
Those 15 years of architectural norms started at a time where a multi-core 2GB server was an expensive luxury!
We know a LOT more today about building web applications than we did 15 years ago. That's why some of us are ready to say that for a lot of applications, a single server running SQLite (with streaming backups to S3 via Litestream) is actually a pretty great option.
I don't mean use 15-year old patterns, I mean we've learned over 15 years what's good practice and what isn't.
We used to use .csv and .ini files that way. After that we used BerkeleyDB, since it was built into so many tools. Or serialized objects. If you got fancy you'd read/write them to a temporary filesystem, and occasionally sync the files to NFS; if the app restarts, sync the files from NFS back to temporary storage, or if the temporary file isn't there, read it from NFS and write it to temporary storage.
Today, if you have to write a web app that has dynamic content and writes and reads user data, you can do it a bunch of ways:
- "Mostly-JS": Write your app in JavaScript. Some hosted provider out there allows you to submit data to some backend app, and read it from the backend app. (This, by the way, is how CGI-BIN web apps worked 20 years ago)
- "Mostly-CGI": Use some managed hosting provider to host a web app with some framework they support, like Wordpress, or Django, or something else. Typically they bundle a networked relational database with it, but I suppose you could trade that out for an sqlite file. Probably wouldn't support Litestream but you could probably have a cron job copy the file to s3.
- "Mostly-standalone": Buy some virtual machine or physical server, set it up, maintain it, write your web app, run a web server that runs your web app, write the file to local disk, set up Litestream. Never touch it, patch it, upgrade it, etc, so it always has security vulns, but it will just keep running, so it will be much easier to get going.
- "Mostly-managed": Pay for some hosted provider to give you the ability to run your app in containers. You build it, you push it, and then set up the thing to run it. Like the previous option, you can opt to never patch or upgrade anything so there's nothing to maintain. But since you can use a bunch of SaaS providers to build, test, and deploy automatically, it's way less to maintain and much more automated. Again, typically you'd use a networked relational database, since they're largely designed to run one app at a time, but you can customize them to have some background task try to upload your sqlite file out of the container or a sidecar.
- "Completely managed": You upload your code. They completely manage the versions of your app platform, doing patches, upgrades, running different instances of your app, databases, web servers, whatever you need. You basically don't have to think about anything but code. You could use sqlite but there's probably no way to back it up.
If you don't need to read and write user data, you don't need a web app at all. A static site works just fine. Hell, you don't even need a static site generator anymore, just link to the right css or js files in your html to DRY up your static content.
Vast vast majority of web apps run fine on a relatively modest VPS. And almost all will run fine on a beefy dedicated server. No amount of best practice changes that.
Best practice is the practice that works the best. That isn't groupthink. If it works, it works, regardless of whether a single person or a group is doing it. Groupthink would be whatever the group thinks is best, which isn't necessarily what actually works well at all.
The reason why running an app on a VPS is not best practice isn't that the VPS can't handle it; it's not a question of scale. The issue is that there are many different problems with running an app on a VPS, and it is much better to avoid those problems by not using a VPS at all, rather than to spend a lot of time trying to mitigate those problems on the VPS. If there is an alternative that is lower cost than the cost of mitigating the issues on the VPS, then that's the better solution.
It turns out that there are solutions like that, among them Heroku/DigitalOcean App Platform, DigitalOcean K8s/AWS EKS/GCloud GKE, Fly.io/AWS Fargate, Google Cloud Run/AWS App Runner, AWS Lambda/Google Cloud Functions, and many more. Almost all of these are better than running your own VPS, because they are designed to remove the problems you will inevitably run into with your own VPS.
Some people buy cheap things and replace them frequently. Some people invest in better quality that lasts longer. If you'd rather patch the holes in things rather than simply last longer, a VPS may be the solution you want. But it's certainly not the best solution.
HN's bizarre groupthink occasionally decides to subvert architectural norms for fun, and any blog post that's trending on the front page suddenly counts as "good advice". Even if it's literally insane, if it's on the front page it's considered sage wisdom, and naysayers are downvoted for being negative about the insanity.