O que é o DuckDB 2.0

O DuckDB é um banco de dados relacional analítico que roda dentro do processo da aplicação. Em vez de exigir um servidor separado, ele pode ser instalado como biblioteca Python, executável de terminal ou cliente para outras linguagens.

A proposta é especialmente útil para consultas OLAP, relatórios e preparação de dados. O motor usa armazenamento colunar e execução vetorizada para processar lotes de valores, um desenho adequado para agregações e leituras analíticas.

O projeto foi criado por Mark Raasveldt e Hannes Mühleisen no CWI, em Amsterdã, e apareceu como trabalho académico em 2019. A prévia do DuckDB 2.0 está em evidência porque o projeto prepara uma nova etapa de uso compartilhado, enquanto o protocolo Quack ainda está em beta na série 1.5.

Como funciona

Em uma aplicação tradicional, o código envia uma consulta pela rede para um banco de dados que vive em outro processo. Com o DuckDB, o motor pode ser carregado pela própria aplicação e executar o SQL no mesmo processo que já possui os dados ou coordena o trabalho.

O processamento é vetorizado. Em vez de tratar uma linha por vez, o mecanismo trabalha com blocos de valores chamados vetores ou chunks. A documentação técnica descreve um tamanho padrão de 2048 tuplas para esses lotes, o que ajuda a reduzir chamadas repetitivas e aproveitar melhor o processador.

O banco também consegue ler arquivos diretamente. Uma consulta pode apontar para CSV, Parquet ou JSON sem exigir uma etapa manual de importação. Para dados persistentes, o DuckDB salva tabelas, visões e outros objetos em um arquivo próprio, mas também pode trabalhar apenas em memória.

Principais recursos

O diferencial mais visível é a combinação de SQL familiar com uma instalação pequena. Isso deixa o fluxo curto para quem precisa explorar dados antes de montar uma infraestrutura maior.

  • Leitura direta de arquivos: consulte CSV, Parquet e JSON usando SQL ou as funções da API Python.
  • Banco embutido: execute análises dentro de scripts, notebooks, aplicações desktop e serviços locais.
  • Armazenamento persistente: use um único arquivo de banco quando o resultado precisar sobreviver ao encerramento do processo.
  • Clientes nativos: há APIs para Python, R, Go, Java, Node.js, Rust, C, C++ e outras plataformas.
  • Extensões: recursos para formatos, serviços e funções adicionais podem ser instalados e carregados quando necessário.

A prévia do 2.0 deve ser tratada como uma oportunidade de acompanhar a evolução do projeto, não como garantia de que toda funcionalidade futura já está pronta para produção. A própria documentação recomenda verificar a versão em uso e separar testes de ambientes críticos.

Como começar: instalação e acesso passo a passo

Para experimentar o cliente Python de pré-lançamento, use um ambiente virtual isolado. A opção --pre permite instalar a versão de preview publicada no índice de pacotes, mas o resultado pode mudar antes de uma versão estável.

Python -m venv .venv
.venv\Scripts\activate
Python -m pip install --upgrade duckdb --pre

Depois, abra um interpretador Python e confirme a versão carregada. A consulta PRAGMA version é útil quando mais de um cliente DuckDB está instalado na mesma máquina.

import duckdb

print(duckdb.sql('PRAGMA version').fetchall())
print(duckdb.sql('SELECT 42 AS resposta').fetchall())

Se preferir o terminal, baixe o CLI na página oficial de instalação. O executável pode abrir um banco persistente ou uma sessão temporária em memória, sem precisar configurar um serviço de rede.

Exemplo prático

Imagine uma pasta com arquivos Parquet de eventos de uma aplicação. O objetivo é descobrir quais caminhos receberam mais acessos, agrupando todos os arquivos com uma única consulta.

import duckdb

con = duckdb.connect('análise.duckdb')

resultado = con.execute('''
    SELECT
        rota,
        count(*) AS acessos
    FROM read_parquet('dados/eventos-*.parquet')
    GROUP BY rota
    ORDER BY acessos DESC
    LIMIT 10
''').fetchall()

for rota, acessos in resultado:
    print(rota, acessos)

con.close()

Nesse fluxo, os arquivos continuam sendo a origem dos dados. O DuckDB lê o padrão de arquivos, aplica o filtro e calcula a agregação sem exigir que você crie uma tabela intermediária apenas para começar a análise.

Se a consulta for repetida, o arquivo análise.duckdb pode guardar tabelas derivadas, visões e resultados persistentes. Para uma análise única, também é possível usar uma conexão em memória e descartar tudo ao fechar o processo.

Comparação com alternativas

SQLite continua sendo uma excelente escolha para dados transacionais de aplicações pequenas. O DuckDB faz mais sentido quando o trabalho principal envolve leitura analítica, agregações, arquivos colunares e exploração de dados.

PostgreSQL é mais apropriado quando muitos usuários e serviços precisam compartilhar um banco central com transações, permissões e escrita concorrente. O DuckDB pode complementar esse ambiente como camada local de análise, sem substituir automaticamente o banco operacional.

Polars e Pandas são ótimos para manipulação em dataframes. O DuckDB se destaca quando a equipe prefere expressar transformações com SQL, ler vários arquivos e deixar o otimizador montar o plano de execução.

Apache Spark atende cenários distribuídos que precisam dividir o trabalho entre vários nós. Para uma análise local ou um pipeline executado em uma única máquina, o DuckDB tende a exigir menos componentes e menos operação.

Pontos positivos e limitações

O ponto forte é a simplicidade operacional. Um desenvolvedor pode instalar a biblioteca, apontar uma consulta para os arquivos e obter um resultado sem provisionar um cluster, criar usuário ou manter um serviço sempre ligado.

A portabilidade também pesa. O mesmo conceito pode aparecer em um notebook, em um job de CI, em uma ferramenta desktop ou em um serviço que prepara dados para um relatório. A licença MIT do núcleo facilita o uso em projetos abertos e comerciais.

Há limites importantes. O modo embutido é de processo único para leitura e escrita, e escritas concorrentes na mesma linha podem gerar conflito. Para múltiplos processos, o Quack está em beta, enquanto o formato DuckLake com catálogo PostgreSQL é uma alternativa voltada a compartilhamento mais estruturado.

⚠️
Atenção

Não transforme um arquivo DuckDB local em banco central de produção apenas porque a primeira consulta foi rápida. Avalie concorrência, backup, permissões e o perfil transacional da aplicação.

Casos de uso reais

Para quem trabalha com engenharia de dados, o DuckDB é útil como etapa local de exploração. Você pode validar um conjunto de Parquet, conferir tipos e testar uma transformação antes de levá-la para um pipeline maior.

Para equipes de produto, ele funciona bem em relatórios internos e scripts de diagnóstico. Um job pode consolidar exportações da aplicação, calcular métricas e gerar um arquivo de saída sem depender de um servidor dedicado.

Para estudantes e desenvolvedores independentes, a curva inicial é curta. É possível aprender SQL analítico usando arquivos reais, com baixo custo de infraestrutura e sem precisar começar administrando um banco remoto.

Para aplicações que precisam analisar dados no dispositivo, o modelo embutido também é interessante. Uma ferramenta desktop ou um serviço local pode consultar dados próximos do usuário e sincronizar apenas os resultados necessários, desde que o desenho de segurança seja adequado.

Dicas e boas práticas

Comece com conexões explícitas quando o código crescer. A API global é prática para exemplos rápidos, mas uma conexão própria deixa o ciclo de vida, a persistência e o uso em threads mais claros.

💡
Dica

Use duckdb.connect com um nome de arquivo para análises que precisam ser retomadas. Use memória apenas quando perder os dados ao final do processo for aceitável.

Prefira consultas parametrizadas ao montar filtros com valores recebidos de usuários. A documentação de segurança do DuckDB trata SQL não confiável como código e recomenda as mesmas precauções adotadas em outras bases.

🔴
Cuidado

Não execute SQL vindo de uma fonte não confiável sem isolamento. DuckDB pode ler arquivos, acessar a rede e carregar extensões, então uma consulta pode ter efeitos bem maiores do que apenas retornar linhas.

Em código paralelo, não compartilhe a conexão global entre threads. Crie uma conexão por thread ou organize o acesso em um único ponto, e use modo somente leitura quando vários processos precisarem consultar o mesmo arquivo.

🚀
Pro tip

Registre a versão com PRAGMA version nos jobs de dados. Isso facilita reproduzir resultados quando uma prévia muda o planejador ou uma extensão.

Vale a pena?

Para desenvolvedores brasileiros que precisam analisar CSV, Parquet ou JSON sem montar uma plataforma inteira, o DuckDB vale muito o teste. A combinação de SQL, portabilidade e instalação simples resolve uma classe real de problemas locais.

A prévia do DuckDB 2.0 merece atenção de quem acompanha arquitetura analítica e colaboração em dados. Ainda assim, preview não é sinônimo de estabilidade: valide o comportamento com seus arquivos e não misture a versão de teste com dados de produção sem plano de retorno.

O próximo passo é pequeno. Separe uma exportação não sensível, instale o cliente em um ambiente virtual, rode uma agregação e compare o resultado com a ferramenta que você já usa. Se a experiência fizer sentido, documente a versão e transforme o experimento em um teste automatizado.