I run multiple $10K MRR companies on a $20/month tech stack

https://stevehanov.ca/blog/how-i-run-multiple-10k-mrr-companies-on-a-20month-tech-stack

How I run multiple $10K MRR companies on a $20/month tech stack

Steve Hanov's Blog

> The enterprise mindset dictates that you need an out-of-process database server. But the truth is, a local SQLite file communicating over the C-interface or memory is orders of magnitude faster than making a TCP network hop to a remote Postgres server.

I don't want to diss SQLite because it is awesome and more than adequate for many/most web apps but you can connect to Postgres (or any DB really) on localhost over a Unix domain socket and avoid nearly all of the overhead.

It's not much harder to use than SQLite, you get all of the Postgres features, it's easier to run reports or whatever on the live db from a different box, and much easier if it comes time to setup a read replica, HA, or run the DB on a different box from the app.

I don't think running Postgres on the same box as your app is the same class of optimistic over provisioning as setting up a kubernetes cluster.

Looks like the overhead is not insignificant:

Running 100,000 `SELECT 1` queries:
PostgreSQL (localhost): 2.77 seconds
SQLite (in-memory): 0.07 seconds

(https://gist.github.com/leifkb/1ad16a741fd061216f074aedf1eca...)

gist:1ad16a741fd061216f074aedf1ecaf62

GitHub Gist: instantly share code, notes, and snippets.

Gist
Most important is that that local SQLite gets proper backups, so a restore goes without issues
Gets proper backups if you back it up the right way https://sqlite.org/backup.html
SQLite Backup API