You can see this in the article here, where they are just using whatever garbage queries Prisma spits out.

I’ve contended for a long time that ORMs and their ilk automatically building queries is an antipattern for anything but small data scale. At any reasonable size of db, you’re going to need to know sql well enough to write optimized queries anyway. There’s essential complexity in the DB queries, which ORMs can only hide for so long.

And do not consider owning the hardware. See what hardware you can buy for that money.

How many servers are needed to bounce back from a server failure in a few minutes? Should we consider 3 VMs instead of 1 physical?

Two. Run one in warm/hot standby, optionally with synchronous commits if you want (nearly) guaranteed zero data loss, and can tolerate the increased write latency.

Technically you’ll need a third server to perform the failover, but it doesn’t need to be nearly as big, as it’s just watching heartbeats and issuing commands.

Server failures are rare. Its still usually going to be cheaper to have physical servers even with spare capacity for failures.

I think these days it's more: were do we find the grey old unix guy who confidently will host your db for you on bare metal.

Which these days seems to mean a 35+ year old who has ever worked on anything other than a big-three cloud.

I’m a mid-30-something who has worked in all three as well as several of the “alt cloud” providers. Typically identified as Linode, DigitalOcean, Hetzner, sometimes Rackspace. I’ve used all of those and more.

Bare metal is absolutely where it’s at for base infrastructure and bang-for-you-buck.

People call me a graybeard for such things, but it’s never been said derisively or sarcastically to my face. Usually it’s asking for advice.

I took a “traditional” path here. I started when “the cloud” was just the fluffy white cloud that said “Internet” or “Other Networks” at the top of the diagram.