3 ms·

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

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

omarqureshi 1y ago
Literally prior to the cloud being a thing, for medium sized web apps, this was the way.
- ok_computer 1y ago
  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.
  - markusw 1y ago
    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.
    - ok_computer 1y ago
      Noted, that confirms my suspicion. Thanks.
markusw 1y ago
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!
BiteCode_dev 1y ago
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.
- JodieBenitez 1y ago
  Damn... looks like my job is secured for another 25 years.

omarqureshi 1y ago

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

ok_computer 1y ago
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.
- markusw 1y ago
  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.
  - ok_computer 1y ago
    Noted, that confirms my suspicion. Thanks.

markusw 1y ago

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!

BiteCode_dev 1y ago

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.

JodieBenitez 1y ago
Damn... looks like my job is secured for another 25 years.