Iceberg ganó la guerra de formatos. Ahora cuenta el catálogo

6 Min. de lectura

La disputa sobre qué formato de tablas sustenta el Data Lakehouse abierto está prácticamente resuelta. Apache Iceberg se ha impuesto. Snowflake, Databricks y Amazon lanzan la versión 3, mientras Delta Lake se acerca al mismo denominador a través de UniForm. Así, la verdadera decisión arquitectónica se desplaza a un punto que muchos equipos de plataformas aún subestiman: el catálogo.

Lo más importante en resumen

• La guerra de formatos está prácticamente zanjada: Iceberg v3 ya está disponible con carácter general en Snowflake, en fase de Public Preview en Databricks y Amazon S3 Tables sigue su ritmo. Delta Lake ofrece sus tablas también como Iceberg mediante UniForm. El principio es claro: escribir una vez, leer desde múltiples motores.
• El catálogo se convierte en el nuevo mecanismo de lock-in: La dependencia pasa del formato al servicio que gestiona los metadatos y los permisos. Polaris, Unity Catalog y AWS Glue compiten precisamente por esta capa.
• La especificación REST decide sobre la libertad: Quien elija un catálogo que cumpla plenamente con la interfaz REST de Iceberg mantendrá motores y nubes intercambiables. Quien no lo verifique, trasladará el lock-in un nivel más arriba.

RelacionadoCross-Cloud Lakehouse y Egress-Caching  /  BigQuery desafía a Databricks con puente a S3

Por qué la guerra de formatos ha terminado

Durante tres años, la primera pregunta en cualquier proyecto de Lakehouse era: ¿Iceberg, Delta Lake o Hudi? Esta cuestión está prácticamente resuelta. Para los nuevos Lakehouses abiertos, Apache Iceberg es el estándar. Netflix, Apple, Airbnb y LinkedIn gestionan con él volúmenes de datos en la escala de petabytes. Las grandes plataformas ya ofrecen un amplio soporte al formato, aunque no siempre de forma completa.

El factor decisivo es la versión 3. Iceberg v3 incorpora de forma nativa Deletion Vectors, Row Lineage y el tipo de datos Variant. Hasta hace poco, estos eran los aspectos en los que Delta Lake llevaba ventaja técnica. La brecha entre el rendimiento de Delta y la compatibilidad de Iceberg se reduce así considerablemente. Snowflake hizo que v3 estuviera disponible con carácter general en mayo, Databricks la ofrece en Public Preview y Amazon S3 Tables también la soporta. La cobertura aún no es completa: AWS Athena, por ejemplo, todavía no lee v3.

Paralelamente, Delta Lake se acerca en lugar de distanciarse. Mediante UniForm, un equipo puede ofrecer sus tablas Delta también como Iceberg, permitiendo su lectura desde Snowflake, BigQuery, Redshift o Trino. Los observadores esperan que las próximas versiones de ambos proyectos sigan convergiendo. Para los usuarios, esto significa que la base es compartida y que la antigua apuesta por un único formato ya no es necesaria.

Cuatro catálogos, cuatro perfiles de lock-in

Cuando el formato se vuelve intercambiable, el catálogo decide el acceso. Este registra qué tablas existen, dónde se encuentran sus metadatos, quién puede leerlas y cómo se serializan correctamente las operaciones de escritura. Aquí es donde reside la nueva competencia. Cuatro opciones dominan el mercado, cada una con su propio grado de libertad.

1. Apache Polaris como referencia neutral. Snowflake hizo público Polaris en 2024 y lo cedió a la Fundación Apache, donde continúa como proyecto independiente de fabricantes. Polaris implementa la interfaz REST de Iceberg, incluyendo la gestión de derechos y credenciales para los motores de acceso. Consecuencia: el menor lock-in estructural, a cambio del esfuerzo operativo de un servicio propio o una variante gestionada.
2. Unity Catalog en el ecosistema de Databricks. Databricks abre Unity Catalog a clientes Iceberg y comparte los recursos en tiempo real con Snowflake, Trino, Flink o Spark, sin copias. Consecuencia: fuerte gobernanza y funciones de compartición, pero la gravedad atrae hacia la plataforma Databricks.
3. AWS Glue con federación de catálogos. Glue se comunica mediante federación con Polaris, Unity Catalog y otros catálogos compatibles con REST. Consecuencia: quienes ya están en AWS integran catálogos existentes en lugar de reemplazarlos. La migración se realiza entonces de forma gradual.
4. Snowflake Open Catalog como Polaris gestionado. Para equipos que no desean operar Polaris por su cuenta, Snowflake ofrece la versión alojada, y Dremio otra alternativa. Consecuencia: la neutralidad de Polaris sin carga operativa propia, a cambio de una relación con el proveedor del servicio.

La clasificación es incómoda, pero clara: un formato abierto no protege automáticamente contra la dependencia. El catálogo puede reintroducir el lock-in que el formato acaba de eliminar. Por eso, la cuestión del catálogo debe plantearse al inicio de la arquitectura.

Fuente: Panorama de catálogos REST de Iceberg, situación a mediados de 2026.

Dónde realmente cojea la migración

El cambio rara vez fracasa por el formato y casi siempre por la gobernanza. Un catálogo no solo gestiona nombres de tablas, sino que también distribuye permisos de acceso y credenciales temporales en la nube a los motores de consulta. Precisamente este *Credential Vending* debe funcionar más allá de los límites de la nube y seguir siendo trazable. Polaris ha reforzado esto en la versión 1.4 de abril, por ejemplo, con etiquetas de sesión para la asignación en los registros de auditoría de AWS y con métricas almacenadas del catálogo.

El segundo obstáculo es la transición en sí. Quien hoy gestiona tablas en Glue, en el metastore de Hive o en un formato propietario no quiere cambiar todo a la vez en una gran migración. La federación de catálogos es aquí el camino pragmático. Permite introducir gradualmente un catálogo neutral como Polaris y seguir operando los sistemas antiguos en paralelo hasta que el corte quede bien ajustado.

Lo importante sigue siendo el aspecto de los costes. Las consultas entre nubes solo resultan económicas cuando se tienen en cuenta el movimiento de datos y el *egress*. El catálogo regula el acceso, pero la cuestión de los costes sigue siendo independiente y debe formar parte de la misma decisión.

Qué deciden ahora los equipos cloud

Para los equipos de plataforma en la región DACH, esto significa concretamente: la elección del formato ya no debe generar un largo debate; Iceberg está establecido. La energía debe centrarse en la cuestión del catálogo. Quien busque la máxima independencia de motores y nubes debe comprobar si el catálogo cumple realmente por completo la especificación REST. Al mismo tiempo, debe calcular con honestidad el esfuerzo operativo de una solución neutral.

Quien ya esté profundamente integrado en una plataforma puede utilizar su catálogo, pero debe ser consciente del vínculo que asume. La federación sigue siendo la opción de salida. La pregunta clave de verificación hoy en día se centra en el catálogo: ¿quién controla las claves? El formato se ha convertido en un detalle secundario. El acceso a los datos entre nubes se está convirtiendo en un requisito previo para que los agentes de IA puedan acceder al mismo conjunto de datos.

Preguntas frecuentes

¿Qué es exactamente un catálogo Iceberg?

El catálogo es el servicio que sabe qué tablas Iceberg existen, dónde se encuentran sus metadatos actuales y quién tiene permiso para leerlas o escribirlas. Mantiene consistente el acceso de múltiples motores al mismo conjunto de datos. Sin catálogo, una tabla Iceberg no es más que un conjunto de archivos sin un marco fiable.

¿Queda zanjada así la disputa entre Iceberg y Delta Lake?

En gran medida. Delta Lake ofrece sus tablas también como Iceberg a través de UniForm, de modo que los motores Iceberg pueden leerlas. Para los nuevos lakehouses abiertos, Iceberg es el caso estándar; la elección del formato ya no ata tanto.

¿Por qué se considera Apache Polaris especialmente neutral?

Polaris pertenece a la Fundación Apache e implementa la interfaz REST de Iceberg. Puede autogestionarse o contratarse como servicio gestionado a través de Snowflake y Dremio. De este modo, el acceso permanece independiente de una única plataforma.

¿Tengo que migrar todo de golpe para usar un catálogo neutral?

No. La federación de catálogos permite introducir un catálogo neutral de forma gradual y seguir operando en paralelo sistemas existentes como Glue o el metastore de Hive. Así se distribuye el riesgo, en lugar de acumularlo en una gran migración.

¿Qué relación tiene la cuestión del catálogo con los agentes de IA?

Los agentes de IA necesitan un acceso fiable y regulado a los datos, a menudo más allá de los límites de la nube. El catálogo proporciona precisamente esta capa de acceso gobernado a un único conjunto físico de datos. Sin una estrategia clara de catálogo, el análisis de agentes entre nubes sigue siendo un trabajo fragmentario.

Fuente de la imagen de portada: Pexels / panumas nikhomkhai (px:17323801)