Neste artigo
- O problema que ninguém fala: stack pesada para análise local
- O que cada ferramenta resolve de verdade
- Quando montar stack pesada é desperdício
- Como usar DuckDB para análise sem subir servidor
- Como usar Polars para transformações encadeadas
- Integração entre DuckDB e Polars
- Como medir se essa abordagem simplificou o trabalho
- Limitações que a documentação não antecipa
- Dúvidas comuns sobre DuckDB e Polars
- Conclusão e próximo passo
O problema que ninguém fala: stack pesada para análise local
Toda vez que alguém descreve um pipeline de análise exploratória que começa com “então a gente sobe um cluster Spark”, eu paro e pergunto: qual é o tamanho do dado? Se a resposta for “uns 5 GB”, eu respiro fundo.
Existe um padrão que vejo repetir em times de dados: a stack de produção vira a ferramenta padrão para qualquer análise, incluindo investigação local, exploração ad hoc e validação de hipótese. O resultado é overhead alto, tempo de setup que concorre com o tempo de análise e dependências que quebram em máquinas diferentes.
A pergunta que faço antes de qualquer coisa é se você realmente precisa de um cluster ou só precisa de um resultado rápido e confiável com os dados que já tem. Na maioria dos casos que vi, é a segunda opção. É aí que DuckDB e Polars entram.
O que cada ferramenta resolve de verdade
Antes de falar como usar, vale deixar claro o que cada uma é, porque a confusão entre as duas é comum.
DuckDB é um banco de dados OLAP embarcado. Você não sobe servidor nenhum. Ele roda em processo, lê Parquet, CSV e JSON direto do disco, e aceita SQL padrão. O modelo mental certo é pensar nele como SQLite, mas otimizado para queries analíticas em vez de transações. Ele é muito bom para agregar, filtrar e fazer join em dados que cabem em disco mesmo que não caibam em memória RAM.
Polars é uma biblioteca de DataFrame em Python com execução lazy, paralelização real e sem o custo de memória do pandas. Ele é melhor quando você precisa de transformações encadeadas, manipulação expressiva de colunas e quer controle fino sobre o pipeline de transformação.
A distinção prática que uso no dia a dia: se a pergunta começa com uma query SQL que já existe na minha cabeça, DuckDB. Se vou construir um pipeline de transformação passo a passo, Polars. E nas situações onde começo com SQL e termino com transformação, os dois conversam bem.
Quando montar stack pesada é desperdício
Não estou dizendo que Spark, Airflow e ferramentas equivalentes não têm lugar. Têm. Mas para análise local e exploratória, o custo de subir esses ambientes raramente se justifica. Algumas situações onde DuckDB e Polars resolvem sem drama:
- Investigar um CSV ou Parquet de alguns gigabytes sem carregar tudo na memória
- Fazer join entre datasets que não vivem no mesmo banco de produção
- Validar hipótese antes de escalar para pipeline
- Debugar um pipeline isolando um subset dos dados para entender o que está errado
- Análise exploratória antes de definir modelo ou transformação definitiva
O que não funciona bem aqui: dado distribuído que realmente não cabe nem em disco local, pipelines que precisam de scheduling e orquestração, ou transformações que vão direto para produção e precisam de controle de versão e auditoria. Nesses casos, a stack pesada faz sentido.
Como usar DuckDB para análise sem subir servidor
O fluxo básico com DuckDB começa com uma conexão em memória, sem nenhuma configuração de servidor. A partir daí, você pode executar SQL padrão diretamente em arquivos Parquet, CSV ou JSON usando funções nativas do banco.
Uma capacidade particularmente útil é ler múltiplos arquivos Parquet com um padrão glob, que consolida todos os arquivos que seguem o padrão em uma única tabela virtual. O resultado pode ser convertido diretamente para um DataFrame do pandas ou do Polars para continuar o trabalho de transformação.
Para descrever esse fluxo para uma IA e pedir ajuda na implementação, você precisa especificar: os nomes dos arquivos ou o padrão de nomes, as colunas que quer selecionar ou calcular, os filtros de data ou categoria que se aplicam e como quer o resultado agregado. Com essa descrição, a IA consegue gerar a query e o código de leitura sem ambiguidade.
Como usar Polars para transformações encadeadas
A interface lazy do Polars é o que faz diferença em relação ao pandas. Você descreve uma sequência de transformações, colunas calculadas e filtros, e o Polars otimiza o plano de execução antes de materializar o resultado. Com pandas, cada operação é materializada imediatamente, consumindo memória a cada passo.
O modelo mental para trabalhar com Polars é escrever toda a cadeia de transformações antes de pedir o resultado. Isso inclui: colunas calculadas a partir de outras colunas, filtros que eliminam linhas com base em condições, ordenações e seleção de colunas relevantes. Quando você pede o resultado final, o Polars avalia o plano todo de uma vez de forma otimizada.
Para explicar esse fluxo para uma IA, descreva as colunas de entrada, o que você quer calcular ou transformar e quais filtros se aplicam. A sintaxe do Polars é específica o suficiente para que a IA gere código funcional a partir de uma descrição clara do objetivo.
Integração entre DuckDB e Polars
Uma coisa que pouca documentação deixa clara: DuckDB consegue registrar um DataFrame do Polars como tabela virtual e executar SQL em cima. Isso fecha o loop entre os dois sem conversão desnecessária de formato ou gravação em disco intermediária.
Esse padrão é útil quando você já tem transformações feitas no Polars e quer fazer uma query SQL em cima do resultado sem exportar para arquivo. Você registra o DataFrame como tabela com um nome, executa SQL normalmente e obtém o resultado.
Para que uma IA ajude com esse padrão, descreva o que o DataFrame do Polars contém e qual query SQL você quer executar em cima dele. A conversão entre as duas ferramentas é direta e bem documentada.
Como medir se essa abordagem simplificou o trabalho
Sem uma forma de avaliar se a mudança de abordagem valeu a pena, você está só trocando uma ferramenta por outra sem evidência. As métricas que uso para avaliar se DuckDB e Polars estão simplificando o fluxo de análise local:
- Tempo até a primeira query útil: quanto tempo levou desde abrir o terminal até ter um resultado inicial. Se esse número não caiu em relação à stack anterior, a troca não ajudou
- Consumo de memória RAM comparado com o fluxo anterior: DuckDB e Polars usam streaming e execução lazy. Se o consumo não caiu em relação ao pandas carregando tudo de uma vez, revise como está lendo os dados
- Taxa de queries que terminaram sem esgotamento de memória: se antes você tinha queries que matavam o processo, anote quantas vezes isso acontece depois da mudança. Zero é o número esperado para dados que cabem em disco local
Essas métricas precisam ser coletadas com os mesmos dados e as mesmas perguntas que você fazia antes. Comparar fluxos diferentes não conta.
Limitações que a documentação não antecipa
DuckDB tem um modelo de concorrência limitado. Se você tentar escrever no mesmo arquivo de banco com dois processos simultâneos, vai ter problema. Para uso local e de um único usuário, isso não importa. Para qualquer coisa que pareça com um serviço compartilhado, não é a ferramenta certa.
Polars tem curva de aprendizado real em torno do modelo lazy versus eager. Se você chamar a materialização do resultado no lugar errado, perde o benefício da execução otimizada. E a API é diferente o suficiente do pandas para causar atrito nos primeiros dias, especialmente em operações de agrupamento e aplicação de funções por grupo.
Outro ponto: integração com código legado. Se o time usa pandas em todo o código existente, introduzir Polars cria uma fronteira de conversão que precisa ser gerenciada. A conversão entre os dois existe, mas adiciona overhead e pode esconder problemas de performance.
Dúvidas comuns sobre DuckDB e Polars
DuckDB substitui o banco de dados de produção?
Não é o propósito. DuckDB é otimizado para queries analíticas locais e embarcadas. Para um banco de dados de produção com múltiplos usuários simultâneos, controle de acesso e transações ACID robustas, a escolha certa é diferente. O artigo sobre PostgreSQL versus MongoDB cobre as decisões de banco de dados para produção.
Polars vai substituir o pandas?
Para novos projetos onde performance importa, Polars é uma alternativa séria. Para código existente com pandas, a migração tem custo real de adaptação. Na minha experiência, times novos adotam Polars com mais facilidade do que times que já têm muito código em pandas. Não há resposta única aqui.
Para dados de produção com pipeline estruturado, esses dois ainda fazem sentido?
DuckDB pode ser parte de um pipeline de dados real, especialmente para transformações analíticas em dados estáticos. Polars também. O que muda é a camada de orquestração, que continua sendo responsabilidade de ferramentas como Airflow ou equivalentes. Para dados que precisam de contrato de qualidade definido antes de entrar no pipeline, o artigo sobre data contracts na prática cobre como estruturar isso.
Como lidar com dados que não cabem em memória mas cabem em disco?
Esse é exatamente o ponto forte do DuckDB. Ele usa processamento em streaming por padrão para queries analíticas, então não carrega tudo na memória ao mesmo tempo. Polars com a interface lazy tem comportamento similar. Os dois foram desenhados para trabalhar com dados que excedem a RAM disponível, desde que caibam em disco.
Conclusão e próximo passo
DuckDB para SQL analítico em arquivos locais, Polars para transformações encadeadas com controle fino, e os dois juntos quando você começa com uma query e termina com transformação. Nenhuma das duas ferramentas requer instalação de servidor, configuração de cluster ou dependência de infraestrutura externa. O custo de entrada é baixo. O ganho em fluxos de análise exploratória é imediato.
Se você quer avançar com isso, o próximo passo é:
- Pegar um arquivo CSV ou Parquet que você já tem e medir quanto tempo leva para chegar no primeiro resultado útil com DuckDB
- Comparar com o tempo do fluxo atual e anotar a diferença
- Experimentar uma transformação encadeada simples no Polars com o mesmo dataset
Para o contexto mais amplo de quando simplificar o stack de dados faz sentido versus quando a complexidade é justificada, o artigo sobre feature store para ML em produção cobre quando a infraestrutura adicional realmente vale o investimento. E para automação de fluxos de dados sem escrita de código pesado, o artigo sobre n8n versus Zapier mostra como conectar fontes de dados sem construir pipeline do zero.
