Embora esta pergunta pareça contrária ao princípio "Evite fazer perguntas subjetivas ou argumentativas" do site, não resisto a tentar uma resposta.
Depende.
Estão falando de uma única configuração de servidor que pode ser dimensionada para conjuntos de dados muito grandes?
Ambos podem funcionar nessa situação, dependendo do conjunto de dados, mas provavelmente não terão um desempenho muito bom sem a configuração personalizada e o planejamento adequado. Na minha experiência ao trabalhar em grandes conjuntos de dados com muitas gravações, descobri que o Postgres tem menos condições que causam bloqueio e o desempenho geral foi melhor.
Você está falando de configurações de vários servidores que escalam para muitos escravos para muitos leitores?
Historicamente, o MySQL é considerado o líder nesse espaço desde que veio com a replicação assíncrona incorporada. Esse não é mais o caso se você não se opuser ao uso do mais novo software de banco de dados; O Postgres agora também tem isso incorporado com o lançamento do 9.0. Minhas experiências com a replicação do MySQL foram mais do que adequadas a este ponto.
Você está falando de configurações de vários servidores que variam de muitos mestres para muitos escritores?
Essa é de longe a maneira mais difícil de dimensionar qualquer produto e muitas vezes pode ser evitada com o uso de servidores de failover. Se você realmente precisar expandir para alta disponibilidade de servidores master, os complementos / instalações alternativas não poderão ser evitados. Para o MySQL, existe o MySQL Cluster NDB, que possui uma opção de código aberto ou uma versão comercial . Para o Postgres, existem muitos complementos que permitem obter níveis variados de HA e pooling
A longo prazo, o dimensionamento do seu banco de dados normalmente se resume ao planejamento do design. Se o seu aplicativo for projetado com escala em mente, o sistema db que melhor corresponda aos seus desenvolvedores geralmente é a melhor opção.