Apache Iceberg vs Delta Lake vs Hudi: qué formato de tabla elegir en 2026

Los tres resuelven el mismo problema —dar garantías de base de datos a ficheros en un data lake— pero nacieron de necesidades distintas, y eso marca su carácter. Conviene partir de una definición limpia de cada uno antes de compararlos.

• Apache Iceberg: formato de tabla abierto creado en Netflix y gobernado por la Apache Software Foundation, diseñado como especificación neutral e independiente del motor. Su arquitectura de metadatos en árbol (metadata file → manifest list → manifests) permite que varios motores lean y escriban la misma tabla concurrentemente. Destaca por el hidden partitioning y la evolución de particiones sin reescribir histórico. Desde Iceberg v3, cada fichero lleva su propio deletion vector.
• Delta Lake: formato creado por Databricks y donado a la Linux Foundation, construido sobre un log de transacciones (_delta_log) en JSON con checkpoints en Parquet. Aporta ACID, time travel, schema enforcement y la operación MERGE. Sus diferenciales son el rendimiento dentro de Databricks/Spark y funciones como liquid clustering, Z-ordering y deletion vectors.
• Apache Hudi: formato creado en Uber y gobernado por la Apache Software Foundation, diseñado desde su origen para upserts e ingesta incremental de baja latencia. Es el único que ofrece de serie merge-on-read y change streams nativos, lo que lo hace el más eficiente para CDC real (no solo inserciones, también actualizaciones y borrados).

Esta tabla resume las dimensiones que de verdad condicionan la decisión. Más abajo desarrollamos las dos o tres que suelen inclinar la balanza en un proyecto real.

La tabla orienta, pero en la práctica solo unas pocas dimensiones inclinan la decisión. Estas son las que más pesan.

Arquitectura de metadatos. Iceberg usa un árbol de manifests inmutables que escala bien con miles de particiones y favorece la concurrencia multi-motor. Delta usa un log secuencial de transacciones, eficiente y simple pero históricamente más acoplado a Spark. Hudi mantiene una timeline de acciones y un índice a nivel de registro, lo que le da ventaja para localizar y actualizar filas concretas.

Copy-on-write vs merge-on-read. Copy-on-write (CoW) reescribe los ficheros afectados en cada actualización: lecturas rápidas, escrituras caras. Merge-on-read (MoR) registra los cambios en logs ligeros y los fusiona en lectura o en una compactación posterior: escrituras rápidas y baja latencia de ingesta, a costa de lecturas algo más lentas hasta compactar. Hudi nació con MoR; Iceberg y Delta lo incorporan vía deletion vectors, pero con menos madurez para upserts intensivos.

• CDC e ingesta incremental: aquí está la distinción menos explicada y más decisiva. Hudi rastrea de serie todos los cambios (inserciones, actualizaciones y borrados) y los expone como flujos de cambio. Iceberg ofrece lectura incremental pero solo de inserciones, no de actualizaciones ni borrados, lo que limita el CDC verdadero.
• Ecosistema y portabilidad: Iceberg tiene el soporte multi-motor más amplio (Spark, Flink, Trino, Snowflake, BigQuery, DuckDB) y gobernanza neutral. Si tu prioridad es no quedar atado a un proveedor, es la apuesta más segura.
• Rendimiento por ecosistema: Delta da su mejor rendimiento y funciones (liquid clustering, deletion vectors) dentro de Databricks/Spark. Fuera de ahí, la ventaja se diluye.

Sí, sigue importando, aunque cada vez menos por bloqueo de proveedor y más por idoneidad técnica. Dos tecnologías han difuminado las fronteras entre formatos.

Delta UniForm (GA) hace que una tabla Delta genere metadatos Iceberg —y ahora también Hudi— en paralelo, sin duplicar datos: cualquier cliente Iceberg puede leerla. Apache XTable (incubating), respaldado por Microsoft, Google y Onehouse, traduce metadatos de forma omnidireccional entre los tres formatos. La adquisición de Tabular (creadores de Iceberg) por parte de Databricks aceleró esta convergencia.

La consecuencia práctica es que muchas organizaciones conviven con varios formatos: Delta para pipelines nativos de Databricks, Iceberg para analítica compartida entre plataformas y Hudi para flujos de CDC de alta frecuencia. La interoperabilidad reduce el coste de equivocarse, pero el formato de origen sigue condicionando rendimiento, latencia de ingesta y capacidades de CDC.

Reducido a lo esencial, la decisión depende de dónde corre tu cómputo y de qué tipo de carga domina tu pipeline.

• Si tu plataforma es Databricks o todo tu cómputo es Spark → Delta Lake. Máximo rendimiento y funciones nativas; con UniForm conservas interoperabilidad.
• Si necesitas analítica a gran escala consultada por varios motores (Trino, Snowflake, BigQuery, Flink) y gobernanza neutral → Apache Iceberg. Es la apuesta estándar y a prueba de futuro.
• Si tu carga dominante es ingesta en streaming o CDC con upserts de alta frecuencia y baja latencia → Apache Hudi. El más maduro en merge-on-read y change streams.
• Si no lo tienes claro o prevés varios casos de uso → empieza por Iceberg como capa de analítica y apóyate en UniForm/XTable para interoperar. Es la decisión con menor coste de reversión.