What if we treated Postgres like SQLite?

> You can just install Postgres on your single big and beefy application server (because there’s just the one when you use SQLite, scaled vertically), and run your application right next to it.

Am I getting old ? Seems obvious to me.

Literally prior to the cloud being a thing, for medium sized web apps, this was the way.

Hehe. Yes and no.

In the cloud, as you probably know, the usual way now is to spin up Postgres separately (RDS, Supabase, Planetscale, Crunchy Bridge, you name it). We've gotten so used to it that a different way of doing it is often not even considered.

But I think tooling has come a long way, and there have been a lot of learnings from the cloud, so it's time to swing the pendulum back and reconsider assumptions!

I’ve always worked in a datacenter (non cloud) with separate db servers to the app servers. Besides network latency, what is the advantage of collocating the http server and database server on one machine?

It’s always given me a separation of concerns good feeling by seeing a dedicated db and app server and doesn’t seem like much overhead, given they are nearby machines in datacenter.

Also, our main reason was sharing a database license to have a well resourced multi-tenant/app db sever serving peripheral web app servers.

Yes, you are old.

I meet an unexpected number of young devs that:

- Find hypermedia to be exotic. JSON web API is the only way that makes sense to them.

- Say they use the cloud to "save money".

- Use third-party services for things as basic as authentication because "it's hard".

- Encode security stuff in the frontend code.

It's the cycle of life.

The biggest one is latency. Network latency will almost always be orders of magnitude bigger than I/O latency. There's a whole class of problems that goes away when latency becomes very small.

Noted, that confirms my suspicion. Thanks.

Damn... looks like my job is secured for another 25 years.