1

Boa! Dois trade-offs que resolvi diferente:

Tabela larga vs JOIN: fiquei nos JOINs em query — a ficha completa (7 LEFT JOINs) sai em ~8ms num Postgres de 1 vCPU, porque é tudo lookup por PK/índice. Denormalizar ganha em consulta analítica (scan), mas pra lookup pontual o join é ruído — e você paga o dobro de storage + rebuild na recarga mensal.

Redis pras auxiliares: testa antes — são ~7k linhas, o Postgres já mantém tudo em shared_buffers (memória local). Redis adiciona um hop de rede pra ganhar quase nada. Se quiser otimizar mesmo, carrega num map em memória do próprio processo no boot: zero rede, zero join.

Quanto tá teu p50 na tabela larga? Se os números baterem, um comparativo das duas arquiteturas dava um post.

Carregando publicação patrocinada...
2

Estava dando uns 80 ou 90GB se eu não me engano.
O meu objetivo em fazer desta forma sempre foi em dar uma resposta mais rápido do que economizar espaço de disco.
Quanto menos join, mais rápido será e alguns valores que são de tabelas auxiliares podem ficar na memória, assim retorna mais rápido.

1

Faz sentido — 80–90GB vs meus ~50GB bate com o ~2x que eu estimava.
Só um adendo na intuição "menos join = mais rápido": ela é verdadeira em geral, mas em lookup por PK o join custa microssegundos — o gargalo vira rede/parse muito antes. Vale rodar um EXPLAIN ANALYZE nas duas formas com a mesma consulta: se a diferença for <1ms, a tabela larga tá te custando 40GB pra empatar. Se der mais que isso, aí teu desenho ganha e eu que aprendo.

1

Amigo, será que tem como você fazer as duas formas e fazer uma análise e postar aqui no Tabnews?
Já tem algum tempo que não estou fazendo o processo de importação dos cnpj, estou focando em oturas coisas no momento, mas gostaria muito de ver se esta teoria faz sentido ou não.
Seria bom ter um post no Tabnews sobre isto.