Postgres sync replication was immature and basically unused until a couple years ago. Async log shipping has been the go-to, or using something slow and fraught with complexity like slony. MySQL sync replication just works, and has worked for many years.
Articles like this about Postgres are pretty common. There is no one “silver bullet” Postgres config that will handle any workload predictably, you need to tune it based on what you’re doing. As this post mentions, VACUUM comes up a lot. MySQL’s storage engine is pretty simple in comparison, so even though it can’t do as many useful things as Postgres’, it usually Just Works™️. Hyperscalers don’t want to tune per application, they want to deploy a zillion homogeneous database instances and have them all work for a variety of applications without babysitting. Having a Postgres expert per product team doesn’t scale.
Often this means they don’t use MySQL or Postgres at all. But when they do, they almost always use MySQL.
I believe this—along with synchronous replication—is the main reason hyperscalers continue to use MySQL over Postgres.
Since postgres can do both async and sync replication, can you elaborate on what you mean?
Postgres sync replication was immature and basically unused until a couple years ago. Async log shipping has been the go-to, or using something slow and fraught with complexity like slony. MySQL sync replication just works, and has worked for many years.
See this Uber post about switching off Postgres for examples of problems with early versions of Postgres streaming replication.
Tell me more about this. Tbh I’ve only used redshift for a clustered rdbms.
Articles like this about Postgres are pretty common. There is no one “silver bullet” Postgres config that will handle any workload predictably, you need to tune it based on what you’re doing. As this post mentions,
VACUUMcomes up a lot. MySQL’s storage engine is pretty simple in comparison, so even though it can’t do as many useful things as Postgres’, it usually Just Works™️. Hyperscalers don’t want to tune per application, they want to deploy a zillion homogeneous database instances and have them all work for a variety of applications without babysitting. Having a Postgres expert per product team doesn’t scale.Often this means they don’t use MySQL or Postgres at all. But when they do, they almost always use MySQL.