$50 PlanetScale Metal Is GA for Postgres

> 'unlimited I/O' because you hit CPU before saturating the disk.

So in the M-10 case, wouldn't this actually be somewhat misleading as I imagine hitting "1/8 vCPU" wouldn't be difficult at all?

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.

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.

Same. Love PlanetScale, love their previous website design. I struggle reading white text on black backgrounds, so I don't even try to read their product pages or blog posts since there's no light mode :( (yes I know about reader mode)

Was curious what it looks like now, and yea, not a fan of the fake hacker "we don't do CSS or styling". But then again maybe I was just used to their old design

Can you provide an example of a website you approve?

Thank you for the feedback.

From the PlanetScale perspective keep in mind the ability to shard. What happens when the largest single node Aurora instance can no longer keep up with application/traffic demands?

I ask because we see it more often than not, and for that situation sharding the workflow is the best answer. Why have one MySQL instance responding to request when you could have 2,4,8...128, etc MySQL instances responding as a single database instance? They also have the ability to vertically scale each of the shards in that database as it's needed.

I had the same latency concerns when I heard about this PaaS DB trend, but you’ll note that this runs in the AWS (soon GCP) region of your choice, so if you’re hosted there, it should be about the same latency as using their managed DB service.

If you aren’t hosting the app in the same AWS/GCP region then I still have the same question.

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

It depends a bit on your cloud provider but some of them have an offering that doesn't always match your needs or their pricing might be much more expensive at equal performance.

I don't think either is a bad choice, but Aurora has some advantages if you're not a DB expert. Starting with Aurora Serverless:

- Aurora storage scales with your needs, meaning that you don't need to worry about running out of space as your data grows. - Aurora will auto-scale CPU and memory based on the needs of your application, within the bounds you set. It does this without any downtime, or even dropping connections. You don't have to worry about choosing the right CPU and memory up-front, and for most applications you can simply adjust your limits as you go. This is great for applications that are growing over time, or for applications with daily or weekly cycles of usage.

The other Aurora option is Aurora DSQL. The advantages of picking DSQL are:

- A generous free tier to get you going with development. - Scale-to-zero and scale-up, on storage, CPU, and memory. If you aren't sending any traffic to your database it costs you nothing (except storage), and you can scale up to millions of transactions per second with no changes. - No infrastructure to configure or manage, no updates, no thinking about replicas, etc. You don't have to understand CPU or memory ratios, think about software versions, think about primaries and secondaries, or any of that stuff. High availability, scaling of reads and writes, patching, etc is all built-in.

They have a very nice comparison in terms of performance and price https://planetscale.com/benchmarks/aurora

It will be faster and a lot easier to use than Aurora.

Do such small caps on CPU/RAM mean that multiple customers are sharing the same server? Is there concern for noisy neighbors here, either IOPS or in case another customer's workload grows to take the full available storage on the NVMe? What kind of downtime would be needed to switch to a larger size?

Why is Metal not offered for single instance deploys? Our app does not need this kind of uptime. We would be happy with a node going down once in a while (no data loss, of course) with a little bit of downtime to save 66% on the cost of running 2 additional nodes that will never see action.

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

It's just a hosted Postgres database, you could run this locally with Docker for example: https://hub.docker.com/_/postgres

Soon!

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.

there aren't per customer IOPs limits but the CPU will be the bottleneck.

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.