Reduzi um DB de 52gb para 4.5gb! PostgreSQL -> Clickhouse

Fiquei curioso sobre os detalhes da quest de tentar "fazer acontecer no PostgreSQL", recentemente no meu trampo atual saimos de Mongo para TimescaleDB com ~4TB de dados, e com queries "OLAP like" com tempo de resposta na casa dos 10/50ms (não vou mentir mas temos spikes de 200/500ms kkk), nessa quest além do que você já comentou fomos fundo nas configurações do postgres, que são bem conservadoras por default, work_mem, checkpoint_timeout, max_wal_size, fora o que ainda não descobrimos e a lista vai longe... Dependendo do padrão de write/read do seu workload, tunar essas configs faz uma diferença enorme.

Boa sorte na proxima quest com o banco de 7tb, não deixe de postar aqui o resultado xD. E Não conhecia o ClickHouse, sua experiência me chamou a atenção vou dar uma estudada!

ps: Tbm não sou expert mas minha calvice já acentuou uns 2cm trabalhando com PostgreSQL ao longo desses anos.

Cara, é isso. Tem sempre que achar outras soluções em DB. Peço até perdão aos que gostam, mas eu particularmente não sou fã do Postgres. 🥲

Dúvida: Estão fazendo análise de dados nos dados histórico? Geralmente dado histórico, é armazenado para auditoria, mas se estão fazendo queries frequentes, talvez se enquadre como análise de dados e deveriam democratizar e etc. Desculpe se entendi errado.
Digo isso pois as vezes estamos combatendo o problema errado, e acho que essa plataforma que está usando é preparada pra lidar com alto volume de dados por ser uma plataforma de observabilidade.
Infelizmente não atuo com análise de dados, senão eu te orientava pra você descobrir e quem sabe estruturar melhor essa area na empresa.

Muito boa a analise, parabéns!

Aqui na empresa utilizamos postgres para salvar todas as partidas recentes dos players que estão na nossa plataforma, a tabela que salva essas partidas já está com mais de 500gb e conforme a plataform atraí mais usuários mais rápido ela vem crescendo.
Começamos a escrever uma PoC para utilizar um TimescaleDB, mas por falta de tempo ainda não chegamos muito a fundo nos testes.

Uma dúvida, você chegou a olhar o custo de utilizar o ClickHouse?

Estranho esse comportamento no postgresql, chegou a rodar alguma query para ver o tamanho físico de dados ocupados por tabelas e por índices?

Eu falo isso pois algumas vezes criamos diversos índices sem uma análise correta, e ao fazer uma consulta o banco acaba nem usando o índice.

Por exemplo: se eu criar um índice em cima da data de criação e um índices em cima de categoria, e fizer uma consulta onde eu busco um range de data de criação e filtro por uma categoria específica, o postgresql usaria apenas um índice nessa busca.

Dados agregados é pior ainda, existem soluções O(log n) envolvendo segtree em banco de dados que podem reduzir mais ainda o tempo de consulta.

Eu digo isso pois o postgresql é uma ferramenta muito customizavel (já vi gente fazendo cache usando postgresql mais performatico que o redis kkk) só que é necessário muito conhecimento e prática para conseguir ajustar ele pro teu caso. O modo default do postgresql que se usa tudo padrao SQL é no modo "pau pra toda obra", mas para casos mais específicos é necessário estudos mais aprofundados.

Os ganhos que você mostrou são muito bons, realmente um case bem bacana. A migração para um banco colunar faz todo sentido nesse cenário, mas acho que a análise da causa do problema poderia ir um pouco além.

O ponto não era só volume ou concorrência no PostgreSQL, mas sim estar usando um banco OLTP para um workload totalmente OLAP. As consultas de agregação em massa sempre vão sofrer em uma arquitetura orientada a linhas.

É verdade que o PostgreSQL é super configurável, e soluções como o TimescaleDB mostram isso com hypertables, compressão e agregações incrementais para séries temporais. Mas no fim das contas, ele continua sendo orientado a linhas, e em workloads puramente analíticos vai sempre carregar mais dados do que o necessário.

Mais do que “trocar de DB”, o grande aprendizado é entender qual categoria de banco resolve melhor cada problema, relacional, não relacional, colunar, chave-valor, grafo etc. Esse alinhamento é o que realmente traz eficiência.

A redução de armazenamento também não é mágica: bancos colunares conseguem comprimir muito melhor porque armazenam valores contíguos por coluna, o que permite técnicas como run-length encoding, dicionários e compressão delta. Já em um OLTP, tentar simular isso com índices só infla o disco e acaba virando um “colunar improvisado”.