Você só precisa do Postgres.

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 errarem é 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.

Aí 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 problemas 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 onde 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 um experimento do 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).

Como quase todo mundo aqui, você está emocionado. Claro que não são a mesma coisa, senão eles não exisitiriam. Alguns pontos são válidos, eu sou muito contra usar NoSQL, eles nunca se provaram, mas você exagerou quando cruzou a linha dos bancos de dados, vamos por partes.

Cache: qual é o sentido de usar o seu próprio banco de dados pra cache se uma das funções do cache é diminuir a carga no banco? Um banco relacional é um recurso relativamente difícil de se escalar, o ideal é não precisar escalar horizontalmente e em muitos casos, você precisa do mesmo dado em 80% das consultas, então um Redis encaixa muito bem, já com estratégia de TTL embutido pro seu cache ser volátil

ElasticSearch: ser o mesmo algoritmo de busca, não significa ser o mesmo sistema de armazenamento, fora que muitas vezes ele é usado pra logs e você NÃO DEVE manter logs no banco em produção.

DynamoDB: ele não é chave-valor, ele é um monstro, mas que ninguém sabe usar, então, não use se quer um banco chave-valor.

Kafka: você não deve usar o seu banco em mais de um microsserviço, isso vai contra a própria arquitetura, fora que o Postgres não tem o melhor recurso do Kafka, porque ele não é um sistema de mensageria. O zero copy do Kafka é absurdo, ele quase não usa CPU e memória, trabalho em uma multinacional e o Kafka serve a toda a companhia, OLTP e OLAP, sem cair, sem precisar escalar, porque ele simplesmente joga o dado direto na interface de rede, sem copiar pra memória várias vezes

No seu site, você mencionou até o Airflow, não misture OLTP e OLAP, isso é feito também pra deixar o banco pra aplicação, não use seu banco relacional pra gerar relatórios, a menos que a empresa seja de fato pequena e se for pequena, ninguém vai inventar um Airflow.

No geral todas as ferramentas existem, porque se usar um banco relacional pra cada, será um desperdício de recurso, você não pode usar o seu banco pra tudo isso, ele não aguenta

Eu sempre considero que os extremistas estão, em princípio, errados. E isso vale para os 2 extremos.

É meio descabido um projeto com uma equipe pequena utilizar todas as opções, para todos os cenários que, talvez, venham a enfrentar no futuro.

Ao mesmo tempo querer simplificar demais vai gerar um monte de retrabalho em um período curto de tempo.

Postgres pra tudo vai forçar um monte de gambiarra ou malabarismo técnico que vai aumentar a complexidade, na minha humilde opinião.

A título de exemplo:
Em mais alto nível: as libs simplesmente não consideram o postgres pra tudo. Então muita coisa vai ter que ser feita na unha. Filas, cache... E a chance de fazer errado, ou perder tempo reinventando a roda, acaba anulando e certamente piorando o ganho de tempo em simplificar demais.

Em mais baixo nível: você usa o postgres pra cache, e com o passar do tempo, mesmo que sua base de clientes não cresça, os dados vão crescer. Até chegar um momento que o banco será maior que a memória. A partir daí você terá uma maior carga de IO, com respostas mais lentas. Se estiver usando um RDS da vida, vai estourar a cota e ter o serviço limitado no baseline, e todo o desempenho que queria ganhar vai acabar abaixo do que estaria se simplesmente nem usasse cache.

Muito bacana realmente nao sabia de tantas possibilidades do postgres, você já fez um teste de perfomance usando as plataformas e o postgres? seria interessante colocar esse dado para "comprovar" que realmente pode substituir as plataformas.

Sobre o UNLLOGGED TABLE eu achei legal.

JSONB é bom, mas dá um pouco mais de trabalho lidar com esses dados, principalmente quando precisa filtrar ou agregar dados, e se esses dados são mais complexos.
Não usei MongoDB ainda, mas pelo pouco que sei ele é mais simples nessa parte.

Elasticsearch do Postgres é legal, não fiz benchmark mas por aqui ainda não tivemos problemas.

Message Queue eu fiquei na dúvida como isso vai funcionar junto com minha aplicação. Talvez eu dê uma olhada maior nisso.

Eu sou muito fã de PostgreSQL, trabalho faz uns 20 anos de DBA, quase que todo esse tempo com o PostgreSQL, então achei legal a tua abordagem.

Em relação às extensões mencionadas, todas são muito boas, mas até agora não consegui encontrar algo que supere esta funcionalidade aqui:

https://typesense.org/docs/30.1/api/search.html#filter-results

É bem pesado juntar text search, facet, group, filter e ter uma velocidade como essa.

Rapaz, ótimo trabalho! Só não faz muito sentido.

Fala, man!

Tem uma galerinha aqui falando que tu exagerou, que tu nao deve usar cache no banco, que isso, que aquilo... Mas essa turma não parece ter conhecimento de infraestrutura, fluxo de dados e de tudo quebrando às 3h da madruga.

E pra corroborar ctg, além do link que tu colocou no final do post, o pessoal do Supabase se aproveitou da versatilidade do PostgreSQL pra criar um "firebase pra chamar de seu", como dizia o slogan deles no início do projeto. Eles criaram uma plataforma ao redor do postges apenas para juntar as peças. Hoje eles são enormes, um PaaS super consolidado e ainda baseados no dinamismo do postgres.

E outra, banco relacional escala horizontal sim! Inclusive o postgres fez o mundo relacional acordar pra vida no assunto escalabilidade e sincronização de dados.

Teu post foi muito bem escrito e com muita propriedade tu falou que nem sempre precisamos de uma ferramenta específica pra cada ocasião. Temos que saber escolher entre inchar mais a stack ou usar algum recurso do pg.

Parabéns, man!

Discordo assim como muitos. E diferentemente de alguns, sou contra o relacional e a favor do NoSQL. Não é necessário Postgres. :D