DuckDB 2.0 mostra por que vale manter a análise perto dos dados

A nuvem passou anos nos convencendo de que análises sérias pertencem ao data center de outra pessoa. O DuckDB 2.0 chega com uma proposta mais interessante: talvez a arquitetura mais inteligente não seja escolher entre nuvem e ambiente local, mas saber quais tarefas nunca deveriam sair da máquina.

Lançado em 21 de outubro de 2026, o DuckDB 2.0.0 LTS, de codinome “Cinnamon Teal”, é o maior lançamento de recursos do projeto até agora. Ele inclui um protocolo Quack refinado, E/S assíncrona, um tipo VARIANT de primeira classe, modo de agente, gatilhos e um analisador SQL extensível, desenvolvidos a partir de quase 20 mil commits desde o DuckDB 1.5, segundo o projeto DuckDB. A linha LTS terá suporte até pelo menos outubro de 2027.

Essa lista de recursos importa menos do que a direção que ela indica. O DuckDB começou como um banco de dados analítico embutido: SQL executado dentro de um aplicativo, laptop ou dispositivo de borda, em vez de por meio de um serviço de banco de dados permanentemente ativo. A versão 2.0 amplia esse modelo sem abandoná-lo. Na nossa visão, essa é a verdadeira história.

O DuckDB 2.0 trata a nuvem como recurso, não como destino padrão

A adição mais reveladora é o Quack. Agora, o DuckDB pode disponibilizar bancos de dados pela rede, enquanto outro cliente DuckDB pode se conectar a eles e encaminhar consultas remotamente usando a nova instrução CONNECT. Isso parece um banco de dados cliente-servidor convencional, mas a diferença importante é que os dois lados continuam sendo instâncias completas do DuckDB. O cliente ainda pode executar cálculos localmente.

Essa é uma resposta mais nuançada à arquitetura de nuvem do que simplesmente criar um serviço hospedado maior. Um laptop pode inspecionar ou transformar dados localmente, um banco de dados remoto pode cuidar das informações centralizadas e o limite entre os dois pode ser escolhido consulta a consulta. O mesmo mecanismo CONNECT também pode funcionar com PostgreSQL e MySQL, enquanto um otimizador de pushdown remoto envia consultas compatíveis para esses servidores, em vez de trazer tabelas inteiras pela rede.

Essa flexibilidade é valiosa porque o movimento de dados costuma ser o custo oculto da análise. Enviar tudo para um data warehouse aumenta a dependência da conectividade, adiciona latência e pode expor dados sensíveis sem necessidade. Manter tudo localmente, porém, pode dificultar a colaboração, a governança e a escala centralizada. A direção do DuckDB 2.0 sugere um meio-termo prático: mover o processamento quando isso ajudar, não porque a arquitetura presume que ele precisa ser movido.

A própria descrição do projeto é excepcionalmente clara nesse ponto: o DuckDB pode rodar em qualquer lugar, de dispositivos de borda a servidores com centenas de núcleos, e trabalhar com arquivos locais ou armazenamento de objetos. A página da plataforma DuckDB apresenta essa portabilidade como uma propriedade central, não como algo acrescentado depois.

O recurso de nuvem mais importante é o que faz os dados remotos parecerem locais

A E/S assíncrona pode parecer menos atraente do que um novo protocolo ou um modo de CLI voltado para agentes, mas provavelmente é o recurso com o benefício prático mais claro para cargas de trabalho dependentes da nuvem. O DuckDB 2.0 separa as leituras remotas do processamento das consultas, permitindo que várias solicitações permaneçam em andamento enquanto a CPU trabalha com os dados que já estão disponíveis.

Esse mecanismo é voltado para arquivos Parquet e CSV em armazenamento de objetos, como o S3. Um relatório da MotherDuck descreve leituras de 2 a 3 vezes mais rápidas pelo S3 em seu cenário de teste, sem alterações nas consultas; esses números vieram de um único laptop e de uma conexão de internet doméstica, portanto devem ser tratados como um experimento indicativo, não como um benchmark universal. A análise da MotherDuck ainda ilustra o ponto maior: execução local não significa ignorar a nuvem. Pode significar usar a nuvem como armazenamento sem fazer um desvio analítico pesado.

É aqui que o modelo do DuckDB se torna convincente. Um data warehouse continua sendo útil quando muitos usuários precisam de análises compartilhadas, governadas e continuamente atualizadas. Mas, para um desenvolvedor explorando um conjunto de dados, um aplicativo gerando um relatório ou um sistema de borda filtrando eventos antes do upload, pagar o custo de um cluster remoto para cada pergunta parece cada vez mais excessivo. A unidade certa de otimização nem sempre é o data center. Às vezes, é a ida e volta dos dados.

VARIANT deixa a análise embutida mais confortável com dados desorganizados

Sistemas analíticos locais tradicionalmente são mais atraentes quando os dados já estão organizados. Aplicações reais são menos previsíveis. Logs evoluem, payloads de eventos mudam de formato e as equipes muitas vezes precisam consultar registros semiestruturados antes de alguém definir um esquema perfeito.

O tipo VARIANT do DuckDB 2.0 reduz esse atrito ao armazenar dados tipados e sem esquema, preservando a execução colunar. O mecanismo consegue detectar estruturas comuns e “desmembrá-las em colunas”, fazendo com que campos recorrentes sejam compactados e executados de maneira mais parecida com colunas comuns. É uma melhoria significativa em relação a tratar cada documento JSON como texto, especialmente no caso de logs e fluxos de eventos cuja estrutura é parcialmente estável e parcialmente imprevisível.

A ressalva é igualmente importante: isso não é mágica. Dados com tipos de valores inconsistentes não terão os mesmos benefícios que campos com formato consistente. O DuckDB está tornando a análise local flexível mais capaz, não eliminando a necessidade de modelar os dados. Isso é uma qualidade, não uma fraqueza. Boas ferramentas devem reduzir o custo de dados imperfeitos sem fingir que a qualidade dos dados deixou de importar.

O rótulo LTS importa porque ferramentas locais precisam durar

Software embutido é fácil de adotar e fácil de abandonar. Um desenvolvedor pode adicionar rapidamente uma biblioteca a um aplicativo, mas sistemas de produção precisam de manutenção previsível, caminhos de migração e estabilidade suficiente para justificar a construção de algo sobre esse componente.

Por isso, o status LTS do DuckDB 2.0 importa para além da data de suporte. O projeto afirma que a versão 2.0 terá suporte até pelo menos outubro de 2027, enquanto a linha 1.4 LTS anterior continuará sendo suportada até o fim de novembro de 2026, e o suporte ao DuckDB 1.5 foi estendido até março de 2027. Essa sobreposição dá às equipes espaço para testar, em vez de transformar uma atualização principal em uma emergência.

Há também um sinal estratégico aqui. O DuckDB está adicionando conectividade com servidores, observabilidade e comportamento de linha de comando favorável a agentes sem abrir mão de sua identidade como mecanismo embutido. O resultado não é um substituto para data warehouses na nuvem — e não deveria ser divulgado como tal. É uma maneira de tornar a análise mais modular: hoje dentro de um laptop, amanhã dentro de um aplicativo e conectada à infraestrutura centralizada quando a carga de trabalho realmente exigir isso.

Nosso veredito é direto: vale acompanhar o DuckDB 2.0 não porque ele torne a análise local universalmente superior, mas porque torna mais difícil descartar uma arquitetura dividida. As equipes devem manter data warehouses centralizados para escala compartilhada e governança, ao mesmo tempo que consideram seriamente o DuckDB para exploração, geração de relatórios embutidos, processamento na borda e análises sensíveis à privacidade. O futuro do processamento de dados provavelmente não será composto de clusters maiores em todos os lugares. Será de decisões melhores sobre onde cada consulta deve ser executada.