MySQL partitioning shines with one specific use-case: time-based data retention. e.g., by using RANGE partitioning over a temporal value, you can very efficiently drop large amounts of old data when no longer needed, and can automate this fairly easily.

For anything else, MySQL partitioning rule-of-thumb is you'll have a bad time, mainly for performance reasons.

Postgres's support for table partitioning got a massive boost in the last major release (11.x): https://www.postgresql.org/docs/current/ddl-partitioning.htm...

We use PostgreSQL date RANGE partitions in our datamart DB for exactly this – functionally instant deletion of old data, without leaving dead tuples in the main table.

No. I was referring to table partitioning.

I don't have much experience with replication in either MySQL or PG (but understand this is another area where mysql may edge pg out still).