Primeiro quero dizer que você tem razão quanto a essa coisa da ferramenta certa. Para a maioria dos problemas tem uma margem de segurança tão grande, que praticamente qualquer ferramenta minimamente razoável atende o problema. Isso não costuma ser dito pelas pessoas, até mesmo experientes, induzindo outras a erro quando essas outras acham que basta ouvir alguém falar que a "boa prática" é tal, então ela faz sem pensar.
Outra questão comum das pessoas erraras é que a ferramenta certa tem que levar uma série de fatores que não são tão técnicos, e um dos mais importantes é que a ferramenta certa é aquela que você domina. Não quer dizer que sempre acontecerá assim, mas em muitos casos sim. Quero deixar bem claro que usar o que se domina não é uma solução universal, em muitos casos precisa usar uma ferramenta melhor e tem que aprender muito bem ou pagar para outra pessoa fazer, sob pena de fazer algo ruim.
Api entra uma outra questão que eu respondi esses dias: https://www.tabnews.com.br/maniero/de7104b0-37bc-4bd3-b227-b0e815e14c15. As pessoas estão radicalizando em quase tudo. Não é sempre para adotar a melhor ferramenta para a tarefa nem a ferramenta que você mais domina.
Também acho que em muitos casos não precisa tantos bancos de dados. E eu já defendi até o SQLite como solução adequada para muito mais probloemas do que as pessoas imaginam, e hoje já estão criando ferramentas que torna isso fácil de realizar.
E acho que o PostgreSQL seja muito bom a atende vários cenários, especialmente em casos que alguém pensaria em algum NoSQL. Isso vale para SQL Server, Oracle e em menor grau até MySQL ou SQLite.
Discordo um pouco que os fornecedores falem muito sobra usar a ferramenta certa, eles falam para usar a ferramenta deles, por isso um monte de gente usa MongoDb ou um banco de dados relacional seria muito melhor. E como dito antes, também não fará muita diferença, é a ferramenta errada, mas funciona.
Não posso afirmar e se ninguém conseguir apresentar algo mais concreto eu não posso considerar como verdade que todos esses 6 DBs podem ser substituídos sempre pelo PostgreSQL. Na verdade, eu tenho a impressão, pela minha experiência, que boa parte deles se puder usar o PostgreSQL no lugar é porque sequer precisava dele.
O que eu conheço dos internals do PostgreSQL, não consigo ver ele tão eficiente quanto o Redis, inclusive o PostgreSQL tem algumas dificuldades com cache, que obviamente a maioria nunca vai perceber porque não é crítico, mas pode impe4dir de substituir um Redis, e se consegue é porque o Redis não era necessário.
O mesmo pode ser dito para o ElasticSearch, tenho sérias dúvidas que o FTS do PostgreSQL seja tão bom assim.
Também não consigo ver o Pg substituindo o Kafka onde realmente o Kafka é necessário (ele não é muitos casos que é usado). Sequer podemos colocar Kafka e RabbitMQ na mesma caixa. Esse é um erro comum, então colocar o Pg na mesma caixa pode ser meio complicado também.
Os demais pode ser até que funcione razoavelmente bem, mas pode ter algumas dificuldades, pode ter mais trabalho e não encaixar tão bem para a tarefa, ainda que consiga dar conta. Você pode pagar em preço para a substituição. Isso não vale tanto para o MongoDB que realmente eu acho que um relacional pode dar conta bem e o Pg tem recursos que facilitam um pouco o modelo de documento. Mas ao mesmo tempo eu sei que tem alguns poucos casos que um DB especializado nesse modelo se torna fundamental e o Pg não dá conta.
Também concordo com o que está implícito na postagem que a maioria das pessoas acredita que precisam de mais escala do que realmente precisam ou vão precisar um dia. Embora em alguns casos ele precise uma ferramenta melhor porque ele fez algo tão errado que precisa de uma solução mais robusta para atender a demanda. Já vi pessoas deixarem pior do que precisa em algumas ordens de magnitude.
Pelo menos no site criado (parabéns pelo trabalho) deixa a porta aberta para ter exceções. Embora eu gostaria que realmente fosse só Google, Spotify, Netflix, Instagram, Wikipedia que precisem de soluções mais complexas, tem vários problemas bem menos que pode ser até que o Pg atenda, mas de forma ruim. EM alguns casos pode ser inviável.
Uma dica que muitos não sabem: o Stack Overflow, que já foi um dos 30 sites mais acessados do mundo consegue rodar com um único SQL Server (embora perderia algumas características) e até mesmo um único servidor web. Agora estão adotando nuvem e o desempenho está piorando muito, então não só o SEO piorou, os custos aumentaram, mas também aguentar o tráfego grande pode não ser possível com tão pouco hardware. Como informação colateral, o SO praticamente acabou para criação de novo conteúdo, mas ainda tem muito acesso do Q&A já existente lá que é de excelente qualidade e não consegue ser bem substituído pela IA.
Eu não tenho tempo, mas sempre me deu vontade de fazer e um experimento fazendo o SO funcionar com mesma carga usando SQLite. Daria um pouco mais de trabalho porque é claro que o SQLite não é a ferramenta ideal para isso, mas se ela der conta já é algo incrível.
Seria interessante testes massivos usando o Pg e pessoas especializadas nas outras ferramentas fazer um contra teste para mostrar falhas no teste do Pg. Só assim poderemos ter informações confiável até onde a substituição é válida e/ou compensa.
O Pg é excelente mas ele tem seus pontos negativos que muitas vezes só serão percebidos por quem o usa bastante em cenários mais pesados.
S2
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).