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