Executando verificação de segurança...
5

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.

Diagrama mostranndo que apenas crenças verdadeiras e justificadas é conhecimento

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:

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).

Carregando publicação patrocinada...
2

Endeusar ou demonizar determinada ferramenta são ambas características de fanboys. O fato é que o MongoDB é um banco NoSQL de uso geral que pode ser usado em ambientes grandes e complexos e, ainda assim, dar excelente performance. Eu mesmo já trabalhei em 2 empresas com milhões de usuários e vários TB de dados no MongoDB e o tempo de resposta é, na maioria dos casos, excelente. PostgreSQL também aguenta muita porrada, o importante é entender as características de cada um.

PostgreSQL funciona muito bem quando você tem queries complexas, quando a estrutura no geral é fixa (e, mesmo assim, o datatype JSONB ajuda muito quando os campos variam muito), quando é necessário fazer muitos particionamentos de dados, etc.

O MongoDB é muito melhor quando você tem muitos dados em árvore (não precisa fazer joins ou executar 2 queries e juntar na aplicação), não precisa fazer malabarismos para tratar eventos de queda de um node (o próprio driver já entende e faz o retry direcionando para o novo primário), fazer sharding (distribuir os dados em vários nodes) nele é muito mais fácil, etc.

O que deve ser levado em consideração na escolha de um ou outro são as regras de negócio, não gosto pessoal.

1

Ajudou demais. Muito obrigado.

Estou lendo as respostas dos links que você compartilhou aqui e já separei algumas traduções feitas por você para ler depois.

Parabéns pelo trabalho que você realiza e muito obrigado novamente.

1

Aqui estou eu considerando mudar meu projeto pessoal para Postgres.
Ainda não entendi o pq, mas campos que são objetos numa mesma collection não estão mantendo os dados de forma consistente.

2

NoSQL deveria chamar NoConsistency porque é isso que ele não costuma ter. Isso é ótimo para certos problemas, não não é para a maioria, a í ou a pessoa fica na torcida ou rezando, ou cria algo bem complexo para garantir a consistência.

1

Ou perde um tempão refazendo certas coisas que deveriam ter sido feitas apenas uma vez; depois desiste e volta para o Postgres véi de guerra.

1

Tô aqui pensando 🤔
Seria bem legal ter um comparativo confiável entre bancos de dados considerando análise sob várias perspectivas como escrita, leitura, concorrência, escalabilidade, etc.