Eu não sei responder exatamente, mas posso especular um pouco com o conhecimento que tenho.

Minha maior aposta é que escolheram para obter melhor eficiência e obter os melhores resultados. Ou seja, porque o PostgreSQL, ao contrário da crença popular, pode entregar melhor desempenho.

De maneira alguma parece ser qualquer outro motivo, o problema é simples demais para escolher tentar outro motivo.

Fico pensando até se não seria o caso tentar outros bancos de dados com melhor performance. Mas provavelmente não mudaria muito porque, também ao contrário da crença popular, foi demonstrado lá que o gargalo não era o banco de dados.

Mas a parte mais interessante é porque não escolheram o MongoDB. E é simples, novamente ao contrário da crença popular, ele não é um banco de dados rápido. Ele pode ser rápido em cenários bem específicos, mas em geral ele será mais ou menos igual ou pior que um banco de dados relacional ou de outro modelo. Nem tanto pelo modelo, mas ele também, mas não no caso de um problema tão simples.

MongoDB é bom e útil em diversos cenários, mas o grosso do uso dele hoje em dia ocorre apenas onde tanto faz a ferramenta que está usando ou onde o relacional funciona melhor, até mesmo se tiver que desnormalizar todo o DB.

As pessoas tomam muitas decisões baseadas em crenças em vez de fazer em cima do conhecimento. Elas decidem baseando-se em coisas que viram na internet através de pessoas aleatórias que geralmente não possuem conhecimento para dizer o que falam ou tem algum interesse em mentir.

Pessoas com maior conhecimento tendem a escolher a melhor ferramenta, o que não costuma ser MongoDB. Mesmo que isso desagrade fanboys. Ao mesmo tempo acho que foram no que estavam acostumados, porque o MongoDB provavelmente daria um resultado muito parecido em um cenário tão simples. Ganharia em um lado e perderia em outro.

Até eu me surpreendi com alguns resultados ali. Mas de forma geral o que o Akita fez comprova o que eu sempre falo e muita gente acha errado porque aprenderam errado. Se você quiser mesmo ter certeza qual vai dar o melhor resultado tem que testar com todos os possíveis e fazer isso sabendo, ou junto com quem sabe bem usar cada um deles, porque o "japonês" motrou o óbvio, que esse domínio é essencial para obter bons resultados.

Competência > Ferramenta.

Eu não vou entrar em detalhes aqui porque já falei muito sobre o porquê não existe milagre para o MongoDB ser mais rápido, e mesmo que tivesse, se é tão importante os concorrentes mudariam seus produtos para obter essa mágica toda, não o fazem porque esse ganho não é verdadeiro.

As pessoas que adotam o MongoDB onde não deve só não quebram a cara porque seus problemas são tão triviais que qualquer solução funciona. Fica aqui os links (que a maioria não vai clicar) e ver sobre isso:

• https://pt.stackoverflow.com/q/576712/101
• https://pt.stackoverflow.com/q/122452/101
• https://pt.stackoverflow.com/q/274320/101

Faz sentido para você?

Espero ter ajudado.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

O MySQL perdeu uma guerra silenciosa para o Postgres no terreno da organização. Enquanto o InnoDB ainda na versão 8 do MySQL tem um problema sério com a expurgação de dados, o Postgres se torna cada vez mais eficiente no Vacuum.

Quando o InnoDB cresce o binário do ibdata dele nunca mais retrocede, eu passei a migrar o MySQL sistematicamente para o Postgres depois disso - bancos muito grandes na hora de você expurgar dados de usuários é um malabarismo. Existe uma ferramenta da Percona chamdaa Xtrabackup, que envolve dropar a tabela e fazer reload do tablespace, mas é um risco muito grande de fazer isso em ambiente de missão crítica.

Eu li o desafio e entendi que era regra usar o postgres, acredito que a galera pode ter entendido isso também. Se eu tivesse participado e pudesse usar outros bancos eu teria usado MongoDB ou algo ainda mais simples se possível.

A minha opnião simplista e muito humilde(eu não acompanhei a rinha rsrs) é que talvez todos apenas tenham ido no efeito manada.

Ora, meu primeiro BD foi o MySQL no Xampp(bons tempos, mas nem tanto..) e simplesmente por isso eu gosto do Postgress. Eu deveria muito gostar do MariaDB, e até tenho ele instalado, mas eu uso? kkkk

Acho que todo mundo tá aprendendo igual, e todo mundo tá usando igual. Se funciona pra 1, funciona pra 2, 4, 8... Não acho que exista uma explicação tecnica secreta, não é tudo SQL? AAAh mas tem o Mongo.. olha eu gostava bastante dele, usava com o Django, era maravilhoso até eu perceber que é só isso, o Mongo é o Mongo, o firebase tá lá, até um Cassandra roda também, e nem vamos esquecer o muito louco SQLite.

Mas pelo mesmo motivo que você pensou automaticamente que o Mongo é o principal antagonista do Postgress, as pessoas pessam que o Postgress é o heroi do SQL. É habito, é cultura, é da natureza humana kkkk Mas caso eu me sinta confortavel em participar, no proximo rinha de backend vou usar um banco em grafos só pra ser diferentão :D que acha? kkkk

Não acompanhei a rinha, mas imagino que, nesse caso específico, a capacidade de replicação do MongoDB mais atrapalhasse do que ajudasse, já que o foco era reduzir ao máximo o tempo de resposta.

Por padrão, o MongoDB precisa gravar na maioria dos nodes do cluster para poder fazer commit (writeConcern=majority). Isso quer dizer que o banco tem que esperar o dado ser gravado no node primário, enviar para as réplicas e receber uma resposta da metade delas para, só então, confirmar a gravação. Como o Postgres por padrão não tem essa característica, então o tempo de resposta diminui.

No mundo real, geralmente as coisas são diferentes: a segurança dos dados é mais importante que uma pequena perda de performance, mas o caso da rinha é diferente.

A resposta é simples!

Mongo é muito rápido para mostrar dados.
Por isso é ótimo para volumes gigantes de dados!

Mas é lento para armazenar! Ou seja para rinha, o armazenamento muito rápido era obrigatório. E mongo é mais lento na escrita.

Vi gente usando mongo, mas a escrita mais lenta atrapalhou os resultados!

Lembrando que numa aplicação normal isso não faz quase diferença.
Dificilmente tem no Brasil empresas que lidem com isso no dia a dia(tirando as grandes é claro)