3 ms·

Are you suggesting using 2 different web hosting companies? If so, latency must be brutal for a web app.

• solardev 4y ago
  It really depends on your setup and performance and scaling needs. If I were doing it and I had to use PHP and Postgres, I'd abstract away the stack as much as possible (using the aforementioned serverless vendors for both the DB and PHP layers). And then I'd cache the HTML output using Cloudflare, or Varnish if you want to in house it. But I dunno your app. Maybe you need good frequent write performance (a social app, for example), in which case a read cache won't do you much good. I wouldn't say that having the DB and PHP in separate data centers (but within the same general reason) would be an automatic dealbreaker. You can test it and see. If you have to have everything in one area you should still be able to do that with something like Google Cloud (app engine plus managed Postgres in the same zone). Maybe AWS or azure has a similar offering. I think digitalocean can run PHP too but it's been a while and I forget how low level (or not) they are. You can go all the way down to a old school LEMP stack if you really want to (on a vm or bare metal) but even the vendors that are "fully managed" are not the same as actual abstractions like the serverless, because they still have to semi manually apply upgrades, etc. and can sometimes take a few days. Support is expensive too (but usually good), whereas you can avoid those complexities with a more abstracted serverless stack. There are a bunch of tradeoffs between speed, maintenance, cost, reliability, support, etc. If you explain more about your needs, happy to discuss it more. If you're more comfortable with a single vendor bare metal VM like the early 2000s kind, keep looking, they have to be out there somewhere...