DuckLake 1.0: O data lake que troca metadados espalhados por um banco SQL – Simplicidade e baixa latência contra a interoperabilidade multi-engine

Em um ecossistema dominado por formatos que espalham metadados por dezenas de arquivos no object storage, o DuckLake 1.0 propõe o impensável: trocar toda essa complexidade por um banco SQL. A pergunta que ecoa entre engenheiros de dados é se simplicidade e baixa latência valem mais que a interoperabilidade multi-engine.

O que é DuckLake 1.0?

DuckLake não é apenas mais um formato de arquivo. É uma reimaginação completa da camada de metadados de um data lake. Enquanto Apache Iceberg e Delta Lake armazenam o estado de uma tabela como uma árvore de arquivos JSON, Avro ou Parquet — que precisam ser lidos, fundidos e versionados constantemente —, o DuckLake adota uma filosofia radicalmente diferente.

Armazena metadados diretamente em um banco de dados SQL relacional.

O catálogo da tabela deixa de ser um conjunto de arquivos imutáveis no S3 e passa a ser um conjunto de linhas em uma tabela SQL, atualizáveis via transações ACID tradicionais. A primeira implementação vem como extensão nativa do DuckDB, focada em pequenas atualizações atômicas, classificação e particionamento otimizados.

Como funciona na prática

A extensão DuckLake gerencia um banco SQL interno — que pode ser SQLite, PostgreSQL ou o próprio DuckDB — contendo todas as informações de schema, partições, estatísticas e histórico de transações. Pequenas atualizações, como inserts, deletes e merges, são feitas diretamente nesse banco, sem reescrever arquivos de manifesto ou gerar novas versões de snapshot.

O armazenamento de dados continua em Parquet ou Arrow no object storage. O que muda é que o catálogo se torna centralizado e indexado por SQL, eliminando a necessidade de montar o estado completo de uma tabela lendo múltiplos arquivos de manifesto espalhados.

Diferencial crítico: Uma consulta ao catálogo que antes exigia a leitura e fusão de dezenas de arquivos agora se resolve com uma única query SQL indexada.

O trade-off central: metadados distribuídos versus centralizados

A decisão de centralizar metadados em um banco SQL versus distribuí-los em arquivos imutáveis não é meramente técnica — é filosófica. Cada abordagem carrega vantagens e sacrifícios que definem cenários de uso completamente distintos.

Onde DuckLake brilha

• Pipelines analíticos centrados em DuckDB que exigem baixa latência em atualizações incrementais
• Mesas de streaming que recebem milhares de micro-lotes por segundo
• Operações que dependem de consultas complexas ao próprio catálogo — como identificar quais partições foram alteradas nas últimas horas

Onde DuckLake não se encaixa

• Ambientes multi-engine que exigem acesso simultâneo por Spark, Trino e Flink
• Data lakes públicos ou compartilhados entre equipes com stacks heterogêneas
• Cenários com requisitos rigorosos de versionamento imutável e compliance

Observação importante: O DuckLake declara compatibilidade com Iceberg, o que significa que outros mecanismos podem, em teoria, ler tabelas DuckLake. No entanto, a implementação nativa é centrada no DuckDB, e adaptações adicionais provavelmente serão necessárias para motores externos.

Implicações técnicas e arquiteturais

A centralização de metadados via SQL tem consequências profundas no comportamento e na performance do data lake. Não se trata apenas de mover arquivos para um banco — é uma mudança de paradigma.

Leitura de estado simplificada

Nos formatos distribuídos, montar o estado atual de uma tabela exige ler múltiplos arquivos parciais de manifesto, fundi-los e resolver conflitos de versão. No DuckLake, uma única query SQL resolve tudo, com índices e otimizações que aceleram a localização de partições e arquivos de dados.

Atualizações atômicas em milissegundos

Inserts, deletes e merges tornam-se transações diretas no banco de metadados. Isso reduz a latência de operações de segundos — ou até minutos em catálogos grandes — para a casa dos milissegundos, viabilizando pipelines de streaming de alta frequência.

Classificação e particionamento otimizados

O formato foi projetado para explorar ao máximo o motor do DuckDB, com push-down de predicados mais eficiente. As estatísticas de partição são mantidas atualizadas em tempo real no banco SQL, permitindo ao otimizador tomar decisões mais precisas.

Implicações de mercado

O DuckLake chega num momento em que muitas equipes sofrem com a complexidade operacional de manter catálogos Iceberg ou Delta Lake em escala. Seu apelo é claro para organizações que já investiram no ecossistema DuckDB.

• Simplicidade como proposta de valor: equipes pequenas e médias podem montar um data lake funcional sem a curva de aprendizado e a carga operacional de formatos distribuídos.
• Pressão sobre os formatos estabelecidos: a centralização via SQL expõe uma fragilidade dos formatos abertos e pode forçar Iceberg e Delta a evoluírem em direção a catálogos mais rápidos e integrados.
• Risco de lock-in: embora open-source, o DuckLake é intrinsicamente acoplado ao DuckDB. Equipes que adotarem o formato podem encontrar barreiras ao tentar migrar ou integrar com outros motores no futuro.

DuckLake não é um substituto para Iceberg ou Delta Lake — é um ataque cirúrgico a um ponto de dor real: a lentidão de metadados distribuídos em cenários de alta frequência de updates.

Riscos e limitações que merecem atenção

Apesar da elegância da proposta, o DuckLake 1.0 carrega riscos que não podem ser ignorados, especialmente em ambientes de produção de grande escala.

1. Dependência de um banco SQL central: torna-se ponto único de falha e potencial gargalo de desempenho quando o catálogo atinge escala petabyte.
2. Interoperabilidade real ainda incerta: a compatibilidade com Iceberg é declarada, mas a experiência prática com Spark, Trino e Flink ainda não foi validada em larga escala.
3. Maturidade do ecossistema: o formato é recém-lançado, sem ferramentas robustas de governança, catálogo federado ou suporte a rollback comparável ao de formatos estabelecidos.
4. Conflito com paradigmas de imutabilidade: atualizações centralizadas podem quebrar a premissa de que dados brutos nunca são alterados, essencial em auditorias e replicação baseada em object storage.

Alerta de cenário: Em data lakes multi-petabyte com dezenas de engines acessando os mesmos dados simultaneamente, a centralização proposta pelo DuckLake pode se tornar um gargalo mais grave do que a complexidade que pretende resolver.

Visão Metatron: o futuro é híbrido

Acreditamos que o futuro dos data lakes não será definido por um único formato vencedor, mas por camadas especializadas por workload. Formatos distribuídos continuarão dominando camadas históricas e de governança, enquanto formatos centralizados como o DuckLake ganharão espaço em camadas quentes e de streaming.

Pontes automáticas entre esses dois mundos — talvez o próximo passo natural — podem unir o melhor de cada paradigma: a auditabilidade e interoperabilidade dos formatos distribuídos com a velocidade e simplicidade da centralização SQL.

O DuckLake pode ser o primeiro movimento concreto nessa direção. Ou pode permanecer como um experimento brilhante, mas restrito ao nicho do DuckDB. O que está claro é que a engenharia de dados está entrando em uma nova era de especialização por workload, onde não existe um formato único que resolva tudo.

Resumo prático: DuckLake 1.0 é ideal para equipes centradas em DuckDB que precisam de atualizações rápidas e baixa complexidade. Para ambientes multi-engine ou data lakes de escala massiva, Iceberg e Delta Lake seguem como escolhas mais maduras e interoperáveis. A decisão depende de qual trade-off sua equipe está disposta a fazer.

Quer entender qual formato de data lake faz sentido para sua stack? A equipe da Metatron Omni está pronta para ajudar você a navegar essas decisões com clareza estratégica. Entre em contato e vamos conversar sobre sua arquitetura de dados.

Escrito pela equipe da Metatron Omni — onde tecnologia encontra narrativa.