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.

▲

bri3d 4 days ago | parent | next [-]

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.

	▲	jashmatthews 3 days ago \| parent \| next [-]
		> 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.
	▲	jedberg 3 days ago \| parent \| prev [-]
		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!". :)

▲

cortesoft 4 days ago | parent | prev [-]

> 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!

▲

jedberg 4 days ago | parent [-]

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.

	▲	cortesoft 4 days ago \| parent [-]
		Its both operating MySQL and creating applications that use it. Additionally, almost all my workloads run in our own datacenters, so I haven't yet been able to offload the administration bits to the cloud.