30 pontos por GN⁺ 2026-01-18 | 2 comentários | Compartilhar no WhatsApp
  • DuckDB é um motor SQL open source que processa dados tabulares em grande escala de forma rápida e simples em uma única máquina, e vem sendo amplamente usado recentemente em engenharia de dados
  • Tem instalação simples, não possui dependências e pode ser executado imediatamente em ambientes Python, sendo ideal para CI e automação de testes
  • Com otimização para consultas analíticas, pode entregar desempenho até 1.000 vezes superior ao SQLite ou Postgres, além de consultar diretamente diversos formatos de arquivo (csv, parquet, json)
  • Com sintaxe SQL amigável (EXCLUDE, COLUMNS, QUALIFY, encadeamento de funções etc.) e API Python, é possível desenvolver pipelines complexos com eficiência
  • Com conformidade ACID, UDFs de alto desempenho e extensão de integração com PostgreSQL, está emergindo como uma alternativa de lakehouse para dados de porte intermediário

Visão geral do DuckDB

  • DuckDB é um motor SQL in-process focado em otimização de consultas analíticas
    • Ele roda dentro da própria aplicação, sem servidor separado, e não exige um serviço externo como o Postgres
    • É especializado em operações intensivas de join e agregação em grande volume e pode oferecer desempenho 100 a 1.000 vezes superior ao de motores voltados a transações (OLTP)
  • Um dos principais casos de uso é o processamento em lote (batch processing), lendo diretamente do disco arquivos grandes como csv, parquet e json
  • Também pode ser usado para exploração leve de dados, como consultar rapidamente um arquivo CSV pela linha de comando

Principais características

  • Velocidade

    • DuckDB é um dos motores open source de processamento de dados mais rápidos, mantendo posição de destaque em benchmarks
    • Em comparação com Polars, DataFusion, Spark e Dask, o DuckDB se destaca em dados menores, enquanto Spark e Dask seguem competitivos em cargas maiores
  • Instalação simples e sem dependências

    • DuckDB é distribuído como um único binário pré-compilado e, em Python, pode ser instalado imediatamente com pip install duckdb
    • Por ser livre de dependências, sua instalação é muito mais simples do que a de frameworks maiores como o Spark
    • Em conjunto com uv, é possível montar um ambiente Python em menos de 1 segundo
  • CI e testes

    • Graças ao tempo de inicialização rápido e à leveza, é ideal para ambientes de CI e teste de pipelines de dados
    • No passado, testes baseados em Spark eram lentos e complexos; com o DuckDB, fica mais fácil simplificar a configuração do ambiente e manter consistência com produção
  • Experiência de escrita de SQL

    • DuckDB permite escrever SQL e validar sintaxe rapidamente
    • É mais vantajoso para execução imediata e desenvolvimento iterativo do que o modo local do Spark ou o AWS Athena
    • Oferece interface com autocompletar
  • Sintaxe SQL amigável

    • DuckDB inclui várias extensões SQL voltadas à usabilidade
      • Suporte a EXCLUDE, COLUMNS, QUALIFY, modificadores de agregação para funções de janela e encadeamento de funções (first_name.lower().trim())
    • Esses recursos permitem realizar seleção e transformação complexa de colunas de forma concisa
  • Suporte a diversos formatos de arquivo

    • É possível consultar dados diretamente de S3, URLs da web e arquivos locais
    • Oferece opções de rigor de tipos para CSV, evitando erros causados por dados de entrada não estruturados
  • API Python

    • Em Python, é possível definir pipelines baseados em CTE passo a passo e inspecionar facilmente os dados de cada etapa
      • Chamadas duckdb.sql() permitem encadear SQL em forma de pipeline
      • Com execução preguiçosa (lazy execution), é possível verificar resultados intermediários sem perda de desempenho
    • Como é possível testar funções de cada etapa, há ganho de eficiência nos testes de CI
  • Conformidade ACID

    • DuckDB oferece garantia ACID completa, mesmo em trabalhos com grande volume de dados
    • Por isso, pode ser usado como alternativa de porte intermediário a formatos de lakehouse como Iceberg e Delta Lake
  • UDFs de alto desempenho e extensões da comunidade

    • É possível escrever funções definidas pelo usuário (UDFs) de alto desempenho em C++
    • Por meio de Community Extensions, extensões podem ser instaladas imediatamente com comandos como INSTALL h3 FROM community
      • Ex.: suporte a indexação hexagonal (h3) para dados geoespaciais
  • Documentação

    • Toda a documentação é fornecida em um único arquivo Markdown, facilitando treinamento de LLMs e busca dentro do editor de código
    • Com recurso de code folding, fica fácil copiar apenas as partes necessárias

Uso prático e efeitos

  • No projeto open source Splink, a adoção do DuckDB como backend padrão trouxe
    • redução de problemas para os usuários, aumento da velocidade de trabalho e simplificação do desenvolvimento e dos testes

Extensões que merecem atenção

  • PostgreSQL Extension: permite conectar e consultar diretamente bancos de dados Postgres a partir do DuckDB
  • pg_duckdb: embute o motor DuckDB dentro do Postgres, permitindo processamento transacional e analítico em paralelo
    • No futuro, após melhorias em otimização de índices do Postgres e filter push-up, há potencial para ampla adoção

2 comentários

 
kaydash 2026-01-18

É irônico usar o Parq, feito para processamento distribuído, com o objetivo de processar em uma única máquina.

 
GN⁺ 2026-01-18
Comentários do Hacker News
  • Há vários motivos para eu gostar do DuckDB
    Ele oferece suporte a arquivos .parquet, .json e .csv, e permite leitura com glob como em select * from 'tsa20*.csv', então dá para tratar centenas de arquivos como se fossem um só
    Mesmo quando os esquemas são diferentes, é fácil combinar tudo com union_by_name, e o parser de CSV faz uma boa inferência automática de tipos
    A versão WebAssembly tem 2 MB, e o CLI tem 16 MB, então é extremamente compacto
    Isso permite embuti-lo diretamente no produto. Por exemplo, como no Malloy
    O Malloy é como uma versão para técnicos do PowerBI ou Tableau, mas usa um modelo semântico para ajudar a IA a escrever consultas melhores. Parece que deixa escrever SQL 10 vezes mais fácil

    • O suporte a CSV do DuckDB mudou completamente a forma como eu exploro dados
      Antes eu gastava tempo tentando entender o esquema primeiro, mas agora carrego os dados, escrevo consultas exploratórias, valido hipóteses e repito o ciclo de limpeza, transformação e criação de tabelas
      Isso me permite ir muito mais fundo e mais rápido, e também descobrir becos sem saída cedo, evitando desperdício de tempo
      Ouvi dizer que existe um artigo sobre como o parser de CSV funciona e ideias para melhorias futuras, mas ainda não consegui encontrá-lo
    • Tenho usado bastante ClickHouse ultimamente, e ele tem muitas vantagens parecidas com as do DuckDB
      Em especial, a ingestão de Parquet e JSON é conveniente, e o clickhouse-local é semelhante à ideia de embutir o DuckDB
      Com a sintaxe SELECT ... FROM s3Cluster(...), dá para fazer ingestão com wildcard a partir de buckets S3, distribuída entre os nós do cluster
      Parece que ele também oferece suporte a schema_inference_mode
      O ClickHouse também implementou um recurso semelhante ao union_by_name
      Documentação relacionada: função s3Cluster, schema inference, PR #55892
    • Eu criei o Shaper, que combina consulta de dados e visualização, numa ideia parecida com a do Malloy
      Mas o Shaper usa SQL em vez de uma linguagem separada
      Com base no DuckDB, ele permite criar dashboards só com SQL
      Shaper GitHub
    • Eu criei o ZenQuery e uso DuckDB internamente
      A velocidade é impressionante, e a detecção automática de esquema funciona corretamente na maior parte do tempo
      O LLM gera o SQL correto a partir de consultas em linguagem natural
    • Esta é realmente uma ótima introdução
      Eu fazia importação manual com SQLite, mas o DuckDB deixou tudo muito mais simples
  • Eu também sou alguém que usa DuckDB com frequência
    Trabalhando com cientistas que pesquisam o ambiente costeiro da Colúmbia Britânica, lidamos com volumes enormes de dados, de observações de geleiras a dados de drones de águas profundas
    Adotamos o DuckDB como motor de uma nova ferramenta de transformação de dados de biodiversidade, com o objetivo de converter e validar dados segundo o padrão Darwin Core
    Criamos tabelas DuckDB dinamicamente com base no esquema e importamos os dados. Quando falha, ele informa o motivo linha por linha
    Toda a transformação e validação também é feita dentro do DuckDB
    Com isso, criamos uma aplicação muito mais rápida, poderosa e capaz de rodar no navegador
    Pesquisadores de campo podem até usá-la offline no navegador do iPad
    Com o DuckDB, surge uma confiança de que o SQL faz o trabalho pesado
    Onde falta estabilidade de tipos, compensamos com parsing e testes
    O objetivo deste projeto é permitir que cientistas analisem dados de biodiversidade e genômica com uma ferramenta comum e os publiquem em repositórios públicos

    • Fiquei curioso sobre o formato dos datasets existentes
      Eu lido bastante com HDF5 em processamento de dados científicos, mas o DuckDB não oferece suporte nativo a HDF5
      A extensão existente é lenta e limitada, então criei uma nova extensão com templates em C++
      Estou procurando pessoas interessadas em colaborar
    • Fico curioso para saber quais seriam as vantagens de usar Polars para o mesmo trabalho
      Pessoalmente, acho a sintaxe do Polars muito mais confortável do que SQL, então estou pensando se vale a pena experimentar o DuckDB
  • Fazemos a análise e o processamento de feeds do Bluesky com DuckDB
    Para obter resultados rapidamente, usamos a interface Apache Arrow e geramos código diretamente a partir de consultas SQL do DuckDB com o SQG

    • Fiquei curioso sobre a stack técnica. Queria saber se existe algum texto sobre a arquitetura interna. A ferramenta de HN também impressiona
  • Quero apresentar o projeto Java manifold-sql
    Ele permite escrever DuckDB SQL inline com segurança de tipos
    Dá para colocar o SQL diretamente no código e iterar sobre os resultados com .fetch(), o que fica limpo e sem camada intermediária

  • O argumento do autor faz sentido para processamento básico de dados,
    mas a parte de que “a maior parte dos dados tabulares pode ser processada em uma única máquina” é discutível
    Ao escalar, fazer pivots ou enriquecer dados, logo pode acontecer estouro de memória (OOM)
    Além disso, a afirmação de que “SQL deveria ser a primeira escolha da nova engenharia de dados” também não se encaixa tão bem em análises complexas

    • O próprio autor aqui
      APIs de dataframe como Polars ou pandas também têm muitas vantagens, mas o problema é que o ecossistema não é padronizado, então muitas vezes é preciso reescrever pipelines
      A maioria dos dados fica abaixo de 10 GB, então uma única máquina costuma ser suficiente
      O Spark é usado em excesso em muitos casos
      Minha posição é: “tente primeiro com DuckDB”. Nos casos simples, ele é rápido e eficiente
    • Para análises avançadas, como ML ou visualização, dataframe é mais adequado
      Para pipelines simples, SQL é bom, mas legibilidade varia de pessoa para pessoa
      Eu acho o estilo dataframe muito mais fácil de ler
    • SQL continua sendo fácil de aprender, e a modelagem de dados ainda é feita majoritariamente com SQL
      Na parte de ingestão há muito Python e Scala, mas o SQL não vai desaparecer
    • Estou processando 500 GB de dados Parquet com DuckDB, e ele roda liso e rápido até num desktop com 50 GB de RAM
      OOM parece ser problema só em casos extremos
    • O Polars também tem quase todas essas vantagens e ainda oferece backend com GPU e distribuído
      Assim como o DuckDB vem recebendo atenção, o Polars também está sendo subestimado
  • Eu faço bastante processamento de dados, e uso principalmente Polars
    É muito rápido e tem muitas funções que, como no pandas, são difíceis de implementar em SQL
    Também dá para usar funções Python diretamente
    Mesmo que o DuckDB tenha desempenho parecido, fico receoso por causa das limitações de expressão do SQL

    • Na minha experiência, o DuckDB foi muito mais rápido e conciso
      Como é standalone, também é simples de instalar, e quase não exige tuning nem curva de aprendizado
  • Carreguei no DuckDB um arquivo Excel mal formatado gerado por mainframe,
    e com a opção all_varchar ele foi carregado em menos de 1 segundo
    O Excel ainda está abrindo o arquivo

  • O DuckDB é excelente, mas o carregamento dinâmico de extensões entra em conflito com code signing, o que dificulta o uso em apps comerciais
    Além disso, a extensão espacial usa componentes LGPL, o que traz questões de licenciamento
    Seria bom poder compor apenas os recursos necessários em nível de pacote, como no Apache Arrow
    Ex.: para transferir arrays via HTTP a GB/s, Arrow Flight; para compartilhamento de arquivos, Arrow IPC; para ler Parquet, adicionar um trait separado
    O sistema de tipos SQL do DuckDB é diferente do Arrow, então podem surgir problemas de incompatibilidade de tipos
    O Arrow fornece bibliotecas nativas para a maioria das linguagens

  • Gostaria de saber se é possível consultar rapidamente páginas filtradas por condição WHERE
    em uma única tabela com dezenas de bilhões de transações e 30 colunas
    No Postgres, até um simples count(*) demora bastante

    • Nessa escala, acho que no DuckDB isso também terminaria em poucos segundos
      Os únicos casos lentos que vi foram joins complexos ou processamento de glob em muitos arquivos
    • Para acelerar o count, talvez cache periódico seja melhor do que índice
      Se a condição WHERE for um par simples de coluna-valor, deve rodar bem rápido
  • O DuckDB não é apenas um banco rápido, ele também tem uma ótima experiência do desenvolvedor (devx)
    É fácil começar, então o ecossistema cresce rapidamente
    A integração com Web/WASM também impressiona
    Espero que apareçam mais motores pequenos como esse, para manter a competição e a inovação