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

More importantly, no bandwidth charge penalty. As leaving AWS isn't inexpensive.

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.