Interesting post! While I suspect that a MySQL installation is just as likely to have its own problems in the long run, I'm not smart enough to provide any kind of compelling point-by-point refutation. However, a number of the points made strike me as having possible trade-offs that were not really addressed in-depth.
My summary of the arguments against Postgres and some basic thoughts on each:
1. Writes are more expensive because all secondary indexes must be updated with a new physical location.
This may be true, but the MySQL model of using primary keys from secondary indexes will mean that reads are inherently expensive. They even mention this:
> This design means that InnoDB is at a slight disadvantage to Postgres when doing a secondary key lookup, since two indexes must be searched with InnoDB compared to just one for Postgres.
So it seems like a classic read vs. write trade-off.
I'm also a little skeptical of any performance claims that don't include any numbers. It's possible that efficient coding in Postgres makes this much more of a wash in terms of performance than claimed here.
2. Replication is less efficient because it's sending a lot of physical information out along the stream.
This is quite true, but IMO unlikely to be a major issues for most users unless they're dealing with a huge amount of data and streaming it over a slow connection (i.e. across the continent like Uber's disaster recovery center).
3. Data corruption from a bug found in 9.2.
Certainly a bad situation, but IMO not really a valid claim for situation. 9.2 is way behind at this point, and there's not much to say that they wouldn't have encountered a similar bug or something worse in MySQL in all that time, especially operating at scale.
To give a counter-anecdote, I operated Postgres at scale for a long time across many versions starting at 9.1 and was lucky enough to have never once encountered a bug with data corruption.
4. Postgres' MVCC model makes it easy for replicas to accidentally fall behind their master.
This one is valid (and annoying), but there are very good reasons for it, and you have some switches to control the behavior based on value transactions finishing on followers or prompt replication more highly.
5. Upgrades are difficult because the WAL stream works at a physical level and is not compatible between database versions.
Again, this is valid, but the statement-based replication is a scary idea. Row-level replication is more interesting and probably something that Postgres should have though.
Some good news is that Postgres is getting closer to logical WAL streaming, which should make in-place upgrades possible.
My summary of the arguments against Postgres and some basic thoughts on each:
1. Writes are more expensive because all secondary indexes must be updated with a new physical location.
This may be true, but the MySQL model of using primary keys from secondary indexes will mean that reads are inherently expensive. They even mention this:
> This design means that InnoDB is at a slight disadvantage to Postgres when doing a secondary key lookup, since two indexes must be searched with InnoDB compared to just one for Postgres.
So it seems like a classic read vs. write trade-off.
I'm also a little skeptical of any performance claims that don't include any numbers. It's possible that efficient coding in Postgres makes this much more of a wash in terms of performance than claimed here.
2. Replication is less efficient because it's sending a lot of physical information out along the stream.
This is quite true, but IMO unlikely to be a major issues for most users unless they're dealing with a huge amount of data and streaming it over a slow connection (i.e. across the continent like Uber's disaster recovery center).
3. Data corruption from a bug found in 9.2.
Certainly a bad situation, but IMO not really a valid claim for situation. 9.2 is way behind at this point, and there's not much to say that they wouldn't have encountered a similar bug or something worse in MySQL in all that time, especially operating at scale.
To give a counter-anecdote, I operated Postgres at scale for a long time across many versions starting at 9.1 and was lucky enough to have never once encountered a bug with data corruption.
4. Postgres' MVCC model makes it easy for replicas to accidentally fall behind their master.
This one is valid (and annoying), but there are very good reasons for it, and you have some switches to control the behavior based on value transactions finishing on followers or prompt replication more highly.
5. Upgrades are difficult because the WAL stream works at a physical level and is not compatible between database versions.
Again, this is valid, but the statement-based replication is a scary idea. Row-level replication is more interesting and probably something that Postgres should have though.
Some good news is that Postgres is getting closer to logical WAL streaming, which should make in-place upgrades possible.