Both DBs solve the same problem:

How to most effectively store and provide access to data, in an ACID-compliant way?

ACID compliance might be implemented in various ways and SQL databases can vary quite substantially how they choose to go about it. MySQL in particular, with the default InnoDB engine, takes a completely different approach to Postgres.

Both implementations have their own tradeoffs, set of advantages and disadvantages.

In theory, the MySQL (InnoDB) approach should have an edge for:

• partial updates of tables with more indexes - not all indexes but only of changed columns have to be modified
• querying tables by the Primary Key - index is the table so it should be as fast as it gets, since data is read from a single place
• previous row versions are stored in a separate space on the disk, therefore active transactions are less affected by the potentially large older row versions

Postgres advantages are:

• uniform search performance for all indexes - there is no primary/secondary index distinction, performance is the same for all of them
• smaller penalty for random inserts because tables are stored on a heap, in random order, in contrast with sorted MySQL Clustered Index (table)
• previously started transactions have better access to prior row versions, since they are stored in the same disk space
• there is less need for locking (virtually none) to support more demanding isolation levels and concurrent access - previous row versions are stored in the same disk space and can be considered or discarded based on special columns (xmin, xmax mostly)

In theory, theory and practice are the same. But, let's see how it is in practice!