DuckDB Labs shipeó DuckLake 1.0 el mes pasado y MotherDuck cableó el soporte de producción — un formato de tabla lakehouse que diverge de Iceberg y Delta Lake de una manera arquitectónicamente consecuente: en vez de metadatos como archivos manifest JSON en object storage, todos los metadatos y el catálogo viven en una base SQL. El framing del equipo sobre el porqué es directo — los metadatos file-based en formatos de lake llevan a coordinación compleja, operaciones de metadatos lentas, y muchos archivos chicos. Los números del lanzamiento de MotherDuck claiman 10x más rápido en queries y 10x más transacciones por segundo en el hot path del catálogo. Los datos crudos quedan en Parquet en object storage; solo el catálogo se movió a durabilidad clase-Postgres. Licencia MIT. Los clientes shipean para Apache DataFusion, Spark, Trino y Pandas — multi-engine desde el día uno, no DuckDB-locked.
El mecanismo que importa a builders es el data inlining. El small-file problem de Iceberg es la deuda crónica de compaction que pega a cada lakehouse en producción: stream unas filas, van a un nuevo archivo Parquet, repetí diez mil veces, ahora tus reads escanean decenas de miles de archivos chiquitos hasta que el job de compaction alcanza. El umbral de inlining de DuckLake por defecto en diez filas — cualquier cosa debajo va directo al catálogo SQL en vez de spawnear un nuevo objeto Parquet. Tablas sorted y bucket partitioning para columnas de alta cardinalidad están en 1.0, los tipos geometry recibieron upgrade, y los deletion vectors son explícitamente compatibles con Iceberg — un vector emitido por DuckLake se lee limpio desde consumers Iceberg existentes. La interop es intencional; este es un formato tratando de ganar por características operacionales, no por lock-in. El tradeoff arquitectónico es que ahora tenés una dependencia de disponibilidad de Postgres (o compatible) en el camino de metadatos. Para la mayoría de builders es feature — Postgres se tuneó para reads de baja latencia y alta concurrencia por cuarenta años. Para builders corriendo lakehouses multi-region sin una DB de catálogo central obvia, es la nueva pregunta a diseñar alrededor.
Lectura ecosystem: la guerra de formatos lakehouse entre Iceberg y Delta Lake tiene diez años a esta altura y la respuesta operacional no llegó. Iceberg ganó la batalla de la spec de metadatos pero Delta sigue shippeando mejor tooling. DuckLake llega desde un tercer eje — esquivar el catálogo file-based por completo. No va a reemplazar Iceberg en deploys de producción que ya tienen pipelines de compaction funcionando y queries Iceberg-nativas, pero para builders levantando una nueva capa analítica en 2026, el enfoque catálogo SQL va a verse mucho mejor operacionalmente. El pitch de MotherDuck — «setup toma 2 comandos SQL» — es descripción honesta: si ya tenés un Postgres, tenés un catálogo DuckLake. El soporte multi-engine significa que no estás apostando a DuckDB; podés correr analytics pesado en Trino mientras queries operacionales livianas pegan DuckDB directo contra los mismos datos. La gran pregunta abierta es el path de migración desde Iceberg, que el anuncio de lanzamiento deja vago — es el workstream que los próximos 6 meses probablemente surfaceen.
Movida práctica: si estás construyendo una nueva capa analítica o feature store ML este trimestre, DuckLake 1.0 vale una semana de eval contra Iceberg. El gap de simplicidad de setup solo es real — reemplazá tu configuración Glue/Hive Metastore con una connection string de Postgres. Si corrés Iceberg en producción con tuning de compaction activo, el costo de migración es no-cero y no hay camino documentado; revisitá cuando DuckLake shippe readers/writers Iceberg explícitos en ambas direcciones. Para pipelines ML que escriben batches chicos frecuentemente (ingestion de training-data, logs de inferencia, eval traces), data inlining solo resuelve una clase de dolor operacional que los enfoques basados en compaction siguen pagando. La promesa de spec estable 1.0 + el compromiso de backward-compatibility hace esto safe para apostar en builds nuevos; para builds existentes, la pregunta es si tu fricción actual vale el costo de migración.