Postgres (esoterically?) has some issues with index bloat on high-insert workloads, does PlanetScale do anything special to tune for this by default, since it caters to higher-perf workloads (over something like supabase)?

How should one decide whether to go with MySQL or Postgres for a greenfield project?

If neki becomes available later, do you expect that customers will be able to easily migrate over to it?

Extensions! Which pg extensions are you going to make available?

corrected. thank you

Thanks for that callout, absolutely right. Fixed!

PlanetScale isnt' really designed for the "ill give it a go" casual customer that might use supabase

It's designed for businesses that need to haul ass

PlanetScale (famously?) deprecated their free "Hobby" tier (plus fired their sales & marketing teams) back in 2024 to achieve profitability

https://planetscale.com/blog/planetscale-forever

Kind of. For horizontally scaling writes we are building the Vitess for Postgres which we are calling Neki https://www.neki.dev/

The product we are GA'ing today has the option of PlanetScale Metal which is extremely fast and scales write QPS further than any of the other single-primary Postgres hosts.

But it's done at a scale that's planetscale

i'll take the opposite side. i was very impressed with their website.

the very first line:

> The world’s fastest and most scalable cloud databases

the second line:

> PlanetScale brings you the fastest databases available in the cloud. Both our Postgres and Vitess databases deliver exceptional speed and reliability, with Vitess adding ultra scalability through horizontal sharding.

i know exactly what they do. zero fluff. and, i'm now interested.

https://planetscale.com/

idk in the linked post it literally says this in the 2nd paragraph:

> Our mission is simple: bring you the fastest and most reliable databases with the best developer experience.

Out of curiosity: how do you connect your databases to external services that are consuming these data? In places I do similar work, databases are usually in the same private network as the instances which are reading and writing data to them. If you put them somewhere on the internet, apart from security, doesn't it affect latency?

Would you mind sharing what you were migrating from, and what kind of issues you ran into?

Care to elaborate what kind of issues? Looking into migrating as well.

It's still AWS/GCP, but it uses instance types with local NVMes.

hosting on AWS/GCP on the ephemeral NVMe nodes. https://planetscale.com/metal

can't speak to GCP specifically but usually the issue is they are host-attached and can't be migrated, so need to be wiped on VM termination or migration -- that's when you lose data.

Reboots typically don't otherwise do anything special unless they also trigger a host migration. GCP live migration has some mention of support though

GCP mentions data persists across reboots here https://cloud.google.com/compute/docs/disks/local-ssd#data_p...

note that stop/terminate via cloud APIs usually releases host capacity for other customers and would trigger data wipe, a guest initiated reboot typically will not.

We deal with this by always running 3 nodes in a cluster, one per AZ, and strong backup/restore processes.

So yes, the data per-node is ephemeral, but it is redundant and durable for the whole cluster.