La pregunta que aparece en comité de datos en 2026: "¿todavía vale hacer modelado dimensional? ¿el lakehouse no resuelve todo?". La respuesta honesta — sí, todavía vale — va contra un poco de la moda. Pero la moda está equivocada, o al menos vendiendo lakehouse para problema que no es de lakehouse. El modelado dimensional (Kimball, star schema, hecho + dimensión) sigue siendo la mejor forma de organizar dato para consumo analítico — y la confusión entre "almacenar dato de cualquier forma" y "modelar para uso" cuesta caro para empresas que todavía no vivieron el ciclo completo.
Este texto es la defensa del modelado dimensional en 2026. No es nostalgia — es argumento práctico sobre dónde el enfoque todavía gana y por qué abandonarlo tiene vuelta fuerte de retrabajo. Cuándo lakehouse es de verdad la arquitectura correcta — y cuándo no lo es — tiene criterios separados propios.
Lo que cambió y lo que no
En 2018, el modelado dimensional era estándar indiscutible. En 2022, el lakehouse (Databricks Delta, Snowflake Iceberg, Apache Iceberg en cualquier storage) se volvió alternativa seria. En 2026, parte del mercado declaró "el modelado murió" — y esa declaración es equivocada por confundir dos problemas separados.
Lo que cambió: storage y formato. El lakehouse permite almacenar dato bruto, semi-estructurado, en parquet abierto. El costo de storage cayó. Schema-on-read sustituye a schema-on-write para muchos casos. ETL pesada para organizar storage se volvió innecesaria.
Lo que NO cambió: la necesidad de modelado semántico. Incluso en el lakehouse, en algún momento alguien necesita decidir: ¿qué es "cliente activo"? ¿Cómo se cuenta el ingreso? ¿Cómo se relaciona la dimensión "producto" con el hecho "venta"? Esa decisión es semántica — no desaparece por cambiar formato de almacenamiento.
Quien confunde los dos cree que el lakehouse reemplaza al modelado. No lo reemplaza. Solo lo posterga. Y postergar el modelado semántico es la forma más cara de descubrir en 18 meses que lo necesitabas.
El lakehouse resolvió storage. No resolvió modelado semántico — y ninguna tecnología va a resolverlo, porque el modelado es decisión de negocio. Empresa que confunde los dos compra lakehouse y descubre el gap en producción.
Dónde el modelado dimensional gana en 2026
Cuatro situaciones específicas donde el dimensional (incluso sobre lakehouse) sigue siendo el enfoque correcto.
1. BI ejecutivo con métricas reutilizadas en N dashboards. Cuando 20 dashboards distintos calculan "ingreso del trimestre", esa lógica necesita vivir en un único modelo — hecho ventas × dim tiempo × dim producto, con agregados pre-calculados. Sin eso, cada dashboard tiene su versión de la métrica, y la dirección pierde confianza. El dimensional lo resuelve.
2. Performance previsible en query analítica. Lakehouse crudo con schema-on-read funciona bien en exploración ad-hoc. En query analítica recurrente (dashboard, reporte, dashboard ejecutivo), el dimensional pre-agregado es 5–50× más rápido. Performance previsible importa cuando 100 usuarios acceden al mismo dashboard al mediodía.
3. Historial de cambio de dimensión (SCD). "El cliente Juan cambió de segmento Premium a Enterprise en marzo". Necesitás reporte de venta del Q1 considerando el segmento de la época — no el actual. SCD Type 2 en dimensional resuelve eso elegantemente. Lakehouse crudo sin modelado obliga a código custom en cada query. En 18 meses de operación, eso se vuelve pesadilla.
4. Gobernanza semántica institucionalizada. El modelo dimensional fuerza documentación (dbt mart es la expresión moderna). Quien mantiene el modelo dimensional mantiene el glosario semántico de la empresa. Lakehouse crudo sin modelado semántico es invitación a "cada uno con su interpretación" — y el data catalog no lo resuelve, solo amplifica lo que existe.
Esos cuatro están bien cubiertos por el modelado dimensional. El lakehouse cubre el 60–70% de ellos parcialmente, pero con costo de gobernanza que se vuelve pasivo.
La trampa del "lakehouse-para-todo"
La tesis vendida por algunos players: "almacená todo crudo, el modelado es overhead, los analistas modelan cuando lo necesiten". Suena moderno. En la práctica, tres problemas aparecen en 12–18 meses.
Problema 1: cada analista se vuelve arquitecto. Sin modelado central, cada uno decide cómo unir hecho y dimensión. Resultado: 10 versiones distintas del mismo análisis, divergencia crónica. Equivalente a lo que el self-service BI mal gobernado produce, en capa más profunda.
Problema 2: la performance degrada en silencio. Query que corría en segundos en warehouse dimensional pasa a 30 segundos en lakehouse crudo. El equipo intenta optimizar con cache, materialized view, partición — y reinventa modelado dimensional caso por caso, sin el nombre lindo.
Problema 3: el historial se vuelve spaguetti. Sin SCD bien diseñado, "cliente en marzo" y "cliente hoy" se confunden. El análisis histórico queda incorrecto. El equipo lo descubre en auditoría, en el peor momento.
Esos tres combinados producen el mismo efecto: empresa que se salteó el modelado dimensional para "ir más rápido" gasta el año siguiente reconstruyendo modelado dimensional dentro del lakehouse, con nombres distintos pero misma estructura. El atajo no fue atajo.
El enfoque que funciona en 2026
No es "lakehouse vs dimensional". Es lakehouse como storage, dimensional como semántica. En capas:
- Bronze (lakehouse crudo). Dato ingerido sin modelado, en formato abierto. Storage barato, schema flexible, fuente de la verdad para reprocesamiento.
- Silver (lakehouse modelado, todavía flexible). Limpieza, deduplicación, conformación básica. Todavía flexible, pero con schema definido.
- Gold (dimensional, dbt mart, semantic layer). Hecho + dimensión, métricas pre-calculadas, gobernanza fuerte. Donde dashboards y BI ejecutivo consumen.
Ese patrón (medallion architecture popularizado por Databricks) es hoy el consenso entre quienes operaron ambos mundos. El lakehouse no reemplaza al dimensional — se complementan.
Empresa que implementa solo bronze + silver tiene warehouse caótico enmascarado de lakehouse moderno. Empresa que implementa bronze + silver + gold tiene lo mejor de los dos mundos.
La regla antes de descartar el modelado dimensional
Cinco preguntas para responder antes de aceptar la tesis "vayamos a lakehouse y sin modelado":
- ¿Cuántos dashboards ejecutivos tiene la empresa? Por encima de 20, el modelado dimensional en la capa gold es casi obligatorio. Sin él, divergencia crónica.
- ¿Hace falta historial de cambio de dimensión? Cliente que cambió de segmento, producto que cambió de categoría, vendedor que cambió de equipo. Si sí, SCD en dimensional es más limpio que código custom.
- ¿Cuántos usuarios técnicos van a modelar? Si pasa de 10 personas modelando, la gobernanza semántica central es necesaria. Si no, cada uno inventa.
- ¿La empresa ya tiene dbt corriendo? Si sí, el modelado dimensional vía dbt mart es camino natural. No exige tecnología nueva — solo disciplina.
- ¿La performance de query es crítica en algún caso? Dashboard con 100 usuarios simultáneos, reporte operativo en tiempo real. Si sí, la pre-agregación dimensional le gana al schema-on-read crudo.
Respondiendo las cinco con sí o "depende", el modelado dimensional sigue valiendo. Negar la regla es entrar al ciclo de 18 meses para redescubrir lo que resolvería.
La decisión para 2026
Si tu empresa está discutiendo "lakehouse y el modelado es overhead", tres movimientos honestos:
Adoptá medallion architecture. Bronze + silver en lakehouse, gold en dimensional vía dbt mart. No es trade-off — es complementario.
Identificá los 10 modelos gold críticos. Las métricas centrales (ingreso, churn, activación, conversión) merecen modelado dimensional cuidadoso, con SCD donde aplique, documentación seria. Los demás pueden quedar más livianos.
Resistí al "modelamos después". Mismo error que el dato limpio después. Modelar cuando el problema explota es 5× más caro que modelar cuando el uso empieza.
El modelado dimensional en 2026 no es nostalgia. Es la forma testeada por 30 años de organizar dato para consumo analítico — y ninguna evolución de storage lo volvió obsoleto. El lakehouse es pieza nueva; el dimensional sigue siendo método. Quien combina los dos entrega plataforma sólida. Quien intenta sustituir uno por el otro descubre el gap en 18 meses, generalmente en reunión difícil sobre número divergente.