Precisamos falar sobre o Pandas
Recentemente eu tirei férias com minha família e fui curti-las na Paraíba. Ficamos alguns dias em Campina Grande para aproveitar o final da festa de São João e demais dias em João Pessoa para curtir uma praia. Como não conhecemos nada, contratamos uma agência local para fazer o transfer do aeroporto de João Pessoa até Campina Grande, pois não é que o apelido de um dos guias e motorista, era Panda! E depois foi através desta agência que fizemos todos os passeios, ou seja, passei minhas férias conversando com o Panda e com a Joana, nossos guias.
Num domingo quente, daqueles em que o sol parece ter tirado o dia para te abraçar com gosto. Estava na praia com minha família, aproveitando as férias como manda o figurino: pé na areia, água de coco gelada e crianças cavando buracos como se buscassem petróleo. Até que me peguei rindo sozinho com um pensamento totalmente fora do clima de férias:
“Olha só, passei esses dias todos conversando com o Panda… e mesmo assim a experiência foi leve, rápida e sem travamentos.”
Foi aí que caiu a ficha. Em contraste, no mundo dos dados, nem sempre conversar com o Pandas (o framework, não o guia gente boa) é tão tranquilo assim. Muitas vezes ele vem com lentidão, estouro de memória e aquele famoso “kernel morreu, reinicie o notebook”. A ironia era boa demais pra ignorar.
E foi assim que me inspirei a escrever esse artigo. Quem trabalha com dados em Python já passou por isso, o Pandas é quase um rito de passagem: poderoso, flexível, acessível. Mas também é pesado, ineficiente em escala, e, convenhamos, às vezes te faz sentir que está tentando construir um arranha-céu com palitos de picolé.
Neste artigo, quero explorar como o Pandas nasceu, porque ele se tornou onipresente nos projetos de dados, e — mais importante — o que existe hoje como alternativa mais performática. Spoiler: o DuckDB pode te dar a leveza que seu notebook, seu projeto e talvez até seu verão merecem.
A origem do Pandas — e por que ele virou um clássico
Lá em 2008, antes de falarmos em LLMs, GPUs de 80GB e data lakes voadores, um analista chamado Wes McKinney estava trabalhando na AQR Capital Management, um fundo de investimentos que lidava com grandes volumes de dados financeiros. Ele precisava fazer análise de séries temporais, agregações complexas e manipulação de dados estruturados. Só que… o Excel não dava conta, o R era limitado em alguns aspectos, e o NumPy, apesar de veloz, era baixo nível demais para o que ele precisava.
Foi aí que nasceu o Pandas — do acrônimo “Panel Data”, um termo da econometria. A ideia era simples e revolucionária: criar uma biblioteca que trouxesse poder de manipulação de dados tabulares para o Python, com foco em análise estatística e financeira.
O Pandas se destacou por oferecer:
- DataFrames (inspirados no R): estrutura de dados tabular com rótulos em linhas e colunas;
- Leitura e escrita facilitada (CSV, Excel, JSON, SQL);
- Integração natural com NumPy, Matplotlib e Scikit-learn;
- Uma API intuitiva — para quem já conhecia Excel ou SQL, a curva de aprendizado era suave;
- E o principal: velocidade suficiente para dados de pequeno e médio porte.
Nascia então o canivete suíço da análise de dados em Python. Ao longo dos anos, com a popularização do Jupyter Notebook, da ciência de dados e do movimento open source, o Pandas se consolidou como um padrão de mercado. É quase impossível abrir um curso de Data Science hoje e não ver import pandas as pd nas primeiras células de código.
Mas como todo clássico… o tempo cobra seu preço.
Alternativas com melhor desempenho
Com o passar do tempo, os dados cresceram, os notebooks ficaram mais exigentes… e o Pandas começou a mostrar suas rugas. Ele ainda é excelente para datasets pequenos ou médios, mas não foi feito para lidar com grandes volumes, execuções paralelas ou operações vetorizadas eficientes em memória.
E foi aí que surgiram alternativas mais modernas — cada uma com seu foco, mas com um ponto em comum: superar as limitações de performance do Pandas sem perder a usabilidade.
Vamos conhecer algumas delas brevemente, antes de mergulhar no DuckDB:
- Polars – um foguete em forma de DataFrame, escrito em Rust. Extremamente rápido, com APIs inspiradas no Pandas, mas com foco em paralelismo e eficiência;
- Dask – distribui DataFrames Pandas em múltiplos núcleos ou nós, facilitando o processamento paralelo;
- Modin – tenta manter 100% da API do Pandas, mas executando em Ray ou Dask por trás;
- Vaex – bom para datasets maiores que a memória RAM, com foco em exploração visual e cálculos preguiçosos (lazy evaluation).
- PySpark – a interface Python para o Apache Spark. Ideal para quem precisa processar dados em larga escala distribuída (cluster), mas com a desvantagem de exigir mais infraestrutura e curva de aprendizado. Ótimo para ambientes corporativos ou pipelines robustos.
Mas além desses, o DuckDB tem se destacado como o “SQLite dos Data Lakes”. Simples, eficiente e pronto para o serviço — especialmente quando você quer manter seu workflow em notebooks e ainda assim processar dados com desempenho digno de Big Data.
Conhecendo o DuckDB
O DuckDB é um banco de dados analítico, colunar e embutido. Isso quer dizer que ele roda localmente, direto do seu script ou notebook, sem servidor, e é otimizado para consultas em larga escala — perfeito para o que costumamos fazer com Pandas.
Você pode instalar com:
pip install duckdb
E começar a usá-lo assim:
import duckdb
import pandas as pd
# Lê um CSV usando Pandas (só como ponte)
df = pd.read_csv('vendas.csv')
# Consulta com SQL direto no DataFrame
result = duckdb.query("""
SELECT categoria, SUM(valor) as total
FROM df
WHERE data BETWEEN '2024-01-01' AND '2024-06-30'
GROUP BY categoria
ORDER BY total DESC
""").to_df()
print(result)
Exemplo de uso do DuckDB
Sim, você acabou de consultar um Pandas DataFrame usando SQL com desempenho de banco colunar, sem precisar carregar tudo na RAM como o Pandas faz nativamente.
E tem mais: o DuckDB também lê direto de arquivos Parquet, CSV, SQLite, Arrow, e consegue trabalhar em pipelines com bilhões de linhas — tudo sem sair do notebook. Como, por exemplo:
import duckdb
# #### Opção 1
# Lê o arquivo CSV diretamente e retorna um DataFrame
df = duckdb.query("""
SELECT * FROM 'caminho/do/arquivo.csv'
""").to_df()
# #### Opção 2
# Conecta (opcional, pode ser em memória)
con = duckdb.connect()
# Cria uma tabela a partir do CSV
con.execute("""
CREATE TABLE vendas AS SELECT * FROM 'vendas.csv'
""")
# Agora você pode fazer queries SQL normalmente
df = con.execute("""
SELECT categoria, SUM(valor) as total
FROM vendas
GROUP BY categoria
""").fetchdf()
# #### Opção 3 (Mudando o caracter delimitador)
duckdb.query("""
SELECT * FROM read_csv_auto('dados.csv', delim=';', header=True)
""").to_df()
# Ou ainda definindo os data types
duckdb.query("""
SELECT * FROM read_csv('dados.csv', columns={'produto': 'VARCHAR', 'quantidade': 'INTEGER'})
""").to_df()
Lendo arquivos CSV usando o DuckDB
Caso queira mais detalhes de benchmark, recomendo a leitura dos seguintes artigos (em inglês):
Se você chegou até aqui, é sinal de que também sente o incômodo. O Pandas foi — e ainda é — uma ferramenta essencial na formação de toda uma geração de profissionais de dados. Ele democratizou a análise com Python, deu poder à comunidade, virou protagonista de cursos, livros e projetos.
Mas o mundo mudou. Os dados cresceram. Os notebooks se tornaram campos de batalha onde cada megabyte conta. E nós, como engenheiros, cientistas e analistas, precisamos de ferramentas que evoluam com essa realidade.
O DuckDB, entre outras alternativas, mostra que é possível manter a simplicidade do Pandas com o desempenho de um banco de dados analítico moderno. E tudo isso sem abdicar da praticidade — pelo contrário, ganhando legibilidade e velocidade no processo.
Então, da próxima vez que seu notebook travar após um groupby()
, lembre-se: talvez o problema não esteja em você. Talvez esteja no Pandas e seja hora de convidar o Duck para a conversa.
Se você achou esse artigo útil ou conhece alguém que pode se beneficiar dessas informações, compartilhe! Afinal, sempre há espaço para um bate-papo produtivo.