PlanetScale for Postgres is now GA (opens in new tab)

Their databases are hosted on AWS and GCP so latency isn't much of an issue. They also have AWS Private Link and if configured it won't go over the internet.

PlanetScale runs in AWS/GCP, so not really “somewhere on the internet” if your workload is already there.

This is the thought I always come back to with the non-big cloud services. It’s pretty much always been mandatory at non-startups to have all databases to be hidden away from the wider internet.

The issues weren't PlanetScale related. We use Hasura and when we did the cutover, we connected to the DB via PGBouncer and some features don't work right. Started seeing a lot of errors so paged them and they helped out. We were connecting directly to PG previously but when we cutover we missed that.

The first few sentences mean absolutely squat.

> Our mission is simple: bring you the fastest and most reliable databases with the best developer experience. We have done this for 5 years now with our managed Vitess product, allowing companies like Cursor, Intercom, and Block to scale beyond previous limits.

> We are so excited to bring this to Postgres. Our proprietary operator allows us to bring the maturity of PlanetScale and the performance of Metal to an even wider audience. We bring you the best of Postgres and the best of PlanetScale in one product.

Seriously??

Literally the first line of every line on the site:

> PlanetScale is the world’s fastest relational database platform. We offer PostgreSQL and Vitess databases that run on NVMe-backed nodes to bring you scale, performance, reliability, and cost-efficiencies — without sacrificing developer experience.

> PlanetScale is a relational database platform that brings you scale, performance, and reliability — without sacrificing developer experience.

> We offer both Vitess and PostgreSQL clusters, powered by locally-attached NVMe drives that deliver unlimited IOPS and ultra-low latency.

> PlanetScale Metal is the fastest way to run databases in AWS or GCP. With blazing fast NVMe drives, you can unlock unlimited IOPS, ultra-low latencies, and the highest throughput for your workloads.

> The world’s fastest and most scalable cloud databases 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.

> Our blazing fast NVMe drives unlock unlimited IOPS, bringing data center performance to the cloud. We offer a range of deployment options to cover all of your security and compliance requirements — including bring your own cloud with PlanetScale Managed.

Ironically, the _how_ is a major topic of the very page you started on (the blog).

Have some agency.

I would just point out that its Hosted Postgres. If your looking for a how I think you have the wrong mental model. Its hosted Postgres, there are some nuance there as to why it would perform differently from RDS on Amazon, or CloudSQL on GCP, but its not some novel new technology that needs a long description.

If you are interested in their new technology that extends on hosted postgres check out Neki https://www.neki.dev/

Well, above the fold in the chapter 'What is PlanetScale for Postgres?' the second paragraph mentions custom operator. That makes me assume it is kubernetes.

> famously?

Notoriously

I am not experienced enough to know the performance differences between planetscale and supabase, but...

> It's designed for businesses that need to haul ass

Could you elaborate what you meant by this for my education?

businesses that 'need to haul ass' usually still want to try something out before buying it. That doesn't need to a a free plan, but it's common to offer some trial period to new users.

Also totally OK if planetscale doesn't do this and that $39/month _is_ the best way to try them out, I just think it would be good for them to make explicit in the article what I should do if I think I might want it but want to try it.

it should be pretty much the same for aurora serverless and likely even cheaper. we see some astronomically expensive auorora serverless bills.

We have not made max_standby_streaming_delay configurable yet. What's your use case?

I don't fully parse your question about blue/green. can you expand your question please? is this for online updrades?

PlanetScale always maintains three (or more, if you want) copies of the data and only acknowledges writes after they've been written to at least two cloud provider availability zones. Durability is provided via replication at the database layer rather than hidden in the slow network-attached block device. Most of our largest customers use Metal for their most critical data and all of them saw their 99th percentile latency plummet when they migrated.

I did an interview all about PlanetScale Metal a couple of months ago: <https://www.youtube.com/watch?v=3r9PsVwGkg4>

we will aim to make it as easy as possible and doable as an online process. with sharding there is always a chance that some application changes are needed so there might be some work required there.

Pre-existing expertise with MySQL and lack of time or inclination to learn something new is the only reason I could think of not to go with Postgres.

At this point I'm not sure why anyone would choose MySQL. Any advantage it had pretty much evaporated with these hosted solutions.

For example, MySQL was easier to get running and connect to. These cloud offerings (Planetscale, Supabase, Neon, even RDS) have solved that. MySQL was faster for read heavy loads. Also solved by the cloud vendors.

From my position

MySQL pros:

The MySQL docs on how the default storage engine InnoDB locks rows to support transaction isolation levels is fantastic. [1] This can help you better architect your system to avoid lock contention or understand why existing queries may be contending for locks. As far as I know Postgres does not have docs like that.

MySQL uses direct I/O so it disables the OS page cache and uses its own buffer pool instead[2]. Whereas Postgres doesn't use direct I/O so the OS page cache will duplicate pages (called the "double buffering" problem). So it is harder to estimate how large of a dataset you can keep in memory in Postgres. They are working on it though [3]

If you delete a row in MySQL and then insert another row, MySQL will look through the page for empty slots and insert there. This keeps your pages more compact. Postgres will always insert at the bottom of the page. If you have a workload that deletes often, Postgres will not be using the memory as efficiently because the pages are fragmented. You will have to run the VACUUM command to compact pages. [4]

Vitess supports MySQL[5] and not Postgres. Vitess is a system for sharding MySQL that as I understand is much more mature than the sharding options for Postgres. Obviously this GA announcement may change that.

Uber switched from MySQL to Postgres only to switch back. It's a bit old but it's worth a read. [6]

Postgres pros:

Postgres supports 3rd party extensions which allow you to add features like columnar storage, geo-spatial data types, vector database search, proxies etc.[7]

You are more likely to find developers who have worked with Postgres.[8]

Many modern distributed database offerings target Postgres compatibility rather than MySQL compatibility (YugabyteDB[9], AWS Aurora DSQL[10], pgfdb[11]).

My take:

I would highly recommend you read the docs on InnoDB locking then pick Postgres.

[1] https://dev.mysql.com/doc/refman/8.4/en/innodb-locking.html

[2] https://dev.mysql.com/doc/refman/8.4/en/memory-use.html

[3] https://pganalyze.com/blog/postgres-18-async-io

[4] https://www.percona.com/blog/postgresql-vacuuming-to-optimiz...

[5] https://vitess.io/

[6] https://www.uber.com/blog/postgres-to-mysql-migration/

[7] https://www.tigerdata.com/blog/top-8-postgresql-extensions

[8] https://survey.stackoverflow.co/2024/technology#1-databases

[9] https://www.yugabyte.com/

[10] https://aws.amazon.com/rds/aurora/dsql/

[11] https://github.com/fabianlindfors/pgfdb

planetscale now supports both :)

Inspired by Vitess seeing as we are the company behind Vitess but it's a new codebase.

Many!

<https://planetscale.com/docs/postgres/extensions>

Can you provide more detail/a reference?

I've done extensive work on improving the Postgres B-Tree code, over quite a number of releases. I'm not aware of any problems with high-insert workloads in particular. I have personally fixed a number of subtle issues that could lead to lower space utilization with such workloads [1][2] in the past, though.

if there's a remaining problem in this area, then I'd very much like to know about it.

[1] https://www.youtube.com/watch?v=p5RaATILoiE [2] https://speakerdeck.com/peterg/nbtree-arch-pgcon

We don't do anything special (yet) but we do have bloat detection that we warn you about. We've noticed that autovacuum works very well on our Metal product because of the extra resources.

On another, similar, vein - i'd be curious to know if XID wraparound and auto vacuum tuning was something you had to advise customers on up front consdering how often that issue rears its head for the same kinds of workloads.

How is this different than Aurora Postgres or RDS Postgres?

Baseless marketing claims aren't considered fluff?

is this web scale?

Thanks for the response, this clarifies things for me because I thought this was already a vitess for postgress implementation. Awesome to hear that this is coming.

Do I understand this right: if these 3 nodes shutdown for some reason, all data is lost and you have to actually restore from backup instead of just starting the machine again. And even if you have to restart one node (due to updates, or crashes) you also have to restore from backup? If so, why not pick a hosting provider that doesn't wipe the disk when machine shuts down?

Hi, thank you for your work on this and being willing to answer questions on it.

"We guarantee durability via replication". I've starting noticing this pattern more where distributed systems provide durability by replicating data rather than writing it to disk and achieving the best of both worlds. I'm curious

1. Is there a name for this technique?

2. How do you calculate your availability? This blog post[1] has some rough details but I'd love to see the math.

3. I'm guessing a key part of this is putting the replicas in different AZs and assuming failures aren't correlated so you can multiply the probabilities directly. How do you validate that failures across AZs are statistically independent?

Thanks!

[1] https://planetscale.com/blog/planetscale-metal-theres-no-rep...

Please reach out to us we would love to talk to you about testing PlanetScale and seeing if we can drive your costs down and performance up.

so it's a "bare metal" virtual machine? Or are they actually using the bare metal offerings for the cloud provider?

A couple dumb questions:

1. You say "ephemeral", but my understanding is that NVMe is non-volatile so upon crash and restart we should be able to recover the state of the memory. Is is ephemeral because of how EC2 works where you might not get that same physical box and memory addresses back?

2. Can you explain what "Semi-synchronous replication" is? Your docs say "This ensures every write has reached stable storage in two availability zones before it’s acknowledged to the client." but I would call that synchronous since the write is blocked until it is replicated.

Thanks!

Congrats on the launch and thanks for responding!

I will try to create a product one day that will have a supabase -> planetscale migration one day to know that I have made it lol (jk)

have a nice day

Hey Sam! Congrats on the launch!

That's a bit vague isn't it? Certainly that does not mean putting something guaranteed even in the same data center, let alone the same rack.