rcrowley

It felt rude to take so many r8gd instances away from our customers who really love those (and i8g and i8ge).

Yes, you can certainly use up your CPU allocation on an M-10 database (at which point we offer online resizing as large as you want to go, all the way up to 192 CPUs and 1.5TiB RAM). Even still, I've been able to coax more than 10,000 IOPS from an M-10. (Actually, out of dozens of M-10s colocated on the same hardware all hammering away.)

You can get a lot more out of that CPU allocation with the fast I/O of a local NVMe drive than from the slow I/O of an EBS volume.

This will be faster than an equivalent RDS instance and will handle more of the operational lifecycle around failover and high-availability with less downtime than RDS.

Within PlanetScale's product lineup, Metal refers to the use of local NVMe drives. Nothing more. These extremely affordable sizes are indeed slices of larger boxen, though no resources are overcommitted.

Soon!

These are all three-node clusters with PlanetScale's management handling backup, restore, failover, and replication.

PlanetScale's Postgres offering is as close to plain-old-Postgres as we could possibly build.

We run on the same instance types the larger PlanetScale Metal sizes offer as whole instances. For Intel that's r6id, i4i, i7i, i3en, and i7ie. For ARM that's r8gd, i8g, and i8ge. (Right now, at least. AWS is always cookin' up new instance types.) Same story will soon be true for GCP.

We've engineered in protections from noisy neighbors in both CPU and I/O usage and we do not over-commit resources.

If your or another customer's workload grows and needs to size up we launch three whole new database servers of the appropriate size (whether that's more CPU+RAM, more storage, or both), restore the most recent backups there, catch up on replication, and then orchestrate changing the primary.

Downtime when you resize typically amounts to needing to reconnect i.e. it's negligible.

PlanetScale operates databases in AWS and GCP. There's no network latency penalty for choosing PlanetScale if you're hosting your app in one of those cloud providers (and in one of the many regions we operate in).

Correct you are.

Just want to add that you don't necessarily need to invest in fancy disk-usage monitoring as we always display it in the app and we start emailing database owners at 60% full to make sure no one misses it.

RAID isn't the answer, either, for the record. In AWS and GCP, the CPU or RAM blowing up will cost you access to that local NVMe drive, too, no matter how much RAID you throw at it.

Yes, a single disk in a VPS or cloud provider has durability concerns. That's why EBS and products like it that pretend to be a single disk are actually several. Instead of relying on multiple block devices, though, we create that redundancy at a higher level by relying on multiple MySQL or Postgres servers for durability, each with a local NVMe drive for performance.

The question isn't how many orphaned rows do you have, it's whether it matters. Databases are wonderful but they cannot maintain every invariant and they cannot express a whole application. They're one tool in the belt.

I computed P(node failure within MTTR) = 0.00007 same as you. I extrapolated this to the outage scenario P(at least two node failures within MTTR) = P(node failure within MTTR)^2 * (1-P(node failure within MTTR)) + P(node failure within MTTR)^3 = 5.09 * 10^-9 which rounds to 0.0000001%.