The style of tradeoff taken, in both cases, really exemplifies the difference in engineering priorities for MySQL and PostgreSQL. MySQL optimizes for reads, at the expense of a higher write load. PostgreSQL optimizes more for writes, at the expense of in-line bloat and reads.
When you go to scale out a RDBMS, traditionally you do it with single-master multi slave replication, to scale reads. Today, that's not an inordinately hard task. Scaling writes is a LOT harder, and I think PostgreSQL made the better choice, in the end.
Comments
The style of tradeoff taken, in both cases, really exemplifies the difference in engineering priorities for MySQL and PostgreSQL. MySQL optimizes for reads, at the expense of a higher write load. PostgreSQL optimizes more for writes, at the expense of in-line bloat and reads.
When you go to scale out a RDBMS, traditionally you do it with single-master multi slave replication, to scale reads. Today, that's not an inordinately hard task. Scaling writes is a LOT harder, and I think PostgreSQL made the better choice, in the end.
Plus, PostgreSQL built in master-slave streaming replication in release 9, so scaling out reads is even less of an issue.