DuckDB: o banco de dados que faz milhões de linhas parecerem uma planilha leve

Existe um momento em que a planilha deixa de ser uma ferramenta e vira um teste de paciência. O arquivo demora para abrir, o filtro congela a tela, o PROCV leva minutos para terminar e qualquer tentativa de salvar parece colocar o computador inteiro em pausa. Normalmente, a reação é procurar uma máquina mais potente ou dividir a base em vários arquivos. Só que o problema não é apenas o tamanho dos dados. É o tipo de ferramenta usada para trabalhar com eles.

É exatamente nesse espaço que o DuckDB se tornou uma das tecnologias mais interessantes do mundo dos dados. Ele é um banco de dados analítico, gratuito e de código aberto que roda dentro do seu computador, sem exigir servidor, cadastro ou uma infraestrutura complicada. Você baixa, aponta para um CSV ou Parquet e começa a consultar milhões de linhas com SQL. Em muitos casos, nem precisa importar o arquivo antes.

Este não é um texto para vender a ideia de que DuckDB resolve tudo. A proposta é entender de onde ele veio, como funciona, por que costuma ser tão rápido, onde realmente supera Excel e pandas, quais são seus limites e como usá-lo em tarefas reais como cruzar tabelas gigantes, substituir PROCV, consolidar arquivos e gerar uma saída que o Excel consiga abrir.

O que é DuckDB, em uma frase

DuckDB é um banco de dados SQL voltado para análise de dados que roda dentro do próprio aplicativo ou processo. A comparação mais conhecida é simples: se o SQLite é um banco embutido excelente para aplicações transacionais, o DuckDB tenta ocupar um papel semelhante para análises.

“Embutido” significa que você não precisa instalar e administrar um servidor separado. Não há um serviço de banco rodando em segundo plano, uma porta de rede para configurar ou um usuário de servidor para criar. Um banco persistente pode ser apenas um arquivo com extensão .duckdb. Também é possível trabalhar somente em memória ou consultar arquivos externos sem copiá-los para o banco.

Essa característica muda a experiência. Em vez de enviar uma planilha de dois gigabytes para algum serviço e esperar o upload, você pode processá-la localmente. Em vez de configurar PostgreSQL, permissões e conexões para uma análise que só uma pessoa fará, abre o DuckDB e consulta. O resultado é uma ferramenta pequena na forma, mas surpreendentemente séria no motor.

De onde veio o DuckDB

O projeto nasceu no CWI, o centro nacional de pesquisa em matemática e ciência da computação dos Países Baixos. Seus criadores, Mark Raasveldt e Hannes Mühleisen, trabalhavam com sistemas analíticos e perceberam uma lacuna: havia bancos poderosos para servidores e bibliotecas úteis para ciência de dados, mas faltava um mecanismo analítico moderno, simples de incorporar e fácil de distribuir.

O desenvolvimento começou na segunda metade da década de 2010 e o projeto ganhou sua primeira versão pública em 2019. A base acadêmica importa porque o DuckDB não começou como uma interface bonita em volta de uma tecnologia antiga. Seu motor foi construído com técnicas modernas de processamento de consultas, incluindo execução vetorizada, paralelismo e otimizações voltadas a cargas OLAP, sigla usada para consultas analíticas.

Hoje, o projeto é mantido como software de código aberto sob licença MIT, com governança ligada à DuckDB Foundation e desenvolvimento comercial apoiado pela DuckDB Labs. Para quem usa a ferramenta, o ponto principal é que o núcleo permanece aberto, pode rodar localmente e não depende de uma assinatura para funcionar. O site oficial é duckdb.org, e o código-fonte fica no repositório oficial do projeto.

OLTP e OLAP: por que essa diferença explica tudo

Bancos tradicionais usados em sistemas de cadastro são normalmente preparados para OLTP, processamento transacional. Pense em uma loja registrando pedidos: inserir uma venda, atualizar o estoque, consultar um cliente pelo identificador. São muitas operações pequenas e rápidas, feitas por vários usuários ao mesmo tempo.

DuckDB foi desenhado principalmente para OLAP. Nesse mundo, a pergunta costuma percorrer muitas linhas de uma vez: somar vendas por mês, cruzar dez milhões de registros, localizar divergências entre tabelas, calcular estatísticas ou filtrar um conjunto enorme. Em vez de alterar uma linha, o trabalho analítico lê blocos inteiros e executa operações pesadas sobre colunas.

Isso não quer dizer que o DuckDB seja incapaz de inserir ou atualizar dados. Ele oferece tabelas, transações ACID, índices e persistência. A diferença é a prioridade do projeto. Se sua aplicação precisa receber milhares de pequenas alterações simultâneas de muitos usuários pela rede, PostgreSQL ou outro banco cliente-servidor tende a fazer mais sentido. Se você precisa analisar grandes volumes perto de onde os dados já estão, DuckDB entra em seu território ideal.

Por que ele é tão rápido

A velocidade não vem de um truque único. Ela surge da combinação entre armazenamento colunar, execução vetorizada, paralelismo, otimização de consultas e leitura inteligente dos formatos externos.

Processamento por vetores

Em vez de processar cada célula isoladamente, o motor trabalha com blocos de valores. Esse modelo aproveita melhor o cache do processador e reduz o custo de interpretar a mesma operação repetidamente. É como carregar caixas inteiras em uma esteira, em vez de transportar cada produto com uma viagem separada.

Uso de várias threads

Quando a consulta permite, DuckDB divide o trabalho entre núcleos do processador. Agregações, leituras e junções podem aproveitar paralelismo sem que você tenha que programar threads manualmente. O ganho real depende dos dados, do disco, da consulta e do número de grupos disponíveis, então “usa todos os núcleos” não deve ser confundido com “toda consulta será instantânea”.

Otimização automática

Você escreve SQL declarando o resultado desejado, e o otimizador decide uma estratégia. Ele pode mudar a ordem das junções, empurrar filtros para perto da leitura, evitar colunas desnecessárias e escolher algoritmos adequados. Um SQL mal formulado ainda pode desperdiçar recursos, mas você não precisa construir manualmente o caminho completo da execução.

Leitura seletiva de Parquet

Parquet organiza dados por colunas e guarda metadados úteis. Se a consulta pede apenas codigo e valor, o DuckDB pode evitar a leitura de outras dezenas de colunas. Se existe um filtro, ele também pode pular grupos cujos valores mínimos e máximos provam que não contêm resultados. A documentação chama essas técnicas de projection pushdown e filter pushdown. É uma das razões pelas quais consultar Parquet costuma ser muito mais eficiente do que abrir um XLSX gigante.

DuckDB não é “um Excel mais rápido”

Excel e DuckDB não são substitutos diretos. Excel é uma interface de planilha: você vê células, edita manualmente, cria fórmulas, formata relatórios e monta gráficos. DuckDB é um motor de banco de dados: ele recebe consultas e devolve resultados. Não existe uma grade oficial do DuckDB tentando reproduzir a experiência completa do Excel.

O fluxo mais produtivo costuma combinar os dois. DuckDB faz o serviço pesado de leitura, limpeza, cruzamento e consolidação. Depois exporta um resultado menor para CSV ou XLSX, que o Excel abre para conferência visual, tabela dinâmica, formatação ou envio. A ideia não é abandonar a planilha, mas impedir que ela seja obrigada a fazer o trabalho de um banco analítico.

Há também uma diferença de limite. Uma planilha do Excel tem limite de 1.048.576 linhas por aba. DuckDB não adota esse limite de interface; a capacidade prática depende de disco, memória, tipos e complexidade da consulta. Isso permite trabalhar com dezenas ou centenas de milhões de registros, embora volume possível e desempenho aceitável sejam coisas diferentes.

DuckDB, SQLite, PostgreSQL e pandas

SQLite: também é embutido e usa um arquivo local, mas é tradicionalmente orientado a cargas transacionais. Para guardar dados de um aplicativo e buscar registros pontuais, continua excelente. Para varrer muitas linhas, agregar e cruzar grandes conjuntos, DuckDB foi desenhado com outra arquitetura.

PostgreSQL: é um servidor completo, maduro, multiusuário e ótimo para aplicações. Exige instalação, administração e uma conexão. DuckDB vence em simplicidade e portabilidade para análise local; PostgreSQL vence quando várias aplicações e usuários precisam consultar e alterar a mesma base continuamente.

pandas: é uma biblioteca Python extremamente útil, com um ecossistema enorme. O problema é que muitos fluxos carregam o conjunto inteiro em memória e criam cópias intermediárias. DuckDB consegue consultar arquivos diretamente e pode derramar parte do processamento para disco quando necessário. Não é uma guerra: DuckDB se integra ao pandas, Polars e Arrow. Você pode filtrar no DuckDB e entregar apenas o resultado relevante a um DataFrame.

Como instalar e começar

O projeto oferece uma linha de comando e bibliotecas para Python, R, Java, Node.js, C, C++, Go, Rust, WebAssembly e outros ambientes. O caminho correto depende de onde o fluxo será executado.

No Python, a instalação comum é:

python -m pip install duckdb

Depois, um banco persistente pode ser aberto assim:

import duckdb

con = duckdb.connect("tnumm.duckdb")
resultado = con.sql("SELECT 42 AS resposta").fetchall()
print(resultado)

Na CLI, você pode abrir o arquivo diretamente e escrever SQL no terminal. A página de instalação oficial mostra as opções atualizadas para cada sistema. Em projetos reais, vale registrar a versão da dependência, porque formatos internos, extensões e comportamento podem evoluir.

Consultar CSV sem importar

Uma das experiências mais convincentes do DuckDB é executar SQL diretamente sobre um arquivo:

SELECT codigo, descricao, valor
FROM read_csv_auto('material.csv')
WHERE valor > 1000
ORDER BY valor DESC;

O leitor tenta detectar delimitador, cabeçalho e tipos. Isso funciona muito bem em arquivos regulares, mas CSV do mundo real pode misturar codificações, datas, aspas, quebras de linha e números brasileiros. Para bases críticas, não dependa cegamente da inferência. Defina os tipos das colunas importantes e valide uma amostra.

Um código como 00214647 não deve ser interpretado como número se os zeros fazem parte da identidade. A coluna precisa ser texto. Um valor como 1.234,56 também não deve cair diretamente em um tipo numérico sem normalização, pois ponto e vírgula têm significados diferentes conforme a localidade.

SELECT
    codigo::VARCHAR AS codigo,
    TRY_CAST(
        REPLACE(REPLACE(valor_texto, '.', ''), ',', '.')
        AS DECIMAL(18, 2)
    ) AS valor
FROM read_csv(
    'material.csv',
    delim = ';',
    header = true,
    columns = {'codigo': 'VARCHAR', 'valor_texto': 'VARCHAR'}
);

O DECIMAL(18,2) é importante em valores monetários porque trabalha com precisão decimal definida. Usar FLOAT ou DOUBLE pode introduzir pequenas diferenças binárias que são normais em ponto flutuante, mas ruins quando um centavo precisa ser comparado exatamente.

Parquet: o formato que combina com DuckDB

CSV é universal, mas não guarda tipos, repete texto e precisa ser interpretado linha por linha. XLSX é ótimo para entrega humana, mas é um pacote XML comprimido, com estilos e várias estruturas que tornam sua leitura mais cara. Parquet é colunar, comprimido e inclui esquema e estatísticas. Para manter grandes bases de consulta, quase sempre é a escolha mais eficiente entre os três.

Converter um CSV para Parquet exige uma linha:

COPY (
    SELECT * FROM read_csv_auto('material.csv')
) TO 'material.parquet'
(FORMAT PARQUET, COMPRESSION ZSTD);

Depois, a consulta pode ser feita sem criar uma tabela:

SELECT codigo, valor
FROM 'material.parquet'
WHERE codigo = '00214647';

Também é possível consultar vários arquivos com um padrão:

SELECT *
FROM read_parquet('bases/material_*.parquet', union_by_name = true);

O parâmetro union_by_name ajuda quando os arquivos têm colunas em ordens diferentes ou quando uma coluna não existe em todos. Ele une pelo nome e preenche ausências com NULL. Isso é útil, mas não corrige divergências semânticas. Se “valor” significa preço unitário em um arquivo e total em outro, o nome igual não torna as colunas equivalentes.

A documentação de Parquet explica leitura, escrita e pushdown. Para desempenho, a orientação oficial evita tanto milhares de arquivos minúsculos quanto arquivos gigantescos difíceis de paralelizar; organização, tamanho e row groups influenciam diretamente o resultado.

Como substituir o PROCV por JOIN

PROCV procura uma chave em uma tabela e retorna um valor associado. Em SQL, a operação equivalente normalmente é um JOIN. A diferença é que o SQL obriga você a pensar na cardinalidade: uma chave existe uma vez ou várias? Essa pergunta evita muitos resultados silenciosamente errados.

Imagine uma tabela de serviços e uma tabela de conversão de códigos:

SELECT
    s.codigo_uv,
    s.descricao,
    c.codigo_tuss
FROM 'servicos.parquet' AS s
LEFT JOIN 'conversao.parquet' AS c
    ON s.codigo_uv = c.codigo_uv;

O LEFT JOIN mantém todos os serviços. Quando não há correspondência, o código retornado fica nulo. Isso é importante em auditoria, porque um registro sem match não deve simplesmente desaparecer.

Se a tabela de conversão tem mais de um código para a mesma chave, o resultado repete a linha do serviço. Não é bug: é a representação correta de uma relação um-para-muitos. Antes de “remover duplicados”, investigue se há vigências diferentes, códigos alternativos ou inconsistências.

Para escolher uma referência por regra explícita, use função de janela:

WITH conversao_ordenada AS (
    SELECT *,
        ROW_NUMBER() OVER (
            PARTITION BY codigo_uv
            ORDER BY data_inicio_vigencia ASC
        ) AS ordem
    FROM 'conversao.parquet'
)
SELECT
    s.*,
    c.codigo_tuss,
    c.data_inicio_vigencia
FROM 'servicos.parquet' AS s
LEFT JOIN conversao_ordenada AS c
    ON s.codigo_uv = c.codigo_uv
   AND c.ordem = 1;

Aqui a data mais antiga foi escolhida de propósito. Em um processo sério, os demais registros não deveriam ser apagados; o ideal é exportá-los para uma aba ou arquivo de revisão. SQL facilita separar “resultado principal” de “inconsistências” sem destruir a origem.

Comparando duas bases gigantes

Um caso frequente é descobrir registros novos, removidos e alterados. Para isso, um FULL OUTER JOIN dá uma visão completa:

SELECT
    COALESCE(a.codigo, b.codigo) AS codigo,
    a.valor AS valor_anterior,
    b.valor AS valor_atual,
    CASE
        WHEN a.codigo IS NULL THEN 'ADICIONADO'
        WHEN b.codigo IS NULL THEN 'REMOVIDO'
        WHEN a.valor IS DISTINCT FROM b.valor THEN 'ALTERADO'
        ELSE 'IGUAL'
    END AS status
FROM 'base_anterior.parquet' AS a
FULL OUTER JOIN 'base_atual.parquet' AS b
    ON a.codigo = b.codigo;

IS DISTINCT FROM é preferível à comparação simples quando existem nulos, porque trata NULL de forma previsível. Mas existe uma condição: a chave deve estar controlada. Se codigo aparece três vezes em uma base e quatro na outra, a junção pode produzir uma multiplicação de linhas. Antes de comparar, rode uma auditoria:

SELECT codigo, COUNT(*) AS quantidade
FROM 'base_atual.parquet'
GROUP BY codigo
HAVING COUNT(*) > 1
ORDER BY quantidade DESC;

Esse é um dos maiores ganhos sobre o PROCV: em vez de retornar a primeira ocorrência e esconder a complexidade, o banco permite medir a qualidade da chave e registrar exceções.

Como lidar com arquivos Excel

DuckDB possui um ecossistema de extensões e suporte a formatos que evolui rapidamente, mas Excel merece cuidado. Dependendo da versão e do ambiente, uma extensão pode ler XLSX; em outros fluxos, Python com openpyxl, pandas ou outra biblioteca faz a leitura e entrega uma tabela ao DuckDB. A decisão deve considerar fórmulas, abas, células mescladas, tipos mistos e estilos.

Para planilhas simples, o objetivo costuma ser extrair os valores e convertê-los uma vez para Parquet. Para pastas com centenas de arquivos, vale criar uma etapa de ingestão que registre: arquivo de origem, aba, data da importação, quantidade de linhas, colunas detectadas e erros. Assim, a velocidade não vem à custa de rastreabilidade.

Na saída, CSV preserva cabeçalhos e suporta qualquer volume, mas não guarda formatação nem múltiplas abas. XLSX é mais amigável para usuários, porém volta a ter o limite de linhas por aba. Se o resultado ultrapassa esse limite, exporte em partes, crie arquivos separados ou entregue o conjunto completo em Parquet e um resumo em Excel.

Exportando resultados

O comando COPY exporta uma consulta diretamente:

COPY (
    SELECT codigo, descricao, valor
    FROM resultado
    ORDER BY codigo
) TO 'resultado.csv'
(HEADER, DELIMITER ';');

Para valores monetários em um CSV destinado ao Excel brasileiro, há duas estratégias. A melhor para intercâmbio técnico é manter o valor como número em formato padronizado e configurar a importação. A alternativa para entrega humana é formatar com vírgula, sabendo que a coluna passa a ser texto. Misturar as duas coisas é receita para comparações erradas.

Uma arquitetura robusta mantém os dados internos em tipos corretos, especialmente DECIMAL e DATE, e aplica a apresentação brasileira apenas na exportação. O banco guarda 1234.56 como valor decimal; o arquivo final pode mostrar 1234,56, sem ponto de milhar, se essa for a convenção do processo.

Consultas maiores do que a memória

DuckDB consegue executar várias operações maiores que a RAM usando o disco para dados temporários. Isso não significa memória infinita. Algumas consultas geram resultados intermediários enormes, e o espaço disponível no disco se torna parte do limite.

É possível definir memória e pasta temporária:

SET memory_limit = '4GB';
SET temp_directory = 'D:/duckdb_temp';

Em máquinas com SSD, o comportamento costuma ser muito melhor do que em disco mecânico. Ainda assim, a primeira otimização não deve ser aumentar recursos, e sim reduzir dados cedo: selecione apenas as colunas necessárias, aplique filtros antes de junções, evite SELECT * em produção e confira se uma chave duplicada está multiplicando o resultado.

Privacidade e segurança

Por rodar localmente, DuckDB pode processar dados sem enviá-los a um servidor externo. Isso é uma vantagem para bases sensíveis, mas “local” não é sinônimo de “seguro automaticamente”. O arquivo .duckdb, os Parquets, os CSVs exportados e a pasta temporária continuam existindo no dispositivo e herdam a segurança do sistema operacional.

Em ambiente profissional, aplique controles de acesso, criptografia de disco, backup, limpeza de temporários e política de retenção. Não coloque senhas diretamente em scripts. Extensões podem acessar serviços remotos quando você pede, e consultas sobre URLs obviamente usam rede. Também é importante instalar extensões apenas de fontes confiáveis e manter as dependências atualizadas.

Para Parquet, o DuckDB possui suporte a criptografia modular com limitações documentadas. Antes de adotar isso como controle corporativo, consulte a documentação oficial de criptografia e teste compatibilidade com as outras ferramentas do fluxo.

Concorrência: o limite que você precisa conhecer

DuckDB funciona muito bem com múltiplas threads dentro de um processo e permite certas operações concorrentes. Mas ele não foi desenhado como substituto direto de um servidor multiusuário que recebe gravações de muitos processos independentes no mesmo arquivo durante todo o dia.

Uma aplicação desktop em que um usuário importa, consulta e exporta é um cenário natural. Um serviço web em que centenas de pessoas tentam alterar o mesmo banco exige outra arquitetura. É possível usar DuckDB como motor analítico por trás do serviço, trabalhar com cópias, formatos compartilhados ou camadas adicionais, mas o desenho precisa ser intencional. A página oficial de concorrência deve ser lida antes de colocar múltiplos escritores sobre o mesmo arquivo.

Erros comuns de quem começa

• Transformar códigos em números: zeros à esquerda desaparecem e chaves deixam de casar. Identificadores devem ser texto
• Usar ponto flutuante para dinheiro: escolha DECIMAL e uma regra clara de normalização
• Confiar em tipos inferidos sem validar: uma amostra pode não conter o valor problemático que aparece no fim do arquivo
• Fazer JOIN sem medir duplicidade: relações muitos-para-muitos podem explodir a quantidade de linhas
• Usar SELECT * em tudo: ler colunas desnecessárias desperdiça memória e I/O
• Criar milhares de Parquets minúsculos: o custo de abrir e inspecionar arquivos pode dominar a consulta
• Tratar resultado vazio como sucesso: zero correspondências pode significar tipos diferentes, espaços, acentos ou regra errada
• Sobrescrever a base original: ingestão e transformação devem preservar a fonte e gerar novas versões rastreáveis

Um fluxo profissional para planilhas gigantes

Um software leve baseado em DuckDB pode organizar o processo em camadas. Primeiro, recebe XLSX, CSV ou outros formatos. Depois, detecta abas e colunas, pede confirmação para campos sensíveis e converte os dados para Parquet. Em seguida, registra cada conjunto em um catálogo lateral sem modificar os arquivos originais.

Quando o usuário escolhe tabelas para sobrepor, o sistema gera uma nova visão ou arquivo, mantendo as fontes. Para uma busca equivalente ao PROCV, ele permite selecionar chave de origem, chave de destino e colunas de retorno. Antes de executar, mostra qualidade do relacionamento: chaves únicas, duplicadas, sem correspondência e muitos-para-muitos.

Ao final, exporta CSV ou XLSX com os cabeçalhos preservados. Se o resultado não cabe em uma aba, a interface avisa e divide com regra previsível. Operações demoradas rodam em segundo plano, exibem progresso e podem ser canceladas sem corromper a base.

Esse desenho usa DuckDB onde ele é melhor, como motor analítico, e deixa a interface cuidar do que SQL puro não oferece: seleção visual, histórico, validação, explicações e segurança contra cliques destrutivos.

Quando DuckDB é a escolha certa

Ele é especialmente forte para análise local, exploração de CSV e Parquet, ETL leve, ciência de dados, testes, notebooks, aplicações desktop, geração de relatórios e preparação de dados antes de outro sistema. Também é ótimo quando você precisa distribuir uma ferramenta que funcione sem instalar e administrar um servidor.

Não é a escolha automática para sistemas transacionais de alta concorrência, aplicações que dependem de controle de acesso centralizado para muitos usuários, bancos que precisam ficar disponíveis pela rede o tempo todo ou cenários em que a principal carga é atualizar registros individuais continuamente.

A pergunta correta não é “DuckDB é melhor que PostgreSQL, Excel ou pandas?”. A pergunta é “qual parte do meu fluxo precisa de um motor analítico local?”. Muitas vezes, a resposta é usar DuckDB junto com essas ferramentas.

Perguntas rápidas

DuckDB é gratuito? Sim. O núcleo é aberto sob licença MIT. Serviços e produtos de terceiros podem ter seus próprios preços, mas o banco local não exige assinatura.

Preciso saber SQL? Para aproveitar bem, algum SQL ajuda muito. O básico de SELECT, WHERE, GROUP BY e JOIN já resolve uma quantidade enorme de tarefas.

Ele abre arquivos maiores que a memória? Frequentemente, sim. O motor pode ler em fluxo e usar disco temporário em diversas operações. A consulta, o formato e o espaço em disco continuam determinando o limite prático.

Posso usar no Windows? Sim. Há CLI e bibliotecas para vários ambientes, inclusive Python. Também funciona em macOS e Linux.

Preciso importar todo Parquet para o banco? Não. Você pode consultá-lo diretamente e criar uma tabela apenas se isso trouxer vantagem para o fluxo.

DuckDB substitui Power BI? Não diretamente. Power BI é uma plataforma de modelagem e visualização. DuckDB pode preparar e consultar dados usados em relatórios, mas não oferece a mesma camada de dashboards.

É seguro usar dados de trabalho? O processamento local reduz exposição, mas a autorização depende das políticas da organização. Proteja arquivos, temporários, backups, credenciais e exportações.

Conclusão: o banco que cabe entre a planilha e o servidor

O maior mérito do DuckDB não é vencer benchmarks. É reduzir a distância entre ter um arquivo enorme e conseguir fazer uma pergunta útil sobre ele. Você não precisa montar um servidor, criar uma infraestrutura ou carregar tudo em uma planilha. Abre o banco, aponta para os dados e usa SQL.

Para quem trabalha com tabelas gigantes, a combinação DuckDB mais Parquet é especialmente poderosa. Ela troca fórmulas frágeis por consultas reproduzíveis, transforma PROCV em relações explícitas, preserva as fontes e permite gerar resultados muito além do limite de uma aba do Excel.

Mas a ferramenta recompensa disciplina. Códigos precisam permanecer como texto, dinheiro precisa de decimal exato, duplicidades precisam ser investigadas e o modelo de concorrência precisa ser respeitado. DuckDB é rápido, não mágico. Quando os dados são bem tratados e a arquitetura combina com o problema, ele entrega uma sensação rara em projetos de dados: a de que milhões de linhas finalmente deixaram de mandar no seu computador.

Para continuar, consulte a documentação oficial do DuckDB, o guia de exemplos e a seção de boas práticas de desempenho. O melhor primeiro teste é simples: pegue um CSV que hoje incomoda, rode uma consulta pequena e compare o fluxo inteiro, não apenas o cronômetro.