Você tem uma pasta de arquivos Parquet, precisa limpar colunas, cruzar tabelas e entregar uma base para avaliação ou treinamento de IA. A escolha entre DuckDB e Polars costuma aparecer como uma disputa de velocidade. Essa é uma pergunta incompleta. Em muitos projetos, a diferença decisiva é como a equipe quer expressar, revisar e guardar a transformação.
DuckDB é um banco analítico incorporado ao processo, com SQL e possibilidade de consultar arquivos diretamente. Polars é uma biblioteca de DataFrames, com expressões e execução lazy para compor pipelines. Os dois podem ler Parquet, otimizar leituras e trabalhar juntos. Por isso, não existe vencedor universal e este artigo não apresenta benchmark próprio. A comparação foi conferida nas documentações oficiais em 22 de setembro de 2026.
Veredito rápido
Comece por DuckDB se a equipe já pensa em consultas SQL, precisa unir fontes tabulares e quer uma camada analítica consultável, inclusive um arquivo de banco persistente quando isso fizer sentido. Comece por Polars se a transformação faz parte de uma aplicação Python ou Rust, a equipe prefere expressões tipadas e quer encadear operações em um LazyFrame. Use ambos quando a consulta SQL resolve uma parte do problema e a manipulação programática resolve outra, desde que a fronteira entre as duas seja medida e testada.
Essa orientação é uma análise editorial, não uma afirmação de que uma ferramenta é sempre mais rápida. A documentação do próprio Polars descreve DuckDB como um banco SQL analítico no processo e Polars como uma interface DataFrame; a comparação oficial do Polars também reconhece a interoperabilidade entre eles.
Comparação direta
| Critério | DuckDB | Polars | Pergunta para decidir |
|---|---|---|---|
| Interface principal | SQL e API relacional | Expressões sobre DataFrame e LazyFrame | Quem manterá o pipeline entende melhor consultas ou código de transformação? |
| Unidade de trabalho | Consulta, relação, tabela ou arquivo de banco | DataFrame e plano lazy | Você precisa de uma base consultável ou de uma etapa dentro da aplicação? |
| Parquet | Consulta arquivos com read_parquet, inclusive padrões de arquivos |
Usa scan_parquet para montar um plano antes de coletar |
Onde filtros e seleção de colunas devem acontecer? |
| Persistência | Pode usar um banco em arquivo, além de consultar arquivos externos | Materializa resultados em formatos como Parquet quando solicitado | Há necessidade de catálogo e tabelas locais ou só de artefatos de saída? |
| Integração | Pode ler DataFrames Polars e devolver resultados como Polars | Pode receber dados de DuckDB e continuar a transformação | A conversão melhora o fluxo ou adiciona uma fronteira desnecessária? |
A tabela resume modelos de uso, não limites absolutos. DuckDB também tem API Python e Polars dispõe de contexto SQL, portanto seria enganoso afirmar que um só aceita SQL e o outro proíbe SQL. O ponto é qual abstração fica no centro do projeto e como o time inspeciona o plano e os resultados.
O que muda ao preparar dados para IA
Projetos de IA lidam com dados imperfeitos antes de lidar com modelos: registros duplicados, campos ausentes, esquemas alterados, datas mal interpretadas e relações entre fontes. Um pipeline que monta o conjunto de avaliação precisa guardar a origem, a regra de filtragem e o critério de exclusão. Nenhuma biblioteca resolve isso por escolha de marca. A decisão técnica deve tornar essas regras legíveis e testáveis para outra pessoa.
Se um analista já tem uma consulta SQL revisada pelo time, DuckDB pode permitir que ela seja aplicada diretamente a arquivos Parquet. Se a mesma transformação integra um serviço Python e exige ramificações, validações ou funções programáticas, Polars pode encaixar melhor. Em ambos os casos, documente as colunas de entrada, a saída esperada e os registros que não deveriam passar. O que chega ao modelo depende mais dessas escolhas que do nome do motor.
DuckDB: SQL, arquivos e banco incorporado
O manual de Parquet do DuckDB mostra consultas com read_parquet, leitura de múltiplos arquivos e aplicação de filtros e seleção de colunas no scan. Isso atende bem uma pergunta como “quais registros passaram por duas fontes e cumpriram estes critérios?”. O SQL torna a consulta auditável por profissionais que não precisam conhecer a API de DataFrames do projeto.
DuckDB não exige que todo Parquet seja importado para uma tabela persistida. Também pode manter dados em um arquivo de banco quando a equipe quer um estado local consultável entre execuções, conforme a documentação da API Python. É uma escolha de arquitetura, não uma obrigação. Uma consulta direta sobre arquivos pode ser suficiente para um relatório reproduzível; uma tabela persistida pode facilitar reutilização, mas traz responsabilidade por atualização, backup e acesso.
Um cuidado frequente é assumir que todo CSV tem tipos corretos porque a primeira amostra passou. O leitor de CSV infere formato, mas dados de produção podem conter exceções. Confira tipos, valores nulos, linhas rejeitadas e critérios de conversão antes de alimentar um conjunto de treino ou avaliação.
Polars: expressões e execução lazy
Polars permite escrever transformações como expressões sobre colunas. Na API lazy oficial, um plano é definido primeiro e executado ao chamar collect(). O otimizador pode antecipar filtros e selecionar apenas as colunas necessárias. A documentação recomenda esse caminho em muitos casos, embora a API eager continue útil para exploração e inspeção de resultados intermediários.
Para arquivos Parquet, scan_parquet devolve um LazyFrame. Isso é diferente de carregar tudo imediatamente com read_parquet. O encadeamento de filter, select e group_by costuma deixar explícita a transformação no código da aplicação. É importante, contudo, saber em que ponto o resultado será materializado e qual será o consumo de memória naquele caso concreto.
A lista de otimizações inclui pushdown de predicados e de projeção. Isso não autoriza prometer que qualquer pipeline caberá na memória ou que todo operador será executado em streaming. Verifique o plano e teste com dados representativos, inclusive casos de esquema irregular.
Como inspecionar um plano antes de confiar nele
Uma diferença prática de manutenção é onde procurar explicação quando o resultado muda. Em Polars, explain() permite examinar o plano de uma consulta lazy, segundo o guia oficial. Em DuckDB, o caminho é inspecionar a consulta SQL e seu plano de execução, descrito na documentação do EXPLAIN. Nenhum plano substitui o teste do resultado, mas ajuda a localizar leitura excessiva, junções inadequadas e filtros aplicados tarde demais.
Para uma comparação justa, rode a mesma regra de negócio sobre a mesma cópia de dados, com o mesmo tratamento de nulos e datas. Compare contagem de linhas, tipos, agregados e amostras de erros. Só depois avalie tempo, memória e complexidade de manutenção. Publicar um número isolado sem dados, máquina, versão e metodologia seria apenas criar uma falsa certeza; este comparativo não faz isso.
Persistir ou transformar: uma decisão de arquitetura
DuckDB pode guardar tabelas em um arquivo de banco. Isso é útil quando várias análises precisam consultar o mesmo conjunto local, mas também exige uma política de atualização e integridade. Polars pode produzir um Parquet ou outro artefato ao final do pipeline e deixar a persistência para o sistema ao redor. As duas abordagens podem coexistir. A questão é quem declara a versão válida do conjunto de dados e como uma execução antiga pode ser reproduzida.
Em um projeto de avaliação de modelos, salve o identificador da origem, a regra de transformação e um checksum do artefato final. Uma tabela local mutável sem versionamento é difícil de auditar. Um conjunto de arquivos sem convenção de partição e esquema também pode se tornar difícil de governar. Escolha um contrato de dados antes de escolher uma ferramenta por popularidade.
Integração entre DuckDB e Polars
Não é obrigatório escolher um lado para cada etapa. A integração oficial do DuckDB com Polars mostra como consultar um DataFrame Polars e devolver resultados em Polars; ela também informa a dependência de PyArrow para esse caminho. Uma consulta SQL pode selecionar e juntar dados, enquanto um LazyFrame continua uma transformação específica do aplicativo.
Mesmo quando a documentação descreve interoperabilidade eficiente, teste a fronteira em seu ambiente. Materialização, tipo de coluna, versão instalada e tamanho da saída podem mudar a experiência. Para o projeto, o ganho só existe se a combinação tornar a rotina mais clara ou mais confiável. Usar dois motores para uma transformação simples pode aumentar a manutenção sem benefício.
Segurança e privacidade dos dados
Processamento local não equivale automaticamente a tratamento seguro. Um arquivo Parquet pode conter dados pessoais; uma consulta pode exportá-los para uma pasta sincronizada; logs de depuração podem expor amostras. Defina quem acessa origem, banco local, saída e backup. Use dados sintéticos quando estiver apenas comparando ferramentas. Não coloque credenciais em notebooks, comandos de exemplo, arquivos .env versionados ou respostas de agentes.
Se a fonte estiver em storage remoto, avalie autenticação, permissões e custo de leitura antes de rodar scans amplos. Evite passar URLs assinadas e tokens em texto compartilhado. O guia de storage do Polars documenta alternativas de credenciais; a escolha concreta deve seguir a política do ambiente. Não trate um tutorial público como autorização para copiar dados reais para um serviço externo.
Disponibilidade e custos sem adivinhação
Este texto compara o uso local documentado das ferramentas, não planos comerciais ou preços de serviços relacionados. O custo operacional pode estar em armazenamento, execução, leitura de dados remotos, revisão do pipeline e pessoas responsáveis pela manutenção. Sem saber a infraestrutura, a frequência de atualização e o volume efetivamente lido, uma tabela de preço produziria uma conclusão enganosa. Confira termos e valores atuais diretamente com o fornecedor se for contratar hospedagem ou recursos gerenciados.
Teste pequeno para decidir
- Separe uma amostra permitida e representativa, com esquema, nulos, duplicatas e ao menos um caso de erro conhecido.
- Defina uma tarefa idêntica: ler Parquet, filtrar colunas, unir duas fontes, agregar e gravar a saída.
- Escreva a versão DuckDB em SQL e a versão Polars com
scan_parquete expressões. Não mude a regra entre elas. - Confira tipos, contagem de linhas e valores de controle. Se divergirem, investigue antes de medir velocidade.
- Peça a uma segunda pessoa para entender cada pipeline e apontar onde alterar uma regra de negócio.
- Registre versões, máquina, tamanho dos arquivos e método de medição se decidir fazer benchmark próprio.
O melhor resultado não é o menor tempo em uma única execução de amostra. É uma transformação que sua equipe consegue explicar, repetir e corrigir sem colocar dados sensíveis em risco. Nosso roteiro para comparar ferramentas usando a mesma tarefa ajuda a registrar critérios antes de medir.
Quando escolher DuckDB
Escolha DuckDB quando o trabalho é naturalmente uma consulta analítica, há familiaridade com SQL e a equipe quer explorar arquivos ou tabelas locais com poucas etapas de integração. É particularmente atraente quando várias pessoas precisam revisar a mesma regra expressa como consulta. Antes de persistir um banco, confirme se uma consulta direta aos arquivos não atende melhor.
Quando escolher Polars
Escolha Polars quando a transformação está fortemente integrada ao código de uma aplicação ou pipeline Python/Rust, e a equipe prefere compor expressões de colunas com um plano lazy. Confira quais etapas materializam dados e se o fluxo continua legível para quem fará suporte. Se o time só precisa de uma consulta SQL estável, não há prêmio por reescrevê-la em expressões.
Quando combinar os dois ou manter o atual
Combine quando existe uma fronteira clara: por exemplo, SQL para selecionar e unir dados, DataFrame para uma transformação programática posterior. Valide tipos e contagem de linhas na passagem. Mantenha a solução atual quando ela já é reproduzível, compreendida e atende ao desempenho necessário. Migrar só porque um gráfico ou uma comparação genérica parece favorável cria trabalho sem ganho demonstrado. Para um uso pontual e controlado de consultas locais, o guia da Skill DuckDB Query é uma referência complementar, não substitui este comparativo.
Limites deste comparativo
Não executamos benchmark, não testamos todas as versões, não comparamos serviços de nuvem pagos e não afirmamos que uma tecnologia substitui a outra em qualquer escala. As documentações oficiais podem mudar. Os fatos acima descrevem interfaces e recursos documentados na consulta de 22 de setembro de 2026; a recomendação por cenário é análise editorial e precisa ser testada com os seus dados e requisitos.