A DuckDB Labs shipou DuckLake 1.0 no mês passado e a MotherDuck conectou o suporte de produção — um formato de tabela lakehouse que diverge do Iceberg e Delta Lake de uma forma arquiteturalmente consequente: em vez de metadados como arquivos manifesto JSON no object storage, todos os metadados e o catálogo vivem num banco SQL. O framing da equipe sobre o porquê é direto — metadados file-based em formatos de lake levam a coordenação complexa, operações de metadados lentas, e muitos arquivos pequenos. Os números do lançamento da MotherDuck reivindicam 10x mais rápido em queries e 10x mais transações por segundo no hot path do catálogo. Os dados brutos ficam em Parquet no object storage; só o catálogo se moveu para durabilidade classe-Postgres. Licença MIT. Os clientes shipam para Apache DataFusion, Spark, Trino e Pandas — multi-engine desde o dia um, não DuckDB-locked.

O mecanismo que importa para builders é o data inlining. O small-file problem do Iceberg é a dívida crônica de compaction que pega cada lakehouse em produção: stream algumas linhas, elas vão para um novo arquivo Parquet, repete dez mil vezes, agora seus reads escaneiam dezenas de milhares de arquivos pequenininhos até o job de compaction alcançar. O threshold de inlining do DuckLake por default em dez linhas — qualquer coisa abaixo pula direto pro catálogo SQL em vez de spawnar um novo objeto Parquet. Tabelas sorted e bucket partitioning para colunas de alta cardinalidade estão no 1.0, tipos geometry receberam upgrade, e os deletion vectors são explicitamente compatíveis com Iceberg — um vector emitido pelo DuckLake se lê limpo de consumers Iceberg existentes. A interop é intencional; esse é um formato tentando ganhar em características operacionais, não em lock-in. O tradeoff arquitetônico é que agora você tem uma dependência de disponibilidade Postgres (ou compatível) no caminho de metadados. Para a maioria dos builders, é feature — Postgres foi tunado para reads de baixa latência e alta concorrência por quarenta anos. Para builders rodando lakehouses multi-region sem um catálogo DB central óbvio, é a nova pergunta a projetar em volta.

Leitura ecossistema: a guerra de formatos lakehouse entre Iceberg e Delta Lake tem dez anos nesse ponto e a resposta operacional não chegou. Iceberg ganhou a batalha da spec de metadados mas Delta ainda shipa melhor tooling. DuckLake chega de um terceiro eixo — desviar do catálogo file-based por completo. Não vai substituir Iceberg em deploys de produção que já têm pipelines de compaction funcionando e queries Iceberg-nativas, mas para builders levantando uma nova camada analítica em 2026, a abordagem catálogo SQL vai parecer muito melhor operacionalmente. O pitch da MotherDuck — «setup leva 2 comandos SQL» — é descrição honesta: se você já tem um Postgres, você tem um catálogo DuckLake. O suporte multi-engine significa que você não está apostando no DuckDB; você pode rodar analytics pesado no Trino enquanto queries operacionais leves batem DuckDB direto contra os mesmos dados. A grande pergunta aberta é o path de migração do Iceberg, que o anúncio de lançamento deixa vago — é o workstream que os próximos 6 meses provavelmente vão fazer emergir.

Movimento prático: se você está construindo uma nova camada analítica ou feature store de ML neste trimestre, DuckLake 1.0 vale uma semana de eval contra Iceberg. O gap de simplicidade de setup sozinho é real — substitua sua configuração Glue/Hive Metastore por uma connection string Postgres. Se você roda Iceberg em produção com tuning de compaction ativo, o custo de migração é não-zero e não há caminho documentado; revisite quando o DuckLake shipar readers/writers Iceberg explícitos em ambas as direções. Para pipelines ML que escrevem batches pequenos com frequência (ingestion de training-data, logs de inferência, eval traces), data inlining sozinho resolve uma classe de dor operacional que abordagens baseadas em compaction continuam pagando. A promessa de spec estável 1.0 + o compromisso de backward-compatibility torna isso seguro para apostar em builds novos; para builds existentes, a pergunta é se sua fricção atual vale o custo de migração.