A pergunta que aparece em comitê de dados em 2026: "ainda vale fazer modelagem dimensional? lakehouse não resolve tudo?". A resposta honesta — sim, ainda vale — vai contra um pouco da moda. Mas a moda está errada, ou pelo menos vendendo lakehouse pra problema que não é de lakehouse. Modelagem dimensional (Kimball, star schema, fato + dimensão) continua sendo a melhor forma de organizar dado pra consumo analítico — e a confusão entre "armazenar dado de qualquer jeito" e "modelar pra uso" custa caro pra empresas que ainda não viveram o ciclo completo.
Esse texto é a defesa da modelagem dimensional em 2026. Não é nostalgia — é argumento prático sobre onde a abordagem ainda ganha e por que abandoná-la tem volta forte de retrabalho. Quando lakehouse é de fato a arquitetura certa — e quando não é — tem critérios separados.
O que mudou e o que não mudou
Em 2018, modelagem dimensional era padrão indiscutível. Em 2022, lakehouse (Databricks Delta, Snowflake Iceberg, Apache Iceberg em qualquer storage) virou alternativa séria. Em 2026, parte do mercado declarou "modelagem morreu" — e essa declaração é errada por confundir dois problemas separados.
O que mudou: storage e formato. Lakehouse permite armazenar dado bruto, semi-estruturado, em parquet aberto. Custo de storage caiu. Schema-on-read substitui schema-on-write pra muitos casos. ETL pesada pra organizar storage virou desnecessária.
O que NÃO mudou: necessidade de modelagem semântica. Mesmo no lakehouse, em algum momento alguém precisa decidir: o que é "cliente ativo"? Como conta receita? Como dimensão "produto" se relaciona com fato "venda"? Essa decisão é semântica — não some por mudar formato de armazenamento.
Quem confunde os dois acha que lakehouse substitui modelagem. Não substitui. Apenas adia. E adiar modelagem semântica é a forma mais cara de descobrir em 18 meses que precisava dela.
Lakehouse resolveu storage. Não resolveu modelagem semântica — e nenhuma tecnologia vai resolver, porque modelagem é decisão de negócio. Empresa que confunde os dois compra lakehouse e descobre o gap em produção.
Onde modelagem dimensional ganha em 2026
Quatro situações específicas onde dimensional (mesmo em cima de lakehouse) continua sendo a abordagem certa.
1. BI executivo com métricas reutilizadas em N dashboards. Quando 20 dashboards diferentes calculam "receita do trimestre", essa lógica precisa morar em um modelo único — fato vendas × dim tempo × dim produto, com agregados pré-calculados. Sem isso, cada dashboard tem sua versão da métrica, e diretoria perde confiança. Dimensional resolve.
2. Performance previsível em query analítica. Lakehouse cru com schema-on-read funciona bem em exploração ad-hoc. Em query analítica recorrente (dashboard, relatório, dashboard executivo), dimensional pré-agregado é 5–50× mais rápido. Performance previsível importa quando 100 usuários acessam o mesmo dashboard ao meio-dia.
3. Histórico de mudança de dimensão (SCD). "Cliente Joao mudou de segmento Premium pra Enterprise em março". Precisa relatório de venda do Q1 considerando segmento da época — não o atual. SCD Type 2 em dimensional resolve isso elegantemente. Lakehouse cru sem modelagem força código custom em cada query. Em 18 meses de operação, isso vira pesadelo.
4. Governança semântica institucionalizada. Modelo dimensional força documentação (dbt mart é a expressão moderna). Quem mantém o modelo dimensional mantém o glossário semântico da empresa. Lakehouse cru sem modelagem semântica é convite a "cada um com sua interpretação" — e data catalog não resolve, só amplifica o que existe.
Esses quatro são bem cobertos por modelagem dimensional. Lakehouse cobre 60–70% deles parcialmente, mas com custo de governança que vira passivo.
A armadilha do "lakehouse-pra-tudo"
A tese vendida por alguns players: "armazena tudo bruto, modelagem é overhead, analistas modelam quando precisarem". Soa moderno. Em prática, três problemas aparecem em 12–18 meses.
Problema 1: cada analista vira arquiteto. Sem modelagem central, cada um decide como juntar fato e dimensão. Resultado: 10 versões diferentes da mesma análise, divergência crônica. Equivalente ao que self-service BI mal governado produz, em camada mais profunda.
Problema 2: performance degrada silenciosamente. Query que rodava em segundo no warehouse dimensional vira 30 segundos no lakehouse cru. Time tenta otimizar com cache, materialized view, partição — e reinventa modelagem dimensional caso a caso, sem o nome bonito.
Problema 3: histórico vira espaguete. Sem SCD bem desenhado, "cliente em março" e "cliente hoje" se confundem. Análise histórica fica incorreta. Time descobre em auditoria, no pior momento.
Esses três combinados produzem o mesmo efeito: empresa que pulou modelagem dimensional pra "ir mais rápido" gasta o ano seguinte reconstruindo modelagem dimensional dentro do lakehouse, com nomes diferentes mas mesma estrutura. O atalho não foi atalho.
A abordagem que funciona em 2026
Não é "lakehouse vs dimensional". É lakehouse como storage, dimensional como semântica. Layered:
- Bronze (lakehouse cru). Dado ingerido sem modelagem, em formato aberto. Storage barato, schema flexível, fonte da verdade pra reprocessamento.
- Silver (lakehouse modelado, ainda flexível). Limpeza, deduplicação, conformação básica. Ainda flexível, mas com schema definido.
- Gold (dimensional, dbt mart, semantic layer). Fato + dimensão, métricas pré-calculadas, governança forte. Onde dashboards e BI executivo consomem.
Esse padrão (medallion architecture popularizado pelo Databricks) é hoje o consenso entre quem operou ambos os mundos. Lakehouse não substitui dimensional — eles se completam.
Empresa que implementa só bronze + silver tem warehouse caótico mascarado de lakehouse moderno. Empresa que implementa bronze + silver + gold tem o melhor dos dois mundos.
A régua antes de descartar modelagem dimensional
Cinco perguntas pra responder antes de aceitar a tese "vamos pra lakehouse e sem modelagem":
- Quantos dashboards executivos a empresa tem? Acima de 20, modelagem dimensional na camada gold é quase obrigatória. Sem ela, divergência crônica.
- Precisa de histórico de mudança de dimensão? Cliente que mudou segmento, produto que mudou categoria, vendedor que mudou time. Se sim, SCD em dimensional é mais limpo que código custom.
- Quantos usuários técnicos vão modelar? Se passa de 10 pessoas modelando, governança semântica central é necessária. Caso contrário, cada um inventa.
- Empresa já tem dbt rodando? Se sim, modelagem dimensional via dbt mart é caminho natural. Não exige nova tecnologia — só disciplina.
- Performance de query é crítica em algum caso? Dashboard com 100 usuários simultâneos, relatório operacional em tempo real. Se sim, pré-agregação dimensional vence schema-on-read cru.
Respondendo as cinco com sim ou "depende", a modelagem dimensional continua valendo. Recusar a régua é entrar no ciclo de 18 meses pra redescobrir o que ela resolveria.
A decisão pra 2026
Se sua empresa está discutindo "lakehouse e modelagem é overhead", três movimentos honestos:
Adote medallion architecture. Bronze + silver no lakehouse, gold em dimensional via dbt mart. Não é trade-off — é complementar.
Identifique os 10 modelos gold críticos. Métricas centrais (receita, churn, ativação, conversão) merecem modelagem dimensional cuidadosa, com SCD onde aplicável, documentação séria. Os outros podem ficar mais leves.
Resista ao "vamos modelar depois". Mesmo erro do dado limpo depois. Modelar quando o problema explode é 5× mais caro que modelar quando o uso começa.
Modelagem dimensional em 2026 não é nostalgia. É a forma testada por 30 anos de organizar dado pra consumo analítico — e nenhuma evolução de storage tornou isso obsoleto. Lakehouse é peça nova; dimensional continua sendo método. Quem combina os dois entrega plataforma sólida. Quem tenta substituir um pelo outro descobre o gap em 18 meses, geralmente em reunião difícil sobre número divergente.