La pelea entre Apache Iceberg y Delta Lake se resolvió de una forma que casi nadie predijo en 2023: ganaron los dos, y perdió la idea de que elegir formato te amarra de por vida. Databricks llevó Managed Iceberg, Iceberg V3 y Foreign Iceberg a disponibilidad general dentro de Unity Catalog. Snowflake escribe Iceberg de forma nativa y donó el catálogo Polaris a la Apache Software Foundation. BigQuery lee y escribe Iceberg a través de BigLake.
Dicho eso, alguien todavía tiene que escribir el CREATE TABLE. Y ahí sí hay que decidir.
Qué es un formato de tabla y por qué te importa
Los dos resuelven el mismo problema. Tienes miles de archivos Parquet en un bucket de S3, ADLS o GCS, y Parquet por sí solo no sabe nada de transacciones, de versiones ni de qué archivos forman la tabla de verdad. El formato de tabla agrega una capa de metadatos encima: transacciones ACID, viaje en el tiempo, evolución de esquema y borrados a nivel de fila.
Delta Lake nació dentro de Databricks y usa un log de transacciones en JSON dentro de la carpeta _delta_log. Iceberg nació en Netflix y llevó los metadatos un paso más allá, con archivos de manifiesto que apuntan a los datos sin depender de cómo esté particionado el directorio. De ahí sale la diferencia práctica más citada: el particionamiento oculto de Iceberg, que te deja cambiar la estrategia de partición sin reescribir la tabla ni pedirle al analista que recuerde filtrar por la columna correcta.
Lo que cambió en 2026
Tres movimientos redefinieron la conversación este año:
- ▸Databricks adoptó Iceberg como ciudadano de primera clase dentro de Unity Catalog, sin dejar de tratar a Delta como su formato central. Managed Iceberg ya es GA.
- ▸Las jugadas multi-motor —Polaris de Snowflake, S3 Tables de AWS, BigLake de BigQuery— eligieron Iceberg como formato nativo. Ninguna eligió Delta.
- ▸La capa de catálogo se volvió federada. En noviembre de 2026 BigQuery Lakehouse llevó a GA los endpoints de catálogo federado contra Unity Catalog y otros proveedores remotos, para consultar tablas Iceberg sin mover un byte.
Y encima está la convergencia: Delta Lake UniForm expone una tabla Delta como si fuera Iceberg, Snowflake lee los dos formatos y Apache XTable traduce metadatos entre ellos. La elección pesa bastante menos que hace dos años.
La pregunta de 2026 ya no es qué formato es mejor, sino qué catálogo va a gobernar tus tablas. Ahí es donde queda el amarre real al proveedor.
Cuándo Delta, cuándo Iceberg
Si todo tu mundo es Databricks y va a seguir siéndolo, Delta sigue siendo lo más cómodo: el runtime está afinado para él, funciones como Liquid Clustering o Deletion Vectors llegan primero ahí, y Unity Catalog te da el gobierno sin configurar nada extra. Trabajar bien con Delta es, en la práctica, trabajar bien con Spark, así que esa base te sirve igual.
Si en tu empresa conviven dos o más motores —un equipo en BigQuery, otro en Snowflake, un tercero con Trino o Spark sobre S3— Iceberg es la apuesta más segura. Es el formato que todos leen y escriben sin intermediarios, y el que mejor sobrevive a que la empresa cambie de proveedor dentro de tres años.
Lo que nadie te dice: la mayoría de los equipos que debaten esto durante semanas tienen menos de 5 TB y menos de diez tablas que de verdad importan. A esa escala, los dos formatos se comportan igual y la decisión correcta es la que no te hace perder un mes. El dolor real no aparece en el formato, aparece cuando tienes 40 tablas pequeñas, compactación sin programar y nadie sabe por qué la consulta tarda ocho minutos.
Tres cosas que importan más que el formato
Primero, la compactación. Los dos formatos sufren el problema de los archivos pequeños y los dos te dan una operación para resolverlo (OPTIMIZE en Delta, rewrite_data_files en Iceberg). Si no la programas, tu lakehouse se degrada solo, sin importar qué elegiste.
Segundo, la retención. El viaje en el tiempo es maravilloso hasta que descubres que guardas 90 días de versiones de una tabla que se reescribe entera cada noche. Revisa VACUUM y expire_snapshots antes de que lo haga el área de finanzas.
Tercero, el gobierno. Quién puede leer qué columna, de dónde salió este número, qué pasa si alguien borra una tabla. Esa capa vive en el catálogo —Unity Catalog, Polaris, Glue— y es la que de verdad te cuesta cambiar después. Vale más tiempo de diseño que la discusión de formatos, y es justo lo que separa a un Data Architect de alguien que solo escribe pipelines.
Migrar de un formato a otro: menos dramático de lo que suena
La frase que más miedo da en estas reuniones es "y si después nos arrepentimos". La respuesta corta: migrar entre Delta e Iceberg no reescribe tus datos, reescribe los metadatos. Los archivos Parquet se quedan donde están. Herramientas como Apache XTable generan los manifiestos del otro formato apuntando a los mismos archivos, y Delta Lake UniForm va un paso más allá: mantiene los metadatos de Iceberg actualizados sobre una tabla Delta, de forma que un motor externo la ve como Iceberg sin que tú cambies nada en tus pipelines.
Lo que sí duele de una migración son las cosas de alrededor. Los jobs que leen rutas de archivo a mano en vez de pasar por el catálogo. Las vistas materializadas que alguien creó hace dos años y nadie documentó. Los permisos, que no viajan solos. Calcula el trabajo real ahí, no en la conversión de la tabla.
El detalle técnico que de verdad cambia tu día a día
Si tengo que elegir una sola diferencia práctica, me quedo con el particionamiento. En Delta, la partición es física: los datos viven en carpetas del tipo fecha=2026-11-11, y si el analista filtra por una columna derivada en vez de por la columna de partición, el motor escanea la tabla entera. Es el clásico "la consulta tarda ocho minutos y nadie entiende por qué".
Iceberg guarda la relación entre la columna y la partición en los metadatos. El usuario filtra por la fecha del evento y el motor resuelve solo qué archivos tocar. Además te deja cambiar la estrategia —de mensual a diaria, por ejemplo— sin reescribir lo viejo: las particiones conviven. En una tabla que crece de forma desigual, eso te ahorra una reescritura completa al año.
Delta no se quedó quieto: Liquid Clustering resuelve una parte del mismo problema sin carpetas rígidas, y en Databricks funciona muy bien. La diferencia es que Liquid Clustering es de Databricks, y el particionamiento oculto de Iceberg lo entiende cualquier motor que lea la tabla. Otra vez la misma pregunta de fondo: cuántos motores vas a tener.
Tres señales de que tu lakehouse necesita atención ya
- ▸Tus consultas más lentas son sobre tablas chicas. Casi siempre son miles de archivos de pocos kilobytes; es compactación pendiente, no falta de cómputo.
- ▸Nadie sabe decirte cuántas versiones guardas de cada tabla. Ahí hay almacenamiento pagado que nadie revisó.
- ▸Dos equipos leen la misma tabla por caminos distintos, uno por el catálogo y otro por la ruta del bucket. El día que cambies el formato, uno de los dos se rompe sin aviso.
Cómo aprender esto con las manos
La forma más rápida de entenderlo es montar un lakehouse chico y romperlo a propósito: escribir, borrar filas, cambiar el esquema, volver a una versión anterior. Introducción a Databricks te deja con Delta Lake funcionando en unas horas, y el bootcamp Databricks Data Engineer entra en Unity Catalog, particionamiento y optimización, que es donde se gana el sueldo.
Si todavía te falta la base completa —modelado, ingesta, orquestación y nube— la ruta Data Engineer es el orden en que conviene aprenderlo, y el catálogo de cursos te deja ajustar la secuencia a la nube que usa tu empresa. Un apunte para tu CV: las ofertas en LATAM casi nunca piden "Iceberg" a secas; piden Spark, SQL y una nube, y el formato aparece dentro de la descripción.
Si prefieres ver estas piezas armadas antes de comprometerte con un bootcamp, en la Comunidad AI Builders hacemos un taller en vivo por semana sobre lo que está saliendo, desde 19 USD al mes.
