La pila de datos analiticos ha pasado la ultima decada prometiendo una separacion limpia entre almacenamiento, motor y transformacion, pero solo en los ultimos doce meses esa promesa ha dejado de sonar a folleto comercial. Apache Iceberg con catalogos REST, dbt como capa declarativa y un motor de consulta intercambiable por debajo se han convertido en el esqueleto real de los nuevos proyectos de analitica. Lo escribo aqui porque el patron se esta repitiendo en demasiados equipos como para ignorarlo, y porque las decisiones tomadas ahora condicionan los proximos cinco anos de una plataforma de datos.
Por que Iceberg se ha llevado el gato al agua
Cuando empezo la conversacion del formato de tabla abierto, los tres candidatos eran Iceberg, Delta Lake y Hudi. A finales de 2025 la realidad es que Iceberg ha ganado la guerra de adopcion por motivos mundanos mas que tecnicos. Databricks compro Tabular en 2024 y empezo a converger Delta e Iceberg. Snowflake, BigQuery y Redshift soportan Iceberg de manera nativa para lectura y, en varios casos, tambien para escritura. AWS Glue ofrece Iceberg como formato por defecto en catalogos nuevos. Cuando tus tres almacenes principales y el mayor motor analitico abierto convergen en el mismo formato, la eleccion deja de ser tecnica.
Lo interesante es que Iceberg no es el mejor en ningun aspecto individual. Delta tiene un motor mas acoplado y rapido en Databricks, Hudi sigue siendo superior para actualizaciones frecuentes en streaming. Pero Iceberg es el que ha conseguido mantener la abstraccion mas limpia entre especificacion y motor. Sus metadatos son JSON y Avro, su modelo de particionado oculto evita los errores clasicos del predicado mal escrito, y su soporte de viajes en el tiempo y esquemas evolutivos es el mas riguroso de los tres.
El giro de 2025 ha sido el catalogo REST. Hasta hace un ano, usar Iceberg fuera de AWS Glue implicaba integrar con Hive Metastore o montar un catalogo a mano. La especificacion REST de Iceberg 1.6 estandarizo una API HTTP que cualquier motor puede consumir, y proveedores como Tabular, Lakekeeper, Gravitino y Unity Catalog la implementan. El resultado es que hoy puedes tener Trino, Spark, DuckDB y un cliente de Python leyendo y escribiendo las mismas tablas a traves de un unico servicio, sin que ninguno se lleve mas bien con el catalogo que los demas.
dbt encima: lo que cambia con Fusion
La capa de transformacion ha evolucionado en paralelo. dbt Labs presento en mayo el motor Fusion, reescritura en Rust de dbt-core que compila el grafo de modelos, valida SQL antes de ejecutarlo y emite planes de ejecucion optimizados. El motor antiguo basado en Python sigue funcionando para proyectos existentes, pero Fusion introduce validacion estatica de columnas y tipos en tiempo de compilacion, algo que faltaba y que ha causado muchas horas perdidas persiguiendo errores que un analizador debio haber detectado antes.
Lo relevante no es la velocidad, aunque tambien. Lo relevante es que dbt Fusion acepta Iceberg como destino nativo en lugar de tratarlo como un adaptador mas. La documentacion oficial incluye ejemplos de materializacion en tablas Iceberg con particionado oculto, viajes en el tiempo y propiedades de tabla. Para equipos que hasta ahora estaban en Snowflake o BigQuery puros, esto abre la puerta a desacoplar la plataforma de almacenamiento del motor de consulta sin reescribir modelos.
En mi opinion, la combinacion dbt mas Iceberg resuelve el problema real de la mayoria de plataformas de datos medianas: el bloqueo del proveedor no viene del motor, viene de los datos. Si tus tablas viven en Iceberg con un catalogo REST, migrar de Snowflake a Trino, o probar DuckDB encima del mismo lago, deja de ser una reescritura completa para ser un cambio de conexion. El dia que alguien eleva los precios un 40 por ciento, tienes opciones reales.
Los puntos donde sigue doliendo
No todo esta resuelto. El rendimiento de consultas interactivas sobre Iceberg en un motor abierto como Trino sigue siendo inferior al de un almacen cerrado bien tuneado, a veces por un factor de dos o tres. La razon es que Snowflake y BigQuery tienen optimizadores de consulta, cache de resultados y gestion de recursos afinados a lo largo de una decada que los motores abiertos no pueden replicar con cuatro ingenieros. Para tableros operacionales con docenas de consultas por segundo, Iceberg abierto sigue siendo demasiado frio.
El segundo punto es la operacion del propio catalogo. Un catalogo REST es infraestructura critica: si se cae, todos los motores pierden la vision coherente de las tablas. Proveedores comerciales como Tabular resuelven esto, pero montarlo tu mismo con Lakekeeper implica alta disponibilidad, copias de seguridad de metadatos y un plan de recuperacion que la mayoria de equipos no tenian cuando vivian dentro de Snowflake y el catalogo era parte del servicio.
El tercer frente es el coste de escritura. Iceberg optimiza para lecturas analiticas con muchas particiones y archivos Parquet grandes, pero mantener ese optimo requiere trabajos de compactacion y limpieza regulares. Olvidarse de compactar una tabla con ingesta de streaming lleva en semanas a miles de archivos pequenos y consultas que tardan minutos. Los almacenes cerrados hacen esto por ti en segundo plano y lo cobran en la factura; con Iceberg tienes que orquestarlo a mano.
Cuando compensa dar el paso
Mi lectura tras acompanar a varios equipos en esta transicion es que el lakehouse abierto con Iceberg y dbt compensa cuando se cumplen tres condiciones a la vez. La primera es volumen suficiente para que el coste del almacen cerrado sea una partida significativa del presupuesto, tipicamente por encima de los seis digitos anuales. Por debajo de eso, el ahorro no cubre el coste operativo de mantener el catalogo y los trabajos de compactacion.
La segunda es heterogeneidad de cargas. Si todo tu analisis es SQL interactivo sobre datos tabulares, un almacen cerrado te dara mejor experiencia. Iceberg brilla cuando hay que mezclar Python, Spark, SQL interactivo y modelos de aprendizaje automatico sobre las mismas tablas sin duplicar datos. En ese escenario, la abstraccion abierta compensa la perdida de rendimiento puntual.
La tercera, y probablemente la mas importante, es que el equipo tenga madurez de ingenieria de datos para operar infraestructura propia. Iceberg no es Snowflake: no se configura en un panel web y funciona. Requiere entender formatos de archivo, metadatos, catalogos, planes de consulta y los detalles finos de cada motor. Equipos que llegan desde el almacen cerrado suelen subestimar esta curva y acaban con un lakehouse peor operado que el almacen que abandonaron. Ante la duda, empezaria por un piloto pequeno con un dataset no critico antes de comprometer la plataforma entera.
