My heuristic is that MySQL is faster for inserts and single-table reads by primary key, but PostgreSQL is faster for more complex queries, particularly if they involve joins or subqueries.
Basically, MySQL is a key-value store in an RDBMS's clothing.
On the flip side, PostgreSQL's high availability options aren't in the box, or are at the very least varied, problematic and/or cost more than other options for support contracts.
Every time I've worked with mySQL I've seen some irksome behavior... just the same, setting up failover options is miles ahead of PostgreSQL. And when you already have in-house talent, it becomes even more obvious.
My only thought was that using a clustered database (such as Cassandra) as the store with the data itself might have been better. domain/url (minus querystring) would hash/distribute fairly well, and with even a relatively small cluster with 2 replica nodes for the shard would be pretty effective. Also, it would be easier to manage a replicated database, in my mind, than tracking sites to pairs of static servers. GoDaddy is/was moving to something similar with new development on one of their applications when I worked there, and able to serve a huge number of static requests (hundreds of thousands per second) off of a relative few servers with a sub 10ms response time, for content not backed by cdn.
In the end it just goes to show that serving static content on modern hardware can scale really well, with a number of options for technology. Which is why I'm somewhat surprised that something hasn't taken over the tide of poorly configured Wordpress blogs.
Basically, MySQL is a key-value store in an RDBMS's clothing.