PlanetScale for Postgres is now GA • Hacker News Board

Re: PlanetScale for Postgres is now GA

#101

Post by maxenglander » Mon, Sep 22, 2025, 7:00 PM UTC

n_u wrote: post #73

samlambert wrote: post #39

Earlier quoted context omitted.

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

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…

Hi n_u,

When we say ephemeral we mean that if the host compute dies in a permanent way (which happens from time to time) the data on the NVMe drives attached to that host is not recoverable by us. AWS/GCP might have recovery mechanisms internally it, but we don't have API access to those APIs.

When we say "semi-synchronous replication" we mean it in the sense of MySQL semi-synchronous replication: https://dev.mysql.com/doc/refman/8.4/en/replication-semisync.... To be honest I'm not exactly sure where the "semi" comes from but here are two possible reasons I can think of why:

1. We actually only require that 1 of the 2 replicas sends an acknowledgement to the primary that it has durably stored the transaction to its relay log before the primary in turn sends an acknowledgement back to the client application. 2. The transaction is visible (can be read) on both the primary and the replica _before_ the primary sends back an acknowledgement that the transaction was committed back to the client application.

Re: PlanetScale for Postgres is now GA

#102

Post by jedberg » Mon, Sep 22, 2025, 7:01 PM UTC

cortesoft wrote: post #94

jedberg wrote: post #63

Earlier quoted context omitted.

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.

> At this point I'm not sure why anyone would choose MySQL Because I have used MySQL for over 20 years and it is what I know!

Fair enough, but I assume most of that is in the administration of MySQL? Which is all now abstracted away by the cloud vendors.

If you're running it yourself I could see why you'd do that, but if you're mostly just using it now, Postgres can do all the same things in the database pretty much the same way, plus a whole lot more.

Re: PlanetScale for Postgres is now GA

#103

Post by n_u » Mon, Sep 22, 2025, 7:03 PM UTC

bri3d wrote: post #89

n_u wrote: post #65

Earlier quoted context omitted.

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 bu…

> I would highly recommend you read the docs on InnoDB locking then pick Postgres. This made me laugh pretty hard, but it's basically my take too. I'd pretty much go with the same thing. It's interesting to me, though, that people see Postgres as the "big database" and MySQL as the "hobby database." I basically see things as the exact opposite - Postgres is incredibly flexible, very nice to use, and these days, has f…

> This made me laugh pretty hard, but it's basically my take too.

Haha glad you enjoyed it.

> It's interesting to me, though, that people see Postgres as the "big database" and MySQL as the "hobby database." I basically see things as the exact opposite

I agree. As I understand Postgres started as a challenger to SQL[1][2] with support for more complicated data types but then in the mid '90s they added SQL support and it was renamed PostgreSQL.

Anecdotally I have heard from people working in industry in the 2000s-2010s that Postgres was viewed as less mature so many of the large web applications were on MySQL. This is a bit confusing to me because MySQL was released around the same time Postgres added SQL support but maybe it was because MySQL had a company behind it.

Many large scale applications of those days were using MySQL. Facebook developed RocksDB and then MyRocks[3] based on MySQL. Youtube built Vitess [4] which was sharded MySQL which was later used by Slack [5], Square, Pintrest and others.

> It's more academically correct

I'm curious about this. I know that Postgres implements MVCC in a wasteful way and uses the OS page cache in addition to its buffer pool resulting in double buffering rather than direct I/O. I feel like the more I learn about database internals the more I learn about how MySQL did things the "right" way and Postgres's approach is a bit odd. But perhaps I'm missing something.

[1] https://en.wikipedia.org/wiki/PostgreSQL#History

[2] https://db.cs.cmu.edu/papers/2024/whatgoesaround-sigmodrec20...

[3] https://engineering.fb.com/2016/08/31/core-infra/myrocks-a-s...

[4] https://vitess.io/docs/22.0/overview/history/

[5] https://slack.engineering/scaling-datastores-at-slack-with-v...

Re: PlanetScale for Postgres is now GA

#104

Post by maxenglander » Mon, Sep 22, 2025, 7:10 PM UTC

candiddevmike wrote: post #61

dfee wrote: post #29

Earlier quoted context omitted.

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 flu…

Baseless marketing claims aren't considered fluff?

People can disagree with the claims of course, but I don't think they are baseless.

On the Postgres side: https://planetscale.com/blog/benchmarking-postgres

On the Vitess side, I would point to our customers, who, on individual databases, have achieved pretty high QPS (millions), on large datasets (100s of TiBs), at a latency that is lower than what other DBaaS providers can offer: https://planetscale.com/case-studies/cash-app

Re: PlanetScale for Postgres is now GA

#105

Post by whizzter » Mon, Sep 22, 2025, 7:11 PM UTC

cyberpunk wrote: post #88

brettgriffin wrote: post #85

Earlier quoted context omitted.

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 sacrific…

This isn’t any kind of answer it’s a bunch of non-statements.. How is this any different that rds on nvme disks? With a name like planet scale i assumed it would be some multi-master setup?

sharded setup with a bit fast and loose foreign key management, so very good for performance but not a drop-in replacement if you rely on your foreign keys to be constrained/checked by the database.

Re: PlanetScale for Postgres is now GA

#106

Post by n_u » Mon, Sep 22, 2025, 7:15 PM UTC

rcrowley wrote: post #99

n_u wrote: post #73

Earlier quoted context omitted.

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…

I think we've got (1) covered elsewhere in the comment tree. For (2), semi-synchronous replication is a MySQL term which we realize in Postgres is by using synchronous replication with ANY one of the available replicas acknowledging the write. This allows us to guarantee durability in two availability zones before acknowledging writes to clients. In MySQL the _semi_ part of semi-synchronous replication refers to the…

> write only needing to be written to the binary log on the replica and not (necessarily) applied to InnoDB.

Ah. I wonder are writes in the log but not yet in InnoDB are available for reads? Then your write may succeed but a subsequent read from a replica would not see it so you lose read-after-write consistency. Perhaps that's another tradeoff.

I'll have to research a bit more but the MySQL docs [1] say "requires only an acknowledgement from the replicas, not that the events have been fully executed and committed on the replica side" which implies that it can't be read yet.

Thanks!

[1] https://dev.mysql.com/doc/refman/8.4/en/replication-semisync...

Re: PlanetScale for Postgres is now GA

#107

Post by n_u » Mon, Sep 22, 2025, 7:16 PM UTC

maxenglander wrote: post #101

n_u wrote: post #73

Earlier quoted context omitted.

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…

Hi n_u, When we say ephemeral we mean that if the host compute dies in a permanent way (which happens from time to time) the data on the NVMe drives attached to that host is not recoverable by us. AWS/GCP might have recovery mechanisms internally it, but we don't have API access to those APIs. When we say "semi-synchronous replication" we mean it in the sense of MySQL semi-synchronous replication: https://dev.mysql.c…

Thanks! I see. It's maybe a term they came up with to place it between async and fully synchronous replication.

Re: PlanetScale for Postgres is now GA

#108

Post by bri3d » Mon, Sep 22, 2025, 7:22 PM UTC

jedberg wrote: post #63

attentionstinks wrote: post #14

Earlier quoted context omitted.

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

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.

At large scale I'd say MySQL is still a competitor for a few reasons:

* Scale-out inertia: yes, cloud vendors provide similar shading and clustering features for Postgres, but they're all a lot newer.

* Thus, hiring. It's easier to find extreme-scale MySQL experts (although this erodes year by year).

* Write amplification, index bloat, and tuple/page bloat for extremely UPDATE heavy workloads. It is what it is. Postgres continues to improve, but it is fundamentally an MVCC database. If your workload is mostly UPDATEs and simple SELECTs, Postgres will eventually fall behind MySQL.

* Replication. Postgres replication has matured a ridiculous amount in the last 5-10 years, and to your point, cloud hosting has somewhat reduced the need to care about it, but it's still different from MySQL in ways that can be annoying at scale. One of the biggest issues is performing hybrid OLAP+OLTP (think, a big database of Stuff with user-facing Dashboards of Stuff). In MySQL this is basically a non-event, but in Postgres this pattern requires careful planning to avoid falling afoul of max_standby_streaming_delay for example.

* Neutral but different: documentation - Postgres has better-written user-facing documentation for user-facing functions, IMO. However, _if_ you don't like reading source code, MySQL has better internals documentation, and less magic. However, Postgres is _very_ well written and commented, so if you're comfortable reading source, it's a joy. A _lot_ of Postgres work, in my experience, is reading somewhat vague documentation followed by digging into the source code to find a whole bunch of arbitrary magic numbers. If you don't believe me , as an exercise, try to figure out what `default_statistics_target` _actually_ does.

Anyway, I still would choose a managed Postgres solution almost universally for a new product. Unless I know _exactly_ what I'm going to be doing with a database up-front, Postgres will offer better flexibility, a nicer feature-set, and a completely acceptable scale story.

Re: PlanetScale for Postgres is now GA

#109

Post by samlambert » Mon, Sep 22, 2025, 7:23 PM UTC

bri3d wrote: post #82

samlambert wrote: post #2

If anyone has questions about our Postgres product please feel free to ask. I will be around to answer.

* I saw your benchmark page at https://planetscale.com/benchmarks/aurora ; do you have something similar for Aurora Serverless? * Do you support something like Aurora Fast Cloning (whether a true CoW fast clone or detaching a replica _without_ promoting it into its own cluster / branch with its own replicas, incurring cost)? * Can PlanetScale Postgres set `max_standby_streaming_delay` to an indefinite amount? * The e…

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?

Re: PlanetScale for Postgres is now GA

#110

Post by gigatexal » Mon, Sep 22, 2025, 7:24 PM UTC

this is still using the OLTP engine though right? Can you use planetscale Postgres with any of the OLAP backends? Can I install the duckdb extension and get OLAP for free plus all the planetscale goodness?