The conversation

Lessons learnedExperience excerpt · English

At large scale I'd say MySQL is still a competitor for a few reasons: * Scale-out inertia: yes, …

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

Original discussionPlanetScale for Postgres is now GA190 source comments · at import
2

What was this responding to?

Parent context · original excerpt

JE

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.

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 2

Direct replies available in this import. Original-language excerpts.

JA

> hybrid OLAP+OLTP .... in Postgres this pattern requires careful planning to avoid falling afoul of max_standby_streaming_delay for example This is a really gnarly problem at scale I've rarely seen anyone else bring up. Either you use max_standby_streaming_delay and queries that conflict with replication cause replication to lag or you use hot_standby_feedback and long running queries on the OLAP replica cause problems on the primary. Logical Decoding on a replica in also needs hot standby feedback which is a giant PITA for your ETL replica.

Full original
JE

I appreciate your detailed reply, and I agree with all your points. I am however highly amused that everyone in this thread defending MySQL ends with some form of "I'd still choose Postgres though!". :)

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.