DEV Community: Jose Luis da Cruz Junior

[pt-BR] Entendendo Ownership em Rust: Um Guia para Pythonistas

Jose Luis da Cruz Junior — Tue, 11 Aug 2026 11:00:00 +0000

Por @zejuniortdr em Fev 22, 2026

Se você vem do Python e está começando com Rust, provavelmente já se deparou com mensagens de erro misteriosas sobre "ownership", "borrowing" ou "value moved here". Calma, você não está sozinho nessa jornada. Vamos explorar juntos esse conceito que é o coração da segurança e performance do Rust.

Por que Ownership é tão importante em Rust?

Imagine que você está organizando uma festa na sua casa — sua memória RAM é a casa. Em Python, é como se você tivesse um assistente (o coletor de lixo) que fica anotando quem veio, quem saiu e limpando tudo depois. Já em Rust, você é o anfitrião responsável: precisa garantir que cada convidado (dado) tenha um lugar certo, sem bagunça e sem invasores.

Esse sistema permite ao Rust:

Garantir segurança de memória sem coletor de lixo
Prevenir vazamentos de memória e acessos inválidos
Permitir otimizações de performance em tempo de compilação

Os três princípios do Ownership

Direto do livro oficial do Rust, as regras são:

Cada valor em Rust tem um dono (owner)
Só pode haver um dono por vez
Quando o dono sai de escopo, o valor é descartado

Parece simples, mas as implicações são profundas. Vamos entender com exemplos.

Princípio 1: Cada valor tem um dono

Em Rust, toda variável é dona do valor que armazena:

fn main() {
    let s = String::from("hello");  // s é a dona da String "hello"
    println!("{}", s);              // podemos usar s aqui
} // s sai de escopo e a memória é liberada automaticamente

Compare com Python, onde os objetos têm vida própria:

def main():
    s = "hello"  # s referencia o objeto string
    print(s)     # mas não é sua "dona" exclusiva
    # O coletor de lixo decide quando liberar a memória

Princípio 2: Um único dono por vez

Em Rust, você não pode ter múltiplos donos para o mesmo valor. Note também que tipos simples como inteiros e booleanos implementam o trait Copy e não sofrem move — são copiados automaticamente:

fn main() {
    // Tipos que implementam Copy são copiados, não movidos
    let x = 5;
    let y = x;
    println!("{} {}", x, y); // Ok: i32 implementa Copy

    // String NÃO implementa Copy: sofre move
    let s1 = String::from("hello");
    let s2 = s1; // O valor é MOVIDO de s1 para s2

    // println!("{}", s1); // ERRO! s1 não é mais dona de nada
    println!("{}", s2);    // Ok, s2 é a nova dona
}

Em Python, isso seria perfeitamente válido em ambos os casos:

s1 = "hello"
s2 = s1  # Ambos referenciam o mesmo objeto
print(s1)  # Funciona
print(s2)  # Funciona

Princípio 3: Descarte quando sai de escopo

Rust automaticamente libera memória quando o dono sai de escopo. Quando isso acontece, o compilador chama implicitamente o trait Drop do valor — o equivalente a um destrutor que você pode até customizar para seus próprios tipos:

fn main() {
    let outer = String::from("outer");
    {
        // Novo escopo
        let inner = String::from("inner");
        println!("{}", outer); // Ok
        println!("{}", inner); // Ok
    } // inner é dropada aqui; Drop é chamado automaticamente

    // println!("{}", inner); // ERRO! inner não existe mais aqui
    println!("{}", outer);    // outer ainda é válida
}

Em Python, não temos essa garantia imediata:

def main():
    s = "hello"
    print(s)
    # O objeto pode ou não ser liberado imediatamente
    # Depende do coletor de lixo

Erros comuns de Pythonistas em Rust

Agora que vimos os princípios, vamos aos problemas que você provavelmente enfrentará.

1. Tentar usar uma variável após movê-la

let s1 = String::from("texto");
let s2 = s1;
println!("{}", s1);  // ERRO: value borrowed here after move

Solução: Use referências (&) ou clone explicitamente:

let s1 = String::from("texto");
let s2 = &s1; // Empresta s1 sem mover
println!("{} {}", s1, s2); // Ok

2. Modificar uma referência imutável

Este erro é sutil: o problema não é só tentar modificar uma referência imutável, mas tentar criar uma referência mutável enquanto referências imutáveis ainda estão ativas:

let mut s = String::from("hello");
let r = &s;              // Referência imutável ativa
s.push_str(", world");   // ERRO: cannot borrow `s` as mutable
                         // because it is also borrowed as immutable
println!("{}", r);

Solução: Use referências mutáveis somente quando não há referências imutáveis ativas:

let mut s = String::from("hello");
// Não há referências imutáveis ativas aqui
let r = &mut s;
r.push_str(", world"); // Ok
println!("{}", r);

3. Criar referências inválidas (dangling references)

fn cria_referencia() -> &String {
    let s = String::from("hello");
    &s // ERRO: s será liberada ao final da função!
}

Solução: Retorne o valor diretamente, transferindo ownership para quem chamou:

fn cria_string() -> String {
    let s = String::from("hello");
    s // Transfere ownership para o caller
}

Exemplo prático completo:

Vamos ver um exemplo completo que mostra ownership na prática, comparando Rust e Python:

Versão Rust

fn main() {
    // Passamos ownership para a função; original não pode ser usada depois
    let original = String::from("Rust é seguro");
    let comprimento = calcula_comprimento(original);
    println!("Comprimento: {}", comprimento);
    // println!("{}", original); // ERRO: original foi movida

    // Com borrowing, original permanece válida
    let original2 = String::from("Rust é eficiente");
    let comprimento2 = calcula_comprimento_emprestado(&original2);
    println!("Original2 ainda válida: {}", original2);
    println!("Comprimento: {}", comprimento2);

    // Clone cria uma cópia real e independente
    let copia = original2.clone();
    let comprimento3 = calcula_comprimento(copia);
    println!("Original2 ainda válida: {}", original2);
    println!("Comprimento da cópia: {}", comprimento3);
}

// Recebe ownership da String; ela é liberada ao final
fn calcula_comprimento(s: String) -> usize {
    s.len()
}

// Recebe uma referência; usa &str para ser mais idiomático
fn calcula_comprimento_emprestado(s: &str) -> usize {
    s.len()
}

Versão Python

def main():
    original = "Python é dinâmico"

    # Em Python, passamos referências, não ownership
    comprimento = calcula_comprimento(original)

    # Original ainda está acessível
    print(f"Original: {original}")

    # Não precisamos nos preocupar com borrowing ou moving
    original2 = "Python é flexível"
    comprimento2 = calcula_comprimento(original2)
    print(f"Original2 ainda válida: {original2}")

def calcula_comprimento(s):
    return len(s)  # Não afetamos o caller

Ownership em tipos customizados

O sistema de ownership se aplica igualmente a structs e outros tipos compostos. Sempre que uma struct contém um campo como String, ela também não implementa Copy — portanto sofre move na atribuição:

struct Item {
    nome: String,
}

fn main() {
    let item = Item { nome: String::from("Exemplo") };
    let item2 = item; // Move ocorre aqui

    // println!("{}", item.nome); // ERRO: item foi movido
    println!("{}", item2.nome);   // Ok
}

Comparação: Gerenciamento de memória em Python vs Rust

Característica	Python	Rust
Modelo	Coleta de lixo (GC)	Ownership system
Performance	Overhead do GC	Sem overhead de runtime
Segurança	Possíveis referências inválidas	Garantido em tempo de compilação
Controle	Automático	Manual (com garantias)
Concorrência	GIL pode ser limitante	Sem GIL, seguro por design

Semântica de operações: Python vs Rust

Operação	Python	Rust
Atribuição (=)	Cria nova referência	Move ou copia (Copy types)
Cópia profunda	copy.deepcopy()	.clone()
Passagem para função	Por referência	Move ou borrow (&)

Quando usar clone() em Rust?

Pythonistas muitas vezes esperam que a atribuição crie cópias independentes. Em Rust, isso não acontece automaticamente para tipos alocados no heap. Se você precisa de uma cópia real, use clone() — mas use com consciência, pois ele aloca nova memória:

let s1 = String::from("texto");
let s2 = s1.clone(); // Cópia real, não só da referência

println!("s1 = {}, s2 = {}", s1, s2); // Ambos válidos

Em Python, isso seria equivalente a:

import copy
s1 = "texto"
s2 = copy.deepcopy(s1)  # Para strings é desnecessário, mas ilustra a ideia

Exercício prático

Para fixar o conceito, tente resolver o seguinte problema:

O código abaixo não compila. Modifique apenas a assinatura de exibe_tamanho para que nome permaneça válido após a chamada da função:

fn main() {
    let nome = String::from("Rustacean");
    exibe_tamanho(nome);
    println!("{}", nome); // Como fazer isso funcionar?
}

fn exibe_tamanho(s: String) {
    println!("Tamanho: {}", s.len());
}

Dica: a solução está na diferença entre mover e emprestar.

O que aprendemos? 📚

Ownership é o sistema único do Rust para gerenciar memória sem GC
Cada valor tem apenas um dono por vez em Rust
Quando o dono sai de escopo, o valor é liberado
Em Python, o coletor de lixo cuida da memória automaticamente
Erros comuns incluem tentar usar valores após movê-los
Referências (&) permitem "emprestar" valores sem transferir ownership
Clone() cria cópias reais quando necessário

Próximos passos na sua jornada Rust

Dominar ownership é o primeiro passo para escrever código Rust seguro e eficiente. No próximo post, exploraremos o conceito de borrowing e lifetimes em profundidade — incluindo como o compilador rastreia o tempo de vida das referências para garantir que nunca apontem para memória inválida.

Para se aprofundar ainda mais com exemplos práticos e exercícios, confira o livro Desbravando Rust em desbravandorust.com.br.

[pt-BR] De Django ORM para SQLx: A Jornada de um backend que desaprendeu a confiar em mágica

Jose Luis da Cruz Junior — Tue, 04 Aug 2026 11:00:00 +0000

Por @zejuniortdr em Fev 16, 2026

Este artigo é para quem viveu anos no conforto do Django ORM e está cogitando encarar SQLx em Rust. Vamos falar de produtividade, dor, performance e o que você realmente ganha (e perde) ao largar a ‘mágica’.

Passei quase 20 anos confiando que o Django fazia magia com bancos de dados. Eu estava errado - não era magia, era abstração. E abstrações, descobri da pior forma, têm custo.

Durante anos, escrevi código Python elegante que se transformava em SQL sem eu nem pensar nisso. Produto.objects.filter(preco__gt=100).select_related('categoria') - boom, query otimizada. Migrations automáticas com makemigrations. Admin de graça. CRUD em minutos. Era produtividade pura.

Até o dia em que isso deixou de ser verdade. Um endpoint de relatório começou a demorar 8 segundos. O Django Debug Toolbar mostrou 247 queries. Duzentas e quarenta e sete. Eu tinha acabado de criar o N+1 query mais épico da história da empresa, e o pior: o código Python parecia perfeitamente inocente. Foi quando comecei a questionar se eu realmente entendia o que estava acontecendo embaixo do capô.

E foi assim que acabei conhecendo SQLx. Minha primeira reação? "Mano, eu tenho que escrever SQL na mão?!" Spoiler: sim. E isso mudou completamente como penso sobre bancos de dados.

O Conforto (e o Preço) da Magia do Django ORM

Vamos ser justos: Django ORM é espetacular para o que foi projetado. Não estou aqui para fazer bashing - usei o Django por décadas e ainda uso em vários projetos. Mas preciso ser honesto sobre seus limites.

O Que o Django ORM Faz de Genial

A produtividade é absurda. Você define seus modelos como classes Python normais e ganha de graça:

# Django ORM - Elegante, Pythônico, Produtivo
from django.db import models

class Categoria(models.Model):
    nome = models.CharField(max_length=100)
    slug = models.SlugField(unique=True)

class Produto(models.Model):
    nome = models.CharField(max_length=200)
    descricao = models.TextField()
    preco = models.DecimalField(max_digits=10, decimal_places=2)
    estoque = models.IntegerField(default=0)
    categoria = models.ForeignKey(Categoria, on_delete=models.CASCADE)
    criado_em = models.DateTimeField(auto_now_add=True)

# Queries elegantes e intuitivas
produtos_caros = Produto.objects.filter(
    preco__gt=100,
    estoque__gt=0
).select_related('categoria')

# Lazy evaluation - não executa até você iterar
for produto in produtos_caros:
    print(f"{produto.nome} - {produto.categoria.nome}")

É lindo. É Pythônico. E funciona muito bem para 80% dos casos de uso. O sistema de migrations é quase mágico - você altera o modelo, roda makemigrations, e o Django gera o SQL de migração automaticamente. O admin? Um CRUD completo e funcional sem escrever uma linha de HTML.

Para MVPs, protótipos e aplicações CRUD tradicionais, Django ORM é imbatível em produtividade.

Onde a Magia Começa a Doer

Mas aí você começa a escalar. Suas queries ficam mais complexas. E começam os problemas:

1. N+1 Queries Silenciosos


# Parece inocente, mas...
produtos = Produto.objects.filter(estoque__gt=0)

for produto in produtos:
    print(produto.categoria.nome)  # BOOM! Uma query POR produto

Você precisa lembrar de usar select_related() ou prefetch_related(). Esqueça uma vez em produção e seu banco chora.

2. Queries Complexas Viram Hieróglifos

# Django ORM quando fica feio
from django.db.models import Count, Sum, F, Q, Prefetch

relatorio = Categoria.objects.annotate(
    total_produtos=Count('produto'),
    produtos_em_estoque=Count('produto', filter=Q(produto__estoque__gt=0)),
    valor_total_estoque=Sum(
        F('produto__preco') * F('produto__estoque')
    )
).filter(
    total_produtos__gt=5
).select_related(
    'categoria_pai'
).prefetch_related(
    Prefetch(
        'produto_set',
        queryset=Produto.objects.filter(estoque__gt=0).order_by('-preco')
    )
)

Olha, eu sei fazer isso. Mas na moral: você consegue ler essa query e saber exatamente qual SQL será gerado? Eu não consigo sem rodar e olhar o log.

3. Controle Limitado

Às vezes você sabe a query SQL perfeita. Você testou no psql, otimizou os índices, usou CTEs, tudo lindo. Mas fazer o Django gerar esse SQL específico? Boa sorte. Você acaba usando .raw() ou connection.cursor(), jogando fora todas as vantagens do ORM.

4. Performance Imprevisível

O ORM pode gerar SQL subótimo e você só descobre em produção, sob carga. Aquele inocente .filter().count() pode virar um SELECT COUNT(*) numa tabela de 10 milhões de linhas sem índice adequado.

O Choque Inicial com SQLx

Quando abri meu primeiro projeto Rust com SQLx, quase desliguei o pc e voltei para o conforto do Django.

// SQLx - Primeira impressão: "Isso é TUDO isso?!"
use sqlx::{PgPool, FromRow};
use serde::Serialize;

#[derive(Debug, FromRow, Serialize)]
struct Produto {
    id: i32,
    nome: String,
    preco: rust_decimal::Decimal,
    estoque: i32,
    categoria_id: i32,
}

async fn listar_produtos_caros(pool: &PgPool) -> Result<Vec<Produto>, sqlx::Error> {
    let produtos = sqlx::query_as::<_, Produto>(
        "SELECT id, nome, preco, estoque, categoria_id
         FROM produtos
         WHERE preco > $1 AND estoque > 0
         ORDER BY preco DESC"
    )
    .bind(100.0)
    .fetch_all(pool)
    .await?;

    Ok(produtos)
}

Minha reação: "Pera aí... eu tenho que escrever o SQL inteiro? Listar todos os campos? Não tem .select_related() mágico? E as migrations, onde estão?!"

Era desconfortável. Parecia que eu estava regredindo 15 anos na carreira.

Mas Aí Veio o Momento "Aha!"
Depois de alguns dias brigando com o compilador (porque Rust não perdoa), descobri algo incrível:


// SQLx com compile-time checking
let produtos = sqlx::query!(
    r#"
    SELECT id, nome, preco, estoque, categoria_id
    FROM produtos
    WHERE preco > $1 AND estoque > 0
    "#,
    100.0
)
.fetch_all(pool)
.await?;

// O compilador VALIDA essa query contra seu banco REAL
// Se você escreveu "produtoss" (com S duplo), NÃO COMPILA
// Se você typar "categoria_idd", NÃO COMPILA
// Se a coluna não existir, NÃO COMPILA

// E o melhor: autocomplete perfeito!
let primeiro = &produtos[0];
println!("{}", primeiro.nome);  // ← IDE sabe que existe
// primeiro.campo_inexistente  // ← ERRO DE COMPILAÇÃO

Isso mudou tudo.

O SQLx valida suas queries em tempo de compilação contra o schema real do banco de dados. Você não descobre erro de SQL em produção, às 3h da manhã, com o CEO te ligando. Você descobre quando tenta compilar. É impossível deployar SQL quebrado.

Comparação Técnica: Lado a Lado

Aspecto	Django ORM	SQLx	Vencedor
Curva de Aprendizado	⭐⭐⭐⭐⭐ Muito fácil	⭐⭐ Requer SQL sólido	Django
Produtividade Inicial	⭐⭐⭐⭐⭐ CRUD em minutos	⭐⭐⭐ Mais boilerplate	Django
Controle sobre SQL	⭐⭐ Limitado	⭐⭐⭐⭐⭐ Total	SQLx
Type Safety	⭐⭐ Runtime (mypy ajuda)	⭐⭐⭐⭐⭐ Compile-time	SQLx
Performance	⭐⭐⭐ Boa com cuidado	⭐⭐⭐⭐⭐ Zero overhead	SQLx
Debugging	⭐⭐ SQL gerado obscuro	⭐⭐⭐⭐ Você escreveu	SQLx
Migrations	⭐⭐⭐⭐⭐ Automáticas	⭐⭐ Manuais (ferramentas)	Django
Queries Complexas	⭐⭐ Fica feio rápido	⭐⭐⭐⭐ SQL puro é melhor	SQLx
Admin/CRUD Grátis	⭐⭐⭐⭐⭐ Sim	⭐ Não existe	Django
Validação de Schema	⭐⭐ Runtime	⭐⭐⭐⭐⭐ Compile-time	SQLx

Relacionamentos e JOINs

# Automático mas implícito
produtos = Produto.objects.select_related('categoria', 'fornecedor')

# Você não vê qual tipo de JOIN está rolando
# É INNER? É LEFT? Django decide por você

// Explícito - você controla cada JOIN
let produtos = sqlx::query!(
    r#"
    SELECT
        p.id, p.nome, p.preco, p.estoque,
        c.nome as "categoria_nome!",
        f.nome as "fornecedor_nome?"
    FROM produtos p
    INNER JOIN categorias c ON p.categoria_id = c.id
    LEFT JOIN fornecedores f ON p.fornecedor_id = f.id
    WHERE p.preco > $1
    ORDER BY p.preco DESC
    "#,
    100.0
)
.fetch_all(pool)
.await?;

Análise: Django é mais rápido de escrever. Mas SQLx deixa cristalino o que está acontecendo. Você vê que categoria é INNER (obrigatório) e fornecedor é LEFT (opcional). O ! e ? na query do SQLx indicam tipos não-nuláveis e nuláveis, respectivamente.

Agregações e Subqueries

Django:

# Fica confuso rápido
from django.db.models import Count, Sum, F, Q, OuterRef, Subquery

vendas_por_categoria = Categoria.objects.annotate(
    total_produtos=Count('produto', distinct=True),
    produtos_em_estoque=Count(
        'produto',
        filter=Q(produto__estoque__gt=0)
    ),
    receita_potencial=Sum(
        F('produto__preco') * F('produto__estoque'),
        filter=Q(produto__estoque__gt=0)
    )
).filter(
    receita_potencial__gt=50000
).order_by('-receita_potencial')

Rust com SQLx:

// SQL puro - sem surpresas
let vendas = sqlx::query!(
    r#"
    SELECT
        c.id,
        c.nome,
        COUNT(DISTINCT p.id) as "total_produtos!",
        COUNT(p.id) FILTER (WHERE p.estoque > 0) as "produtos_em_estoque!",
        COALESCE(SUM(p.preco * p.estoque) FILTER (WHERE p.estoque > 0), 0) as "receita_potencial!"
    FROM categorias c
    LEFT JOIN produtos p ON c.id = p.categoria_id
    GROUP BY c.id, c.nome
    HAVING COALESCE(SUM(p.preco * p.estoque) FILTER (WHERE p.estoque > 0), 0) > $1
    ORDER BY receita_potencial DESC
    "#,
    50000.0
)
.fetch_all(pool)
.await?;

Análise: Para queries complexas, SQL puro é infinitamente mais legível. Você não precisa decorar a sintaxe do Django ORM nem adivinhar qual SQL será gerado. E quando roda EXPLAIN ANALYZE, você vê exatamente a query que escreveu.

Transactions

Django:

from django.db import transaction

@transaction.atomic
def transferir_estoque(origem_id, destino_id, quantidade):
    # select_for_update = lock pessimista
    origem = Estoque.objects.select_for_update().get(id=origem_id)
    destino = Estoque.objects.select_for_update().get(id=destino_id)

    if origem.quantidade < quantidade:
        raise ValueError("Estoque insuficiente")

    origem.quantidade -= quantidade
    destino.quantidade += quantidade

    origem.save()
    destino.save()
    # Se qualquer coisa explodir, rollback automático

SQLx:

async fn transferir_estoque(
    pool: &PgPool,
    origem_id: i32,
    destino_id: i32,
    quantidade: i32,
) -> Result<(), sqlx::Error> {
    let mut tx = pool.begin().await?;

    // SELECT FOR UPDATE explícito
    let origem = sqlx::query!(
        "SELECT quantidade FROM estoque WHERE id = $1 FOR UPDATE",
        origem_id
    )
    .fetch_one(&mut *tx)
    .await?;

    if origem.quantidade < quantidade {
        return Err(sqlx::Error::RowNotFound); // Rollback implícito
    }

    sqlx::query!(
        "UPDATE estoque SET quantidade = quantidade - $1 WHERE id = $2",
        quantidade, origem_id
    )
    .execute(&mut *tx)
    .await?;

    sqlx::query!(
        "UPDATE estoque SET quantidade = quantidade + $1 WHERE id = $2",
        quantidade, destino_id
    )
    .execute(&mut *tx)
    .await?;

    tx.commit().await?;
    Ok(())
}

Análise: SQLx é mais verboso, mas você controla cada passo da transação. O SELECT FOR UPDATE está explícito. O commit é manual. Se você retornar Err, o rollback é automático. Zero mágica, controle total.

O Que SQLx Me Ensinou Sobre Bancos de Dados

Essa é a parte que eu não esperava: usar SQLx me tornou um desenvolvedor melhor, inclusive quando volto para Django.

1. Índices Importam (DE VERDADE)
No Django, você adiciona db_index=True e esquece. No SQLx, quando você escreve WHERE preco > 100 ORDER BY criado_em DESC, você pensa: "Pera, eu tenho um índice em preco? E em criado_em? Devo criar um índice composto?"

Comecei a rodar EXPLAIN ANALYZE em tudo. Descobri que metade dos índices que criava no Django eram inúteis, e faltavam índices críticos em queries reais.

2. JOINs Têm Custo Diferente
INNER JOIN é rápido quando há match. LEFT JOIN traz tudo da tabela esquerda mesmo sem match - mais lento e mais dados. RIGHT JOIN quase ninguém usa (e provavelmente você também não deveria).

No Django, select_related esconde essas decisões. No SQLx, você escolhe o JOIN, e isso te força a pensar na semântica dos dados.

3. Connection Pooling Não É Mágico
Django gerencia o pool automaticamente. Você nem pensa nisso. No SQLx:

let pool = PgPoolOptions::new()
    .max_connections(20)
    .min_connections(5)
    .acquire_timeout(Duration::from_secs(3))
    .connect(&database_url)
    .await?;

Você configura explicitamente quantas conexões, timeouts, behavior de retry. E quando dá erro de "too many connections", você sabe exatamente por quê.

4. Tipos do Banco vs Tipos da Linguagem
Django abstrai: DecimalField vira Decimal em Python. No SQLx, você mapeia explicitamente:

use rust_decimal::Decimal;  // Para NUMERIC/DECIMAL do PostgreSQL
use chrono::{DateTime, Utc};  // Para TIMESTAMP WITH TIME ZONE
use uuid::Uuid;  // Para UUID

#[derive(FromRow)]
struct Produto {
    id: Uuid,
    preco: Decimal,  // Não é f64! Precisão financeira!
    criado_em: DateTime<Utc>,
}

Você aprende que f64 é péssimo para dinheiro (floating point errors). Você entende que timestamps com timezone são diferentes de timestamps ingênuos. Django abstrai isso; SQLx te educa.

5. Prepared Statements são seus amigos
SQLx usa prepared statements por padrão:

sqlx::query!("SELECT * FROM produtos WHERE id = $1", produto_id)

Esse $1 não é interpolação de string. É um placeholder. O PostgreSQL prepara a query uma vez, cacheia o plano de execução, e reutiliza. É mais rápido e previne SQL injection automaticamente.

Django também faz isso, mas você nunca vê. Em SQLx, é impossível não usar prepared statements (a menos que você use .query() com raw SQL, mas aí você perde compile-time checking).

Quando Usar Cada Um?

Quando Usar Cada Um?
Aqui está a verdade: eu não "abandonei" o Django. Uso as duas ferramentas, para coisas diferentes.

Use Django ORM quando:

✅ Você precisa de um MVP/protótipo RÁPIDO - Nada bate Django para validar uma ideia em 2 dias

✅ Seu time é predominantemente Python - Curva de aprendizado de Rust é íngreme; às vezes não vale a pena

✅ As queries são simples - CRUD básico, filtros simples, relacionamentos diretos? Django é imbatível

✅ O Django Admin é requisito - Um backoffice completo de graça é difícil de superar

✅ Performance não é gargalo - Se o banco responde em 50ms e isso é OK para seu SLA, otimização prematura é raiz de todo mal

✅ Você quer migrations automáticas - makemigrations é espetacular; em Rust você usa ferramentas como sqlx-cli migrate ou refinery, mas é mais manual

Use SQLx quando:

✅ Performance e latência são críticas - APIs públicas de alta carga, microserviços que processam milhões de requests

✅ Você tem queries SQL complexas - CTEs, window functions, LATERAL joins - SQL puro é mais legível

✅ Type safety em compile-time é importante - Zero erros de SQL em produção vale ouro

✅ Você quer controle total - Quando você precisa otimizar cada byte e cada milissegundo

✅ Seu time já sabe SQL bem - Se seu time é forte em SQL, SQLx é produtivo rapidamente

✅ Microserviços de alta performance - Serviços stateless, containerizados, que precisam escalar horizontalmente com eficiência

Use os Dois quando:
✅ Sistema híbrido - Django para backoffice/admin, Rust+SQLx para APIs públicas de alta carga

✅ Migração gradual - Comece com Django, identifique gargalos, reescreva apenas esses endpoints em Rust

✅ Equipe mista - Devs Python no backoffice, devs Rust em serviços críticos

Lições da Jornada

Depois de meses nessa transição, aqui estão as lições que carrego:

1. Abstrações São Trade-offs

Django te dá produtividade; SQLx te dá controle. Não existe almoço grátis. Escolha conscientemente qual trade-off seu projeto precisa.

2. Saber SQL de Verdade Importa

SQLx me forçou a ser muito melhor em SQL. E isso é transferível para qualquer stack. Hoje, quando volto para o Django, escrevo queries do ORM muito mais eficientes porque sei o SQL que vai ser gerado.

3. Type Safety É Viciante

Depois que você vê query errors em compile-time, é muito difícil voltar para descobrir em produção que você typo categria em vez de categoria.

4. Curva de Aprendizado Vale a Pena

Os primeiros dias foram duros. Muito. Mas depois da curva, você codifica mais rápido e com mais confiança. Zero medo de refatorar queries, porque o compilador te protege.

5. Django Não É "Ruim"

Sério. O Django é uma ferramenta incrível para o que foi projetado. Rust+SQLx é para cenários diferentes. Use a ferramenta certa para o problema certo.

Conclusão

Desaprender a confiar em mágica foi doloroso. Teve dias que eu pensei "cara, por que não deixo o Django fazer isso automaticamente?". Mas hoje, olhando para trás, valeu cada minuto de frustração.

Não é que SQLx seja "melhor" que Django ORM. É que eles resolvem problemas diferentes. O Django maximiza produtividade para 80% dos casos. SQLx maximiza performance e controle para os 20% críticos.

No fim das contas, eu não abandonei o Django - eu só aprendi quando não usar ele. E isso, ironicamente, me tornou um desenvolvedor Django melhor também. Hoje, quando vejo um select_related, sei exatamente qual JOIN está rolando. Quando vejo um .annotate(), sei qual SQL será gerado. Quando vejo N+1 queries, identifico na hora.

A magia ainda está lá. Eu só entendo os truques agora.

E você sabe o que descobri? Não precisa escolher um lado. Use o Django para prototipar rápido. Use SQLx para otimizar gargalos. Use os dois no mesmo sistema. A melhor stack é a que resolve o problema do jeito mais eficiente, não a que te dá mais pontos de dogmatismo no Twitter.

Se você está confortável demais com seu ORM, talvez seja hora de se desconfortar um pouco. Escreva SQL na mão por algumas semanas. Veja o que você aprende. Não precisa migrar tudo - mas experimente.

Você pode se surpreender com o que descobre quando a magia desaparece.

Quer Mergulhar Fundo no Rust e SQLx?

Se este artigo despertou sua curiosidade sobre como Rust e SQLx funcionam por baixo dos panos, ou se você quer dominar essa transição sem passar pelos mesmos perrengues que eu passei, temos algo especial para você.

"Desbravando Rust" é o guia definitivo para desenvolvedores backend que querem ir além das abstrações e realmente entender como bancos de dados, performance e type safety funcionam em sistemas modernos.

O Que Você Vai Aprender:

SQLx do zero: Desde queries simples até transactions complexas e streaming.

Async/Await em Rust: Como Tokio funciona e por que é tão rápido comparado ao asyncio do Python.

Type Safety na prática: Compile-time checking que salva seu deploy às 3h da manhã.

Migrations e Schema Management: Ferramentas do ecossistema como sqlx-cli e como estruturar projetos reais.

Projetos completos: Construa APIs de produção com Axum + SQLx + PostgreSQL, com testes, observabilidade e deploy.

[pt-BR] Cargo contra rapa

Jose Luis da Cruz Junior — Tue, 28 Jul 2026 11:00:00 +0000

Por @zejuniortdr em Dez 03, 2025

Se você vem de linguagens como JavaScript, Python ou PHP, provavelmente já passou pela "fadiga de configuração". Você quer começar um projeto novo e a primeira hora é gasta decidindo qual gerenciador de pacotes usar, configurando o linter, o formatador, o framework de testes e o bundler.

E se eu te dissesse que no Rust, essa decisão já foi tomada por você, e ela é incrivelmente boa?

Apresento o Cargo: o gerenciador de pacotes, sistema de build, executor de testes, gerador de documentação e melhor amigo do desenvolvedor Rust, com uma prévia do que encontrará no livro que pode ser adquirido no link no final deste post.

O Caos do Tooling Moderno

Para entender o valor do Cargo, precisamos olhar para o estado atual de outras stacks populares. Não me entenda mal, essas linguagens são fantásticas, mas o tooling... bem, é complicado.

O Ecossistema JavaScript/TypeScript

Bem-vindo ao paradoxo da escolha:

Gerenciador de Pacotes: npm? yarn? pnpm? bun?
Build/Bundle: Webpack? Rollup? Vite? Esbuild? Turbopack?
Testes: Jest? Mocha? Vitest? Ava?
Linting/Formatting: ESLint? Prettier? Biome? Standard?

Configurar um projeto TypeScript moderno do zero é quase um rito de passagem. Você precisa de um package.json, tsconfig.json, .eslintrc, .prettierrc, jest.config.js... e torcer para as versões conversarem entre si.

O Ecossistema Python

Python é famoso por ser fácil de ler, mas difícil de gerenciar:

Gerenciamento de Dependências: pip puro? poetry? pipenv? O novo e promissor uv?
Ambientes Virtuais: venv? virtualenv? conda?
Formatação/Linting: black? flake8? pylint? ruff (escrito em Rust, diga-se de passagem)?

O meme "Python environment hell" existe por um motivo.

O Ecossistema PHP

O PHP evoluiu muito. O Composer é uma obra de arte e salvou a linguagem. Mas ele foca estritamente em dependências.
Para um workflow completo, você ainda precisa costurar:

Testes: PHPUnit ou Pest?
Análise Estática: PHPStan ou Psalm?
Formatação: PHP-CS-Fixer ou Pint?

O Jeito Cargo de Ser

Rust adotou uma abordagem diferente: Baterias Inclusas. O Cargo não é apenas um instalador de bibliotecas; ele é um orquestrador de todo o ciclo de vida do desenvolvimento.

Quando você instala o Rust, o Cargo vem junto. E com ele, você tem uma ferramenta padronizada para tudo.

1. Criando Projetos (`cargo new`)

Sem perguntas complexas, sem boilerplate excessivo.

cargo new meu-projeto

Isso cria a estrutura de pastas, inicializa o git e cria o Cargo.toml (o arquivo de configuração). Pronto.

2. Gerenciando Dependências

Quer adicionar uma lib?

cargo add serde --features derive

O Cargo baixa, compila (incluindo dependências das dependências) e garante que tudo funciona. O resolver de versões do Cargo é extremamente robusto e respeita o Semantic Versioning rigorosamente.

3. Build e Execução (`cargo run`)

cargo run

Esse comando compila seu código, linka as bibliotecas e executa o binário. Se você mudar uma linha, ele recompila incrementalmente apenas o necessário.

4. Testes Integrados (`cargo test`)

Não precisa instalar nada. O Rust tem suporte a testes na própria linguagem.

#[test]
fn it_works() {
    assert_eq!(2 + 2, 4);
}

Rodou cargo test, ele encontra todos os testes (unitários, integração e até doc-tests), compila e executa em paralelo. Simples assim.

5. Formatação Padrão (`cargo fmt`)

Chega de brigas em Code Review sobre onde colocar a chave ou se usa aspas simples ou duplas.
O rustfmt é o padrão oficial. Todo código Rust parece ter sido escrito pela mesma pessoa.

cargo fmt

6. O Professor Particular (`cargo clippy`)

O Clippy é mais que um linter; é um mentor. Ele não só aponta erros, mas sugere formas mais idiomáticas ("Rustacean") de escrever seu código.

cargo clippy

Ele vai te dizer: "Ei, você está usando um loop for aqui, mas um iterator seria mais rápido e legível. Tente assim..."

7. Correções Automáticas (`cargo fix`)

Complementando o Clippy, o cargo fix pode aplicar automaticamente muitas das sugestões e correções que o Clippy (e o próprio compilador) identificam. Isso transforma warnings em ações concretas, economizando tempo e garantindo que seu código esteja sempre em conformidade com as melhores práticas da linguagem.

cargo fix --edition

8. Documentação Automática (`cargo doc`)

cargo doc --open

Esse comando gera um site estático com a documentação de todas as suas dependências e do seu próprio código, offline, navegável e padronizado. É mágico.

Por que isso importa?

A padronização do Cargo elimina a fadiga de decisão.
Em vez de gastar energia configurando ferramentas, você gasta energia resolvendo o problema do seu negócio.

Se você entrar em um projeto Rust open-source hoje, seja ele pequeno ou gigante (como o kernel do Linux ou o próprio compilador do Rust), você sabe exatamente como rodar, testar e documentar: cargo run, cargo test, cargo doc.

Essa consistência cria uma comunidade mais coesa e produtiva. Enquanto outras stacks tentam reinventar a roda a cada 6 meses com uma nova ferramenta de build "revolucionária", a comunidade Rust continua aprimorando o Cargo, que já é excelente há anos.

Conclusão

O Cargo não é perfeito, mas é o mais próximo que temos de uma "experiência de desenvolvedor ideal" em linguagens de sistema. Ele prova que uma linguagem difícil de aprender não precisa ter um tooling difícil de usar. Pelo contrário: o tooling do Rust é tão bom que muitas vezes ele te ensina a linguagem.

Se você está cansado de configurar Webpack, brigar com ambientes virtuais Python ou configurar o PHPUnit xml, dê uma chance ao Rust. O Cargo vai te mal acostumar.

Benchmarks

Recurso / Ferramenta	Cargo (Rust)	npm/Yarn/pnpm (JS)	Composer (PHP)	Pip (Python)	Pipenv (Python)	uv (Python)
Gerenciador de Pacotes	✅	✅	✅	✅	✅	✅
Sistema de Build	✅	❌²	❌	❌	❌	❌
Executor de Testes	✅	❌²	❌²	❌²	❌²	❌²
Gerador de Documentação	✅	❌²	❌	❌	❌	❌
Linter/Formatador	✅	❌²	❌²	❌²	❌²	❌²
Ambientes Virtuais	❌¹	❌¹	❌¹	❌¹	✅	✅
Resolução de Dependências	✅✅³	✅	✅	✅	✅	✅✅³
Linguagem Principal	Rust	JavaScript	PHP	Python	Python	Python

¹: Não é um conceito diretamente comparável ou necessário para a linguagem da mesma forma. No JS, node_modules local serve a um propósito similar.
²: Ferramenta externa usualmente orquestrada por scripts ou outras ferramentas.
³: Um duplo ✅ indica um sistema de resolução de dependências mais robusto e determinístico, frequentemente com um algoritmo de satisfação de booleanos (SAT solver) que garante que todas as dependências sejam resolvidas para uma única versão compatível, mesmo em grafos complexos.

Quer experimentar esse poder na prática?

No livro "Desbravando Rust", dedicamos capítulos inteiros para explorar o ecossistema do Cargo, ensinando não só a sintaxe da linguagem, mas como usar essas ferramentas para criar software robusto, testado e documentado desde o primeiro dia.

Garanta seu exemplar e pare de brigar com configurações!

[pt-BR] Pandas vs Polars: Benchmark com 3 Milhões de Registros

Jose Luis da Cruz Junior — Tue, 21 Jul 2026 11:00:00 +0000

Por @zejuniortdr em Nov 21, 2025

Recentemente caiu na minha timeline um vídeo do Lewis apresentando um pacote do python que ele classificou como incrível:

O pacote em questão é o Polars. Como o próprio site oficial diz:

Polars is an open-source library for data manipulation, known for being one of the fastest data processing solutions on a single machine. It features a well-structured, typed API that is both expressive and easy to use.

E como ele consegue ser tão incrível e apresentar resultados tão absurdos? É escrito em Rust 🦀.

Este artigo nasceu da inspiração sobre o tema depois de uma aula de Pandas com o Rafael Dias e da provocação da Amanda Ozava que lembrou bem quando compartilhei com ela o vídeo acima.

Dado ambos com mais experiência que eu no assunto, achei por bem citá-los aqui e pedir para que fizessem uma revisão no material que compartilharei abaixo.

Meu primeiro contato com o Pandas foi em um Nano Degree da Udacity:
Programming for Data Science with Python e de lá para cá não tive muita oportunidade de usá-lo. O material abaixo é fruto de uma pesquisa ao longo de alguns dias (desde a talk do Rafa), obviamente com algum viés para o bench entre os dois pacotes.

O que são DataFrames?

Se você já trabalhou com planilhas do Excel ou Google Sheets, você já conhece o conceito de DataFrame sem saber. Um DataFrame é basicamente uma tabela de dados com:

Linhas: cada linha representa um registro (como uma linha na planilha)
Colunas: cada coluna representa um atributo ou campo (como uma coluna na planilha)
Tipos de dados: cada coluna tem um tipo específico (números, texto, datas, etc.)

A diferença é que DataFrames são projetados para:

Processar milhões de linhas de forma eficiente
Realizar operações complexas em poucos comandos
Integrar-se com ferramentas de análise de dados e machine learning

Pandas tem sido a biblioteca padrão para isso em Python desde 2008. Polars é o novo competidor que promete fazer tudo isso, só que muito mais rápido.

Semelhanças: O Território Comum

Antes de falarmos das diferenças, é importante entender que ambas as bibliotecas compartilham os mesmos conceitos fundamentais:

Estruturas de Dados

DataFrames: Estruturas tabulares bidimensionais com linhas e colunas
Series: Estruturas unidimensionais representando uma única coluna
Operações vetorizadas: Em vez de processar um dado por vez (como um loop), processam lotes inteiros de dados de uma só vez
Suporte a diversos formatos: CSV, Parquet, JSON, Excel e outros

Operações Comuns
As operações fundamentais são suportadas por ambas:

Filtros e seleções: Escolher linhas e colunas específicas
Agregações: Somar, calcular médias, contar elementos, etc.
Joins e merges: Combinar dados de múltiplas tabelas
Transformações: Criar novas colunas baseadas em cálculos
Agrupamentos: Agrupar dados por categorias e aplicar operações

Exemplo Equivalente - Filtro Simples

#Pandas
pythondf_filtrado = df[df['quantidade'] > 5]

# Polars
pythondf_filtrado = df.filter(pl.col('quantidade') > 5)

Ambas fazem a mesma coisa: filtram as linhas onde a coluna 'quantidade' é maior que 5. A sintaxe é um pouco diferente, mas o conceito é idêntico.

Diferenças: Onde Polars se Destaca

Agora vamos ao que realmente interessa: o que torna Polars tão especial? As diferenças vão muito além da sintaxe.

1. Linguagem de Implementação: A Base de Tudo

Aqui está o grande diferencial:

Pandas:

Construído sobre NumPy, que tem seu núcleo escrito em C
Limitado pelo GIL (Global Interpreter Lock) do Python - uma trava que impede que múltiplas threads Python executem ao mesmo tempo
Sofre com overhead (custo adicional) ao lidar com tipos Python, especialmente strings

Polars:

Escrito completamente em Rust 🦀
Performance próxima de C/C++, mas com segurança de memória garantida
Sem limitações do GIL - paralelização nativa e verdadeira
Gerenciamento de memória eficiente e sem overhead.

Impacto visível: Polars é 5-10x mais rápido em operações comuns. Em alguns casos específicos, pode ser até 100x mais rápido.

2. Modelo de Execução: Eager vs Lazy

Esta é uma das diferenças mais importantes e que mais impacta a performance.

Pandas - Eager Execution (Execução Imediata)
Pandas executa cada operação imediatamente, na ordem em que você escreve:

df.assign(nova_col=lambda x: x['a'] * 2)     # Executa agora
  .query('quantidade > 100')                 # Depois executa isso
  .groupby('categoria').mean()               # Por último isso

O problema: ele processa todos os dados primeiro, para depois filtrar. É como preparar um banquete completo para depois descobrir que só 10% dos convidados apareceram.

Polars - Lazy + Eager Execution (Execução Preguiçosa + Imediata)
Polars oferece dois modos:

Modo Eager (padrão): Similar ao Pandas, executa imediatamente
Modo Lazy (recomendado): Constrói um plano de execução e otimiza antes de executar

df.lazy()                                        # Entra em modo lazy
  .with_columns((pl.col('a') * 2).alias('nova_col'))
  .filter(pl.col('quantidade') > 100)            # Ainda não executou nada
  .group_by('categoria').mean()
  .collect()                                     # AGORA executa tudo otimizado

O que Polars faz nos bastidores:

Reordena operações: Aplica filtros ANTES de fazer cálculos pesados
Elimina redundâncias: Remove cálculos que não serão usados
Otimiza memória: Processa apenas o necessário
Paraleliza: Divide o trabalho entre múltiplos núcleos

É como ter um assistente inteligente que reorganiza sua lista de tarefas para fazer tudo mais rápido.

3. Sintaxe e Estilo de Código

Pandas - Flexível Demais

Pandas é muito flexível, o que pode ser bom para iniciantes, mas ruim para manutenção:

# Múltiplas formas de fazer a mesma coisa:
df[df['a'] > 5]
df.query('a > 5')
df.loc[df['a'] > 5]

Para operações complexas, você frequentemente precisa usar .apply() com lambdas (funções anônimas), que são lentas porque processam linha por linha:

# Operação condicional com .mask()
df.assign(a=lambda df_: df_['a'].mask(df_['c'] == 2, df_['b']))

# Apply sequencial (lento!)
df['resultado'] = df.apply(lambda row: complexa_func(row), axis=1)

Polars - Consistente e Expressivo

Polars usa uma API baseada em expressões e contextos. Tudo é mais consistente:

# Operação condicional clara
df.with_columns(
    pl.when(pl.col('c') == 2)
    .then(pl.col('b'))
    .otherwise(pl.col('a'))
    .alias('a')
)

# Operação nativa e paralela (rápida!)
df.with_columns(
    pl.col('valores').map_elements(complexa_func)  # Automaticamente paralelizado
)

A sintaxe de Polars pode parecer mais verbosa no início, mas é:

Mais explícita: Fica claro o que está acontecendo
Mais consistente: Sempre usa o mesmo padrão
Mais rápida: Evita loops implícitos

4. Paralelização e Concorrência

Pandas - Praticamente Single-Threaded

Pandas roda majoritariamente em um único núcleo do seu processador:

# Pandas opera majoritariamente em um único núcleo, exceto por algumas operações vetorizadas que podem usar paralelismo interno do NumPy.
df.groupby('categoria')['valor'].sum()

Por quê? Por causa do GIL (Global Interpreter Lock) do Python. É como ter um carro de 8 cilindros, mas só poder usar 1 de cada vez.

Para ter paralelismo real em Pandas, você precisa de bibliotecas externas como:

Dask: Pandas paralelo para datasets grandes
Modin: Drop-in replacement que paraleliza Pandas
Ray: Framework de computação distribuída

Polars - Paralelização Nativa

Polars usa todos os núcleos disponíveis automaticamente:

# Usa todos os núcleos automaticamente
df.group_by('categoria').agg(pl.col('valor').sum())

Além disso, Polars usa SIMD (Single Instruction, Multiple Data) - uma tecnologia que permite processar múltiplos valores com uma única instrução do processador. É como ter um supermercado com múltiplos caixas, todos trabalhando simultaneamente.

Pandas também usa SIMD em algumas operações via NumPy. Exemplo: operações vetorizadas:

df["price_with_tax"] = df["price"] * 1.12

5. Tipos de Dados e Strictness

Pandas - Loose Typing (Tipagem Flexível)

Pandas faz conversões automáticas de tipos, o que pode parecer conveniente, mas gera bugs silenciosos:

df = pd.DataFrame({'valores': [1, 2, 3, 4, 5]})
print(df['valores'].dtype)  # int64

df.loc[5] = [None]  # Adiciona um valor None
print(df['valores'].dtype)  # float64 (converteu TODA a coluna!)

O que aconteceu? Ao adicionar um None (que representa ausência de valor), Pandas converteu toda a coluna de inteiros para floats, porque inteiros não podem representar valores ausentes nativamente.

Polars - Strict Typing (Tipagem Estrita)

Polars é rigoroso com tipos e te força a ser explícito:

df = pl.DataFrame({'valores': [1, 2, 3, 4, 5]})

# Isso dá erro!
df.extend(pl.DataFrame({'valores': [None]}))
# Error: type mismatch

# Forma correta - seja explícito
df.extend(pl.DataFrame({'valores': [pl.Null]}))  # OK com tipo correto

Por que isso é bom? Porque erros explícitos são melhores que bugs silenciosos. Você descobre o problema imediatamente, não depois de horas de depuração.

6. Uso de Memória

Pandas - Guloso com RAM

Pandas requer 5-10x o tamanho do dataset em memória RAM:

Copia dados frequentemente entre operações
Não tem suporte nativo para datasets maiores que a memória
Precisa carregar tudo na RAM de uma vez

Se você tem um arquivo CSV de 1GB, pode precisar de 10GB de RAM para processá-lo com Pandas.

Polars - Eficiente e com Streaming

Polars requer apenas 2-4x o tamanho do dataset:

Usa zero-copy operations sempre que possível (reutiliza dados sem copiar)
Suporte nativo a streaming para datasets maiores que a RAM
Processa dados em chunks (pedaços) quando necessário

# Processar arquivo maior que a memória disponível
pl.scan_csv('arquivo_gigante.csv')           # Não carrega tudo
  .filter(pl.col('data') > '2024-01-01')     # Filtra durante a leitura
  .group_by('categoria')
  .agg(pl.col('valor').sum())
  .sink_csv('resultado.csv')                 # Streaming! Não sobrecarrega RAM

Com Polars, você pode processar arquivos de 50GB em uma máquina com 8GB de RAM.

7. Operações Complexas: Apply vs Expressões Nativas

Pandas - Dependente de `.apply()`

Para operações complexas, Pandas frequentemente te força a usar .apply(), que é lento:

# Loop implícito - processa linha por linha
df['novo'] = df.apply(
    lambda row: row['a'] * row['b'] if row['c'] > 10 else 0,
    axis=1
)

O .apply() é lento porque:

Itera linha por linha (perde vetorização)
Tem overhead do Python para cada linha
Não pode ser paralelizado facilmente

Polars - Métodos Nativos para Tudo

Polars tem métodos nativos (escritos em Rust) para praticamente tudo:

# Operação vetorizada e paralela
df.with_columns(
    pl.when(pl.col('c') > 10)
    .then(pl.col('a') * pl.col('b'))
    .otherwise(0)
    .alias('novo')
)

Por ser nativo em Rust:

Vetorizado: Processa múltiplas linhas de uma vez
Paralelizado: Usa múltiplos núcleos automaticamente
Zero overhead: Sem custo adicional do Python

8. Ecossistema e Maturidade

Pandas - Maduro e Integrado

Vantagens:

Maturidade: Desde 2008, extremamente estável
Ecossistema rico: Integração profunda com scikit-learn, matplotlib, seaborn, statsmodels
Documentação extensa: Milhares de tutoriais e respostas no Stack Overflow
Comunidade gigante: Fácil encontrar ajuda

Quando usar: Se você precisa de integração imediata com ferramentas de machine learning.

Polars - Novo mas Crescendo Rápido

Situação atual:

Maturidade: Desde 2020, mas já muito estável
Crescimento acelerado: Comunidade crescendo exponencialmente
Interoperabilidade: Fácil converter para Pandas quando necessário

# Usar Polars para processamento pesado
df_polars = pl.DataFrame({'a': [1, 2, 3, 4, 5]})

# Converter para Pandas quando precisar de scikit-learn
df_pandas = df_polars.to_pandas()
model.fit(df_pandas)

# E vice-versa
df_polars_novamente = pl.from_pandas(df_pandas)

Tendência: Cada vez mais bibliotecas estão adicionando suporte direto a Polars.

Quando Usar Cada Uma?

Use Pandas quando:

Datasets pequenos/médios (< 1GB): Se cabe confortavelmente na memória, Pandas funciona bem;
Prototipagem rápida e exploração: Sintaxe mais familiar para quem está começando e ótimo para análise exploratória em Jupyter notebooks;
Integração profunda com ML: scikit-learn, statsmodels, TensorFlow integram nativamente. Também não quer o overhead de converter dados;
Time já familiarizado: Equipe já domina Pandas e o custo de mudança não se justifica (ainda);

Use Polars quando:

Performance é crítica: Processamento precisa ser rápido e economia de tempo/recursos tem valor significativo;
Datasets grandes (> 1GB): Arquivos de vários gigabytes e precisa processar milhões/bilhões de linhas;
Operações de agregação/groupby pesadas: Para agrupamentos complexos com múltiplas agregações, o Polars pode ser 10-50x mais rápido;
Dados maiores que memória: Suporte nativo a streaming e consegue processar arquivos de 50GB com 8GB de RAM;
Código em produção que precisa escalar: Aplicações que rodam frequentemente, custos de infraestrutura importam e/ou desempenho impacta experiência do usuário;

Exemplos Práticos: Comparando as Três Abordagens

Toda essa parte teórica com exemplos simples foram para criar uma fundação mínima de conhecimento para quem nunca viu algum destes pacotes e conseguirmos seguir na parte que realmente importa deste artigo.

Não é que eu duvide do Lewis, mas por se tratar de números tão absurdos, resolvi testar reproduzindo o mesmo cenário que ele criou: processar três milhões de linhas de um arquivo CSV com ambas e para cereja do bolo, resolvi fazer um teste apelativo para ver se traria muita diferença. Também inclui neste benchmark processar o mesmo arquivo com Rust + Polars.

Para gerar esse arquivo inicial, utilizei o seguinte script em python:

import csv
import random
from datetime import datetime, timedelta
from pathlib import Path

def generate_sales_data(num_records=3_000_000, output_file="data/sales_data.csv"):
    """Gera dados sintéticos de vendas"""
    Path("data").mkdir(exist_ok=True)

    products = ["Laptop", "Mouse", "Keyboard", "Monitor", "Headset",
                "Webcam", "SSD", "RAM", "GPU", "CPU"]
    categories = ["Electronics", "Accessories", "Components"]
    regions = ["North", "South", "East", "West", "Central"]

    start_date = datetime(2023, 1, 1)

    print(f"Gerando {num_records:,} registros...")

    with open(output_file, 'w', newline='', encoding='utf-8') as f:
        writer = csv.writer(f)
        writer.writerow([
            'id', 'date', 'product', 'category', 'region',
            'quantity', 'price', 'discount', 'customer_id'
        ])

        for i in range(num_records):
            date = start_date + timedelta(days=random.randint(0, 730))
            product = random.choice(products)
            category = random.choice(categories)
            region = random.choice(regions)
            quantity = random.randint(1, 20)
            price = round(random.uniform(10, 2000), 2)
            discount = round(random.uniform(0, 0.3), 2)
            customer_id = random.randint(1, 50000)

            writer.writerow([
                i, date.strftime('%Y-%m-%d'), product, category,
                region, quantity, price, discount, customer_id
            ])

            if (i + 1) % 500_000 == 0:
                print(f"  {i + 1:,} registros gerados...")

    print(f"✓ Arquivo gerado: {output_file}")

if __name__ == "__main__":
    generate_sales_data()

Com as seguintes dependências:

pandas = "==2.3.3"
polars-lts-cpu = "==1.33.1"
psutil = "==7.1.3"

Exemplo 1: Python + Pandas

Para o bench para este cenário, foi utilizado o seguinte script:

import pandas as pd
import time
import psutil
import os
from pathlib import Path

def get_memory_usage():
    """Retorna uso de memória em MB"""
    process = psutil.Process(os.getpid())
    return process.memory_info().rss / (1024 * 1024)

def benchmark_pandas():
    Path("results").mkdir(exist_ok=True)

    metrics = {
        'library': 'Pandas',
        'operations': {},
        'total_time': 0,
        'peak_memory_mb': 0
    }

    initial_memory = get_memory_usage()
    start_total = time.time()

    # 1. LEITURA
    print("1. Lendo CSV...")
    start = time.time()
    df = pd.read_csv('data/sales_data.csv')
    read_time = time.time() - start
    metrics['operations']['read_csv'] = read_time
    print(f"   Tempo: {read_time:.2f}s | Memória: {get_memory_usage():.2f} MB")

    # 2. FILTROS
    print("2. Aplicando filtros...")
    start = time.time()
    filtered = df[(df['quantity'] > 5) & (df['price'] > 100)]
    filter_time = time.time() - start
    metrics['operations']['filter'] = filter_time
    print(f"   Tempo: {filter_time:.2f}s | Registros: {len(filtered):,}")

    # 3. AGREGAÇÕES
    print("3. Agregações (groupby)...")
    start = time.time()
    agg_result = df.groupby(['region', 'category']).agg({
        'quantity': 'sum',
        'price': 'mean',
        'id': 'count'
    }).reset_index()
    agg_time = time.time() - start
    metrics['operations']['aggregation'] = agg_time
    print(f"   Tempo: {agg_time:.2f}s | Grupos: {len(agg_result):,}")

    # 4. TRANSFORMAÇÕES
    print("4. Transformações de colunas...")
    start = time.time()
    df['total_price'] = df['quantity'] * df['price'] * (1 - df['discount'])
    df['year'] = pd.to_datetime(df['date']).dt.year
    transform_time = time.time() - start
    metrics['operations']['transform'] = transform_time
    print(f"   Tempo: {transform_time:.2f}s")

    # 5. JOINS
    print("5. Join de dataframes...")
    start = time.time()
    summary = df.groupby('customer_id')['total_price'].sum().reset_index()
    summary.columns = ['customer_id', 'total_spent']
    joined = df.merge(summary, on='customer_id', how='left')
    join_time = time.time() - start
    metrics['operations']['join'] = join_time
    print(f"   Tempo: {join_time:.2f}s")

    # 6. ESCRITA
    print("6. Escrevendo resultado...")
    start = time.time()
    top_customers = joined.groupby('customer_id')['total_spent'].first()\
        .sort_values(ascending=False).head(1000)
    top_customers.to_csv('results/pandas_top_customers.csv')
    write_time = time.time() - start
    metrics['operations']['write_csv'] = write_time
    print(f"   Tempo: {write_time:.2f}s")

    # MÉTRICAS FINAIS
    total_time = time.time() - start_total
    peak_memory = get_memory_usage()

    metrics['total_time'] = total_time
    metrics['peak_memory_mb'] = peak_memory - initial_memory

    print(f"\n{'='*50}")
    print(f"PANDAS - Tempo total: {total_time:.2f}s")
    print(f"PANDAS - Memória pico: {peak_memory - initial_memory:.2f} MB")
    print(f"{'='*50}\n")

    # Salvar métricas
    import json
    with open('results/pandas_metrics.json', 'w') as f:
        json.dump(metrics, f, indent=2)

    return metrics

if __name__ == "__main__":
    benchmark_pandas()

Exemplo 2: Python + Polars

Eis o script, também em python processa o mesmo arquivo do exemplo anterior, só que agora com o Polars:

import polars as pl
import time
import psutil
import os
from pathlib import Path

def get_memory_usage():
    process = psutil.Process(os.getpid())
    return process.memory_info().rss / (1024 * 1024)

def benchmark_polars_python():
    Path("results").mkdir(exist_ok=True)

    metrics = {
        'library': 'Polars (Python)',
        'operations': {},
        'total_time': 0,
        'peak_memory_mb': 0
    }

    initial_memory = get_memory_usage()
    start_total = time.time()

    # 1. LEITURA (Lazy)
    print("1. Lendo CSV (lazy)...")
    start = time.time()
    df = pl.scan_csv('data/sales_data.csv')
    read_time = time.time() - start
    metrics['operations']['read_csv'] = read_time
    print(f"   Tempo: {read_time:.4f}s (lazy) | Memória: {get_memory_usage():.2f} MB")

    # 2. FILTROS
    print("2. Aplicando filtros...")
    start = time.time()
    filtered = df.filter(
        (pl.col('quantity') > 5) & (pl.col('price') > 100)
    )
    filter_time = time.time() - start
    metrics['operations']['filter'] = filter_time
    print(f"   Tempo: {filter_time:.4f}s (lazy)")

    # 3. AGREGAÇÕES
    print("3. Agregações (groupby)...")
    start = time.time()
    agg_result = df.group_by(['region', 'category']).agg([
        pl.col('quantity').sum().alias('total_quantity'),
        pl.col('price').mean().alias('avg_price'),
        pl.col('id').count().alias('count')
    ])
    agg_time = time.time() - start
    metrics['operations']['aggregation'] = agg_time
    print(f"   Tempo: {agg_time:.4f}s (lazy)")

    # 4. TRANSFORMAÇÕES
    print("4. Transformações de colunas...")
    start = time.time()
    df = df.with_columns([
        (pl.col('quantity') * pl.col('price') * (1 - pl.col('discount')))
            .alias('total_price'),
        pl.col('date').str.strptime(pl.Date, '%Y-%m-%d').dt.year().alias('year')
    ])
    transform_time = time.time() - start
    metrics['operations']['transform'] = transform_time
    print(f"   Tempo: {transform_time:.4f}s (lazy)")

    # 5. JOINS
    print("5. Join de dataframes...")
    start = time.time()
    summary = df.group_by('customer_id').agg(
        pl.col('total_price').sum().alias('total_spent')
    )
    joined = df.join(summary, on='customer_id', how='left')
    join_time = time.time() - start
    metrics['operations']['join'] = join_time
    print(f"   Tempo: {join_time:.4f}s (lazy)")

    # 6. EXECUÇÃO + ESCRITA
    print("6. Executando query e escrevendo resultado...")
    start = time.time()
    top_customers = (joined
        .group_by('customer_id')
        .agg(pl.col('total_spent').first())
        .sort('total_spent', descending=True)
        .head(1000)
        .collect()  # Aqui executa tudo!
    )
    top_customers.write_csv('results/polars_python_top_customers.csv')
    write_time = time.time() - start
    metrics['operations']['write_csv'] = write_time
    print(f"   Tempo: {write_time:.2f}s (execução + escrita)")

    # MÉTRICAS FINAIS
    total_time = time.time() - start_total
    peak_memory = get_memory_usage()

    metrics['total_time'] = total_time
    metrics['peak_memory_mb'] = peak_memory - initial_memory

    print(f"\n{'='*50}")
    print(f"POLARS (Python) - Tempo total: {total_time:.2f}s")
    print(f"POLARS (Python) - Memória pico: {peak_memory - initial_memory:.2f} MB")
    print(f"{'='*50}\n")

    import json
    with open('results/polars_python_metrics.json', 'w') as f:
        json.dump(metrics, f, indent=2)

    return metrics

if __name__ == "__main__":
    benchmark_polars_python()

Exemplo 3: Rust + Polars

E por fim mas não menos importante, o exemplo em Rust com Polars que é praticamente uma F1 nessa corrida de velotrol:

use polars::prelude::*;
use std::time::Instant;
use std::fs;
use sysinfo::System;

fn get_memory_usage() -> f64 {
    let mut sys = System::new_all();
    sys.refresh_memory();
    sys.used_memory() as f64 / (1024.0 * 1024.0)
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    fs::create_dir_all("results")?;

    let initial_memory = get_memory_usage();
    let start_total = Instant::now();

    // 1. LEITURA (Lazy)
    println!("1. Lendo CSV (lazy)...");
    let start = Instant::now();
    let df = LazyCsvReader::new("data/sales_data.csv")
        .with_has_header(true)
        .finish()?;
    let read_time = start.elapsed();
    println!("   Tempo: {:?} (lazy) | Memória: {:.2} MB", read_time, get_memory_usage());

    // 2. FILTROS
    println!("2. Aplicando filtros...");
    let start = Instant::now();
    let _filtered = df.clone().filter(
        col("quantity").gt(lit(5))
            .and(col("price").gt(lit(100.0)))
    );
    let filter_time = start.elapsed();
    println!("   Tempo: {:?} (lazy)", filter_time);

    // 3. AGREGAÇÕES
    println!("3. Agregações (groupby)...");
    let start = Instant::now();
    let _agg_result = df.clone()
        .group_by([col("region"), col("category")])
        .agg([
            col("quantity").sum().alias("total_quantity"),
            col("price").mean().alias("avg_price"),
            col("id").count().alias("count"),
        ]);
    let agg_time = start.elapsed();
    println!("   Tempo: {:?} (lazy)", agg_time);

    // 4. TRANSFORMAÇÕES
    println!("4. Transformações de colunas...");
    let start = Instant::now();
    let df = df.with_columns([
        (col("quantity") * col("price") * (lit(1.0) - col("discount")))
            .alias("total_price"),
    ]);
    let transform_time = start.elapsed();
    println!("   Tempo: {:?} (lazy)", transform_time);

    // 5. JOINS
    println!("5. Join de dataframes...");
    let start = Instant::now();
    let summary = df.clone()
        .group_by([col("customer_id")])
        .agg([col("total_price").sum().alias("total_spent")]);

    let joined = df.join(
        summary,
        [col("customer_id")],
        [col("customer_id")],
        JoinArgs::new(JoinType::Left),
    );
    let join_time = start.elapsed();
    println!("   Tempo: {:?} (lazy)", join_time);

    // 6. EXECUÇÃO + ESCRITA
    println!("6. Executando query e escrevendo resultado...");
    let start = Instant::now();
    let top_customers = joined
        .group_by([col("customer_id")])
        .agg([col("total_spent").first()])
        .sort(
            ["total_spent"],
            SortMultipleOptions::default().with_order_descending(true),
        )
        .limit(1000)
        .collect()?; // Executa aqui!

    let mut file = std::fs::File::create("results/polars_rust_top_customers.csv")?;
    CsvWriter::new(&mut file)
        .include_header(true)
        .finish(&mut top_customers.clone())?;

    let write_time = start.elapsed();
    println!("   Tempo: {:?} (execução + escrita)", write_time);

    // MÉTRICAS FINAIS
    let total_time = start_total.elapsed();
    let peak_memory = get_memory_usage() - initial_memory;

    println!("\n{}", "=".repeat(50));
    println!("POLARS (Rust) - Tempo total: {:.2?}", total_time);
    println!("POLARS (Rust) - Memória pico: {:.2} MB", peak_memory);
    println!("{}\n", "=".repeat(50));

    // Salvar métricas
    let metrics = format!(
        r#"{{
  "library": "Polars (Rust)",
  "total_time": {:.2},
  "peak_memory_mb": {:.2}
}}"#,
        total_time.as_secs_f64(),
        peak_memory
    );

    fs::write("results/polars_rust_metrics.json", metrics)?;

    Ok(())
}

Resultados

Cada um dos exemplos acima foram executados na mesma máquina do post Performance na prática: Um exemplo de real onde o Axum supera o FastAPI, e criei um script em python para analisar as saídas geradas na pasta results/:

import json
import pandas as pd
from pathlib import Path

def compare_results():
    results_dir = Path("results")

    # Carregar métricas
    with open(results_dir / "pandas_metrics.json") as f:
        pandas_data = json.load(f)

    with open(results_dir / "polars_python_metrics.json") as f:
        polars_py_data = json.load(f)

    with open(results_dir / "polars_rust_metrics.json") as f:
        polars_rust_data = json.load(f)

    # Criar tabela comparativa
    comparison = pd.DataFrame({
        'Biblioteca': [
            pandas_data['library'],
            polars_py_data['library'],
            polars_rust_data['library']
        ],
        'Tempo Total (s)': [
            f"{pandas_data['total_time']:.2f}",
            f"{polars_py_data['total_time']:.2f}",
            f"{polars_rust_data['total_time']:.2f}"
        ],
        'Memória Pico (MB)': [
            f"{pandas_data['peak_memory_mb']:.2f}",
            f"{polars_py_data['peak_memory_mb']:.2f}",
            f"{polars_rust_data['peak_memory_mb']:.2f}"
        ]
    })

    print("\n" + "="*60)
    print("COMPARAÇÃO FINAL: Pandas vs Polars (Python) vs Polars (Rust)")
    print("="*60)
    print(comparison.to_string(index=False))
    print("="*60)

    # Calcular speedup
    pandas_time = pandas_data['total_time']
    polars_py_time = polars_py_data['total_time']
    polars_rust_time = polars_rust_data['total_time']

    print(f"\nSPEEDUP:")
    print(f"  Polars (Python) vs Pandas: {pandas_time/polars_py_time:.2f}x mais rápido")
    print(f"  Polars (Rust) vs Pandas: {pandas_time/polars_rust_time:.2f}x mais rápido")
    print(f"  Polars (Rust) vs Polars (Python): {polars_py_time/polars_rust_time:.2f}x mais rápido")

    print(f"\nREDUÇÃO DE MEMÓRIA:")
    pandas_mem = pandas_data['peak_memory_mb']
    polars_py_mem = polars_py_data['peak_memory_mb']
    polars_rust_mem = polars_rust_data['peak_memory_mb']

    print(f"  Polars (Python) vs Pandas: {((pandas_mem-polars_py_mem)/pandas_mem*100):.1f}% menos memória")
    print(f"  Polars (Rust) vs Pandas: {((pandas_mem-polars_rust_mem)/pandas_mem*100):.1f}% menos memória")
    print()

if __name__ == "__main__":
    compare_results()

Eis os números:

Para facilitar a execução de todos e coletar principalmente os picos de consumo de cpu e e memória de uma forma fácil, utilizei o seguinte Makefile:

bench:
    echo "============================================"
    echo "Python + Pandas"
    python scripts/2_benchmark_pandas.py
    echo "============================================"
    sleep 15

    echo "============================================"
    echo "Python + Polars"
    python scripts/2_benchmark_pandas.py
    echo "============================================"
    sleep 15

    echo "============================================"
    echo "Rust + Polars"
    ./target/release/pandas-vs-polars
    echo "============================================"
    sleep 15

    echo "Resultados"
    python scripts/5_compare_results.py

Depois de rodar o primeiro script para gerar o arquivo, simplesmente rodei esse bench, com intervalos de 15s entre cada um para mapear os picos. Os números foram surpreendentes:

➜  make bench
echo "============================================"
============================================
echo "Python + Pandas"
Python + Pandas
python scripts/2_benchmark_pandas.py
1. Lendo CSV...
   Tempo: 2.56s | Memória: 302.78 MB
2. Aplicando filtros...
   Tempo: 0.12s | Registros: 2,148,184
3. Agregações (groupby)...
   Tempo: 0.33s | Grupos: 15
4. Transformações de colunas...
   Tempo: 0.58s
5. Join de dataframes...
   Tempo: 0.37s
6. Escrevendo resultado...
   Tempo: 0.07s

==================================================
PANDAS - Tempo total: 4.05s
PANDAS - Memória pico: 782.25 MB
==================================================

echo "============================================"
============================================
sleep 15
echo "============================================"
============================================
echo "Python + Polars"
Python + Polars
python scripts/2_benchmark_pandas.py
1. Lendo CSV...
   Tempo: 2.49s | Memória: 302.79 MB
2. Aplicando filtros...
   Tempo: 0.12s | Registros: 2,148,184
3. Agregações (groupby)...
   Tempo: 0.35s | Grupos: 15
4. Transformações de colunas...
   Tempo: 0.53s
5. Join de dataframes...
   Tempo: 0.37s
6. Escrevendo resultado...
   Tempo: 0.07s

==================================================
PANDAS - Tempo total: 3.93s
PANDAS - Memória pico: 782.39 MB
==================================================

echo "============================================"
============================================
sleep 15
echo "============================================"
============================================
echo "Rust + Polars"
Rust + Polars
./target/release/pandas-vs-polars
1. Lendo CSV (lazy)...
   Tempo: 23.295µs (lazy) | Memória: 2659.56 MB
2. Aplicando filtros...
   Tempo: 206.271µs (lazy)
3. Agregações (groupby)...
   Tempo: 13.338µs (lazy)
4. Transformações de colunas...
   Tempo: 4.626µs (lazy)
5. Join de dataframes...
   Tempo: 14.751µs (lazy)
6. Executando query e escrevendo resultado...
   Tempo: 618.259553ms (execução + escrita)

==================================================
POLARS (Rust) - Tempo total: 634.52ms
POLARS (Rust) - Memória pico: 312.22 MB
==================================================

echo "============================================"
============================================
sleep 15
echo "Resultados"
Resultados
python scripts/5_compare_results.py

============================================================
COMPARAÇÃO FINAL: Pandas vs Polars (Python) vs Polars (Rust)
============================================================
     Biblioteca Tempo Total (s) Memória Pico (MB)
         Pandas            3.93            782.39
Polars (Python)            0.35            311.11
  Polars (Rust)            0.63            312.22
============================================================

SPEEDUP:
  Polars (Python) vs Pandas: 11.08x mais rápido
  Polars (Rust) vs Pandas: 6.24x mais rápido
  Polars (Rust) vs Polars (Python): 0.56x mais rápido

REDUÇÃO DE MEMÓRIA:
  Polars (Python) vs Pandas: 60.2% menos memória
  Polars (Rust) vs Pandas: 60.1% menos memória

Conclusão

Quando comecei este artigo, prometi mostrar por que Polars está revolucionando o processamento de dados. Os números não mentem - e eles são ainda mais impressionantes do que esperava.

Os Resultados em Números

Processando 3 milhões de registros com operações reais (filtros, agregações, transformações e joins), foi obtido:

Python + Pandas:

Tempo total: 3.93 segundos
Memória pico: 782.39 MB

Python + Polars:

Tempo total: 0.35 segundos → 11.08x mais rápido
Memória pico: 311.11 MB → 60.2% menos memória

Rust + Polars:

Tempo total: 0.63 segundos → 6.24x mais rápido
Memória pico: 312.22 MB → 60.1% menos memória

O Que Esses Números Significam?

1. Polars é Consistentemente Mais Rápido

Com 11x de ganho de performance, Polars em Python transformou uma operação que levava quase 4 segundos em apenas 0.35 segundos. Em termos práticos:

Uma análise que levava 10 minutos agora leva menos de 1 minuto
Um pipeline que rodava em 1 hora agora termina em 5 minutos
Processamentos noturnos de 8 horas podem ser reduzidos para menos de 1 hora

2. Eficiência de Memória é Revolucionária

A redução de 60% no uso de memória não é apenas um número - é a diferença entre:

Precisar de uma máquina com 32GB vs 16GB de RAM
Conseguir processar datasets 2-3x maiores na mesma infraestrutura
Reduzir custos de nuvem significativamente em ambientes de produção

3. Lazy Evaluation é Magia Pura

Observe os tempos do Rust + Polars:

1. Lendo CSV (lazy)...          23.295µs (0.000023 segundos!)
2. Aplicando filtros...         206.271µs (0.0002 segundos!)
3. Agregações (groupby)...      13.338µs (0.000013 segundos!)
4. Transformações de colunas... 4.626µs (0.000004 segundos!)
5. Join de dataframes...        14.751µs (0.000014 segundos!)
6. Execução + escrita...        618.259ms (0.618 segundos)

As operações 1-5 levaram microsegundos porque Polars apenas construiu o plano de execução - não processou nada ainda. Quando finalmente executou (operação 6), fez tudo de uma vez, otimizado.

É como ter um assistente que anota todas as suas tarefas, reorganiza da forma mais eficiente possível, e então executa tudo de uma vez só.

4. Rust vs Python: Uma Surpresa Interessante

Curiosamente, Polars em Python foi mais rápido (0.35s) que em Rust puro (0.63s) no tempo total. Por quê? A maior parte do tempo do Rust foi gasto na escrita final do arquivo (618ms). As operações de processamento em si foram absurdamente rápidas em ambos.
Isso nos ensina algo importante: para a maioria dos casos de uso, Polars em Python já é mais que suficiente. Você não precisa migrar para Rust para ter ganhos extraordinários de performance.

O Veredicto Final

Polars não é hype - é uma mudança de paradigma.
Se você trabalha com dados e ainda usa apenas Pandas:

Para prototipagem e datasets pequenos: Pandas continua sendo excelente
Para qualquer coisa em produção: Polars deveria ser sua escolha padrão
Para datasets grandes (>1GB): Polars não é opcional, é necessário
Para economia de recursos: 60% menos memória = custos menores

Critério	Pandas	Polars
Performance	Significativamente mais lenta	Extremamente Rápida (11x mais)
Tipagem	Flexível (pode levar a erros)	Estrita (segurança e performance)
Paralelismo	Limitado (single-core padrão)	Nativo (aproveita todos os cores)
Lazy Evaluation	❌ (processamento imediato)	✔ (otimização e eficiência)
Uso de RAM	Alto (782 MB)	Baixo (311 MB, 60% menos)
Streaming	❌ (requer dados em memória)	✔ (via lazy, para datasets grandes)
Ecossistema ML	Excelente (maduro)	Bom (crescendo rapidamente)

A Transição Vale a Pena?

A curva de aprendizado de Polars existe, sim. A sintaxe é diferente, o paradigma de expressões requer uma mudança de mentalidade. Mas os resultados falam por si:

11x mais rápido significa que o tempo que você investe aprendendo Polars se paga na primeira semana de uso
60% menos memória significa infraestrutura mais barata e capacidade de processar datasets maiores
API consistente e expressiva significa código mais limpo e manutenível a longo prazo

O Futuro é Rust, Mas Você Não Precisa Saber Rust

A beleza de Polars é que você colhe todos os benefícios do Rust (velocidade, segurança de memória, paralelização) escrevendo Python. É o melhor dos dois mundos.

E quando você realmente precisar daquele último bit de performance? A transição de Python para Rust com Polars é suave - a API é praticamente idêntica.

Os números provam: Polars entrega o que promete. Não é marketing, não é hype - é engenharia de qualidade resolvendo problemas reais.
Se você processa dados regularmente, especialmente em produção, não é mais uma questão de "devo aprender Polars?" mas sim "quando vou migrar?".

A revolução do processamento de dados já começou. E ela é escrita em Rust 🦀.

Quer Dominar Rust e Entender Como Polars Funciona Por Baixo dos Panos?

Se este artigo despertou sua curiosidade sobre como Polars consegue ser tão rápido, ou se você quer entender por que Rust está revolucionando o mundo da programação, temos algo especial para você.
"Desbravando Rust" é o guia definitivo para quem quer ir além do superficial e realmente dominar a linguagem que está por trás de ferramentas como Polars, Tokio, Servo e tantas outras que estão redefinindo performance e segurança.

O Que Você Vai Aprender:

Fundamentos sólidos: Do zero ao avançado, sem pular etapas essenciais
Performance real: Entenda como Rust elimina o overhead que torna Python lento
Safety sem garbage collector: Como Rust garante segurança de memória em compile-time
Concorrência sem medo: Paralelização nativa sem data races (o que torna Polars tão rápido)
Projetos práticos: Construa aplicações reais, incluindo processamento de dados como vimos neste artigo.

Se os números não mentem e o Polars é 11x mais rápido que Pandas, imagine o que você pode construir quando entende a linguagem que torna isso possível.

[pt-BR] Performance na prática: Um exemplo de real onde o Axum supera o FastAPI

Jose Luis da Cruz Junior — Tue, 14 Jul 2026 11:00:00 +0000

Por @zejuniortdr em Nov 16, 2025

Qual a stack perfeita para desenvolvimento? Essa é uma pergunta simples porém que trás muitas dúvidas, principalmente para quem está começando e a resposta nem sempre é óbvia: É a que resolve o problema da melhor maneira possível, consumindo menos recursos.

Claro que sempre existirão trade-offs, como por exemplo a curva de aprendizado, que pode ser maior uma determinada linguagem, principalmente quando esta é o Rust devido a sua forma única de trabalhar e as decisões de design da própria linguagem que é bem única em alguns pontos.

Neste post, a ideia é apresentar um exemplo prático onde através de um benchmark simples, é possível ver a diferença entre as duas.

O escopo do projeto

Criar uma API Rest com um único endpoint /api/v1/cep/{cep} que receberá via path param e retornará os dados de endereço do CEP informado. Para otimizar a velocidade e reduzir o acoplamento de um serviço externo, ao invés de depender 100% de uma API de terceiros, primeiro a requisição consultará no banco da própria aplicação, e somente em caso de não encontrar o registro, baterá no terceiro para retornar o dado solicitado e persistir no banco para uma consulta futura.

Ambiente do Execução

Hardware: Intel Core i7-2600K (8 cores) @ 3.80 GHz, 15.56 GiB RAM
Sistema Operacional: EndeavourOS (Arch Linux)
Banco de Dados: PostgreSQL em container Docker
Condições: Mesma máquina, mesma configuração de banco, mesmo padrão de cache

Stack Python:

Python 3.13
FastAPI 0.115.0
Uvicorn com 4 workers
psycopg (driver async)
httpx para requisições HTTP

Stack Rust

Rust 1.90
Axum 0.8.6
Tokio runtime padrão
sqlx para PostgreSQL
reqwest para requisições HTTP

Parâmetros do Teste:

20.000 requisições totais
Concorrência: 50 conexões simultâneas
Sem fase de warmup (cold start)
Padrão de acesso: cache miss inicial → consulta ViaCEP → cache hits subsequentes
Lib responsável para o teste de carga: Dril para ambos.

Resultados Quantitativos

Métrica	FastAPI (Python)	Axum (Rust)	Diferença
Requisições/segundo	1.356,92	2.773,98	2,04x
Tempo total de execução	14,7s	7,2s	2,04x
Tempo mediano	28ms	9ms	3,11x
Tempo médio	36ms	18ms	2,00x
Percentil 99	88ms	42ms	2,09x
Percentil 99.5	103ms	51ms	2,02x
Percentil 99.9	2.048ms	1.901ms	1,08x
Desvio padrão	97ms	96ms	~1,00x
Requisições falhadas	0	0	Ambas 100%

A implementação Rust apresentou throughput duas vezes superior e latência mediana três vezes menor em comparação com a implementação Python.

Análise dos Percentis

Comportamento Típico (Mediana)
A mediana de 9ms para Axum versus 28ms para FastAPI indica que, em condições normais de operação, a implementação Rust responde em aproximadamente um terço do tempo.

Comportamento sob Carga (P99)
O percentil 99 mostra que 99% das requisições da implementação Rust completam em até 42ms, enquanto a implementação Python atinge 88ms. Esta diferença é relevante para aplicações com requisitos de SLA rigorosos.

Casos Extremos (P99.9)
Ambas as implementações apresentam spikes similares no percentil 99.9 (~2 segundos). Este comportamento sugere que os outliers não são causados pelos frameworks, mas provavelmente por contenção no PostgreSQL ou latência externa da API ViaCEP.

Fatores Técnicos de Performance

Modelo de Compilação
Python 3.13 executa bytecode através de um interpretador, mesmo com o JIT experimental que oferece melhorias de 2-9%. Rust compila para código de máquina nativo otimizado, eliminando overhead de interpretação.

Concorrência e Paralelismo
FastAPI com múltiplos workers do Uvicorn distribui carga entre processos, mas cada worker possui seu próprio Global Interpreter Lock (GIL), limitando paralelismo real dentro de cada processo. Rust com Tokio utiliza multi-threading nativo sem restrições de lock global.

Gerenciamento de Memória
Python utiliza garbage collection com pausas imprevisíveis. Rust emprega ownership e borrowing, garantindo segurança de memória em tempo de compilação sem overhead de GC em runtime.

Ecossistema Assíncrono
Ambas as implementações utilizam I/O assíncrono, mas o ecossistema Rust (Tokio + sqlx + reqwest) foi projetado com async como padrão desde a origem, resultando em menor overhead de abstração.

Considerações sobre sqlx
É relevante notar que sqlx não é o driver PostgreSQL mais performático para Rust. Benchmarks do TechEmpower mostram que implementações com tokio-postgres direto alcançam posições significativamente superiores em rankings de performance, devido ao menor overhead de pool de conexões e prepared statements.

Estrutura dos Handlers

Implementação com FastAPI**


@app.get("/api/v1/cep/{cep}")
async def get_cep(cep: str):
    # Limpar CEP (remover hífen)
    cep_limpo = cep.replace("-", "")

    # Validar formato
    if len(cep_limpo) != 8 or not cep_limpo.isdigit():
        raise HTTPException(status_code=400, detail="CEP inválido")

    # Buscar no banco
    async with db_pool.connection() as conn:
        async with conn.cursor(row_factory=dict_row) as cur:
            await cur.execute(
                "SELECT * FROM ceps WHERE cep = %s",
                (cep_limpo,)
            )
            row = await cur.fetchone()

            if row:
                return dict(row)

    # Fallback para ViaCEP
    try:
        response = await http_client.get(f"{VIACEP_URL}/{cep_limpo}/json/")
        response.raise_for_status()
        data = response.json()

        # Verificar se CEP existe
        if "erro" in data:
            raise HTTPException(status_code=404, detail="CEP não encontrado")

        # Salvar no banco
        async with db_pool.connection() as conn:
            async with conn.cursor() as cur:
                await cur.execute("""
                    INSERT INTO ceps (
                        cep, logradouro, complemento, bairro,
                        localidade, uf, ibge, gia, ddd, siafi
                    ) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s)
                    ON CONFLICT (cep) DO NOTHING
                """, (
                    data.get("cep", "").replace("-", ""),
                    data.get("logradouro", ""),
                    data.get("complemento", ""),
                    data.get("bairro", ""),
                    data.get("localidade", ""),
                    data.get("uf", ""),
                    data.get("ibge", ""),
                    data.get("gia", ""),
                    data.get("ddd", ""),
                    data.get("siafi", "")
                ))
                await conn.commit()

        return data

    except httpx.HTTPError as e:
        raise HTTPException(status_code=503, detail=f"Erro ao consultar ViaCEP: {str(e)}")

Características técnicas:

Validação e serialização automática via Pydantic
Type hints opcionais verificados em runtime
Tratamento de exceções com try/except
Syntax concisa e expressiva

Implementação com Axum

pub async fn get_zipcode_handler(
    State(state): State<AppState>,
    Path(cep): Path<String>,
) -> Response {
    dotenv().ok();

    let sanitized_zipcode = match cep_service::validate_cep(&cep) {
        Ok(valid_cep) => valid_cep,
        Err(error_response) => return *error_response,
    };

    let search_zipcode_on_viacep = env::var("SEARCH_ZIPCODE_ON_VIACEP")
        .unwrap_or_else(|_| "false".to_string())
        .to_lowercase()
        == "true";

    let strategy = cep_service::SearchStrategy::WithFallback {
        enable_viacep: search_zipcode_on_viacep
    };

    let result = cep_service::execute_search(&state, &sanitized_zipcode, strategy).await;

    cep_service::search_result_to_response(result, "")
}

Serviço auxiliar

pub async fn execute_search(
        state: &AppState,
        cep: &str,
        strategy: SearchStrategy,
    ) -> SearchResult {
        match strategy {
            SearchStrategy::Single(provider) => match provider {
                Provider::Database => search_in_database(state, cep).await,
                Provider::ViaCep => search_in_viacep(state, cep, Some(false)).await,
            },
            SearchStrategy::WithFallback {
                enable_viacep,
            } => match search_in_database(state, cep).await {
                SearchResult::Found(response) => SearchResult::Found(response),
                SearchResult::Error(err) => SearchResult::Error(err),
                SearchResult::NotFound => {
                    if enable_viacep {
                        match search_in_viacep(state, cep, Some(true)).await {
                            SearchResult::Found(response) => return SearchResult::Found(response),
                            SearchResult::Error(err) => return SearchResult::Error(err),
                            SearchResult::NotFound => {}
                        }
                    }
                    SearchResult::NotFound
                }
            },
        }
    }

pub async fn search_in_database(state: &AppState, cep: &str) -> SearchResult {
        let result = sqlx::query_as!(
            CepResponse,
            r#"
            SELECT
                l.cep,
                COALESCE(l.logradouro, '') as "logradouro!",
                COALESCE(b.nome, '') as "bairro!",
                c.nome as "cidade!",
                e.sigla as "estado!",
                l.created_at,
                'database' as "provider!: String"
            FROM logradouro l
            INNER JOIN cidade c ON l.id_cidade = c.id
            INNER JOIN estado e ON c.id_estado = e.id
            LEFT JOIN bairro b ON l.id_bairro = b.id
            WHERE l.cep = $1
            "#,
            cep
        )
        .fetch_optional(&state.db)
        .await;

        match result {
            Ok(Some(response)) => {
                tracing::info!("Found zipcode in database: {}", cep);
                SearchResult::Found(response)
            }
            Ok(None) => {
                tracing::info!("CEP não encontrado no banco: {}", cep);
                SearchResult::NotFound
            }
            Err(e) => {
                tracing::error!("Erro ao consultar banco de dados: {}", e);
                SearchResult::Error(format!("Erro ao consultar banco de dados: {}", e))
            }
        }
    }

    /// Busca CEP no ViaCep
    pub async fn search_in_viacep(
        state: &AppState,
        cep: &str,
        save_in_db: Option<bool>,
    ) -> SearchResult {
        let viacep_client: ViaCepClient = ViaCepClient::new();
        let must_save = save_in_db.unwrap_or(true);

        match viacep_client.buscar_cep(cep).await {
            Ok(viacep_response) => {
                tracing::info!("CEP {} encontrado no ViaCep", cep);

                if !must_save {
                    return SearchResult::Found(viacep_response);
                }

                if let Err(e) = salvar_cep(state, &viacep_response).await {
                    tracing::error!("Erro ao salvar CEP {} no banco: {}", cep, e);
                }

                SearchResult::Found(viacep_response)
            }
            Err(err) => {
                match err {
                    CepApiError::CepNotFound => {
                        tracing::warn!("CEP {} não encontrado no ViaCep", cep);
                        SearchResult::NotFound
                    }
                    CepApiError::InvalidCep => {
                        tracing::warn!("CEP {} inválido", cep);
                        SearchResult::Error("CEP inválido".to_string())
                    }
                    CepApiError::RequestError(msg) => {
                        tracing::warn!("Erro de request no ViaCep: {}", msg);
                        SearchResult::NotFound // Trata como not found para continuar fallback
                    }
                    CepApiError::HttpError(code) => {
                        tracing::warn!("Erro HTTP no ViaCep: código {}", code);
                        SearchResult::NotFound // Trata como not found para continuar fallback
                    }
                    CepApiError::ParseError(msg) => {
                        tracing::warn!("Erro de parsing no ViaCep: {}", msg);
                        SearchResult::NotFound // Trata como not found para continuar fallback
                    }
                }
            }
        }
    }

Características técnicas:

Type safety absoluto verificado em compile-time
Pattern matching para tratamento de erros com Result<T, E>
Sistema de ownership previne erros de memória
Serialização zero-copy quando possível via serde

Casos de Uso para Cada Stack

Quando FastAPI é Adequado

Desenvolvimento Rápido: Para prototipagem e MVPs, onde velocidade de implementação é prioritária. O tempo de desenvolvimento em Python é significativamente menor.

Ecossistema Rico: Projetos que requerem integração com bibliotecas de machine learning (TensorFlow, PyTorch), data science (pandas, numpy) ou outras ferramentas do ecossistema Python.

Curva de Aprendizado: Equipes que precisam de produtividade imediata. Desenvolvedores júnior podem contribuir efetivamente com Python em dias, enquanto Rust requer semanas de aprendizado.

Gargalos Externos: Aplicações onde o tempo de processação é dominado por operações de I/O lentas (queries não otimizadas, APIs externas). Nestes casos, otimização da linguagem tem impacto marginal.

Quando Axum é Adequado

Alto Volume: Sistemas que precisam processar milhares de requisições por segundo, onde eficiência computacional impacta diretamente custos de infraestrutura.

Requisitos de Latência: APIs públicas ou microserviços internos com SLAs rigorosos de tempo de resposta.

Estabilidade de Longo Prazo: Sistemas que evoluem lentamente e se beneficiam de garantias de type safety e memory safety em compile-time.

Otimização de Custos: Ambientes onde a redução do número de servidores ou instâncias cloud resulta em economia significativa.

Reteste com FastAPI + Gunicorn (8 Workers)

Após a publicação inicial, o @gleberdiniz, depois de revisar o material, sugeriu testar a implementação FastAPI com configuração de produção usando Gunicorn com múltiplos workers, argumentando que a comparação seria mais justa ao explorar melhor o paralelismo disponível no hardware de 8 núcleos.

Configuração do Teste Revisado

Instalação das dependências:

pipenv install gunicorn uvicorn

Comando de execução:

gunicorn app:app \
  --workers 8 \
  --worker-class uvicorn.workers.UvicornWorker \
  --bind 0.0.0.0:8000

Parâmetros do teste:

Mesmos 20.000 requisições
Mesma concorrência de 50 conexões
Mesmo ambiente de hardware e banco de dados

Novos Resultados Quantitativos

Métrica	FastAPI (4 workers)	FastAPI (8 workers)	Axum (Rust)	Melhoria 8w vs 4w	Gap Axum vs 8w
Requisições/segundo	1.356,92	2.470,25	2.773,98	+82,0%	1,12x
Tempo total de execução	14,7s	8,1s	7,2s	-44,9%	1,12x
Tempo mediano	28ms	21ms	9ms	-25,0%	2,33x
Tempo médio	36ms	20ms	18ms	-44,4%	1,11x
Percentil 99	88ms	48ms	42ms	-45,5%	1,14x
Percentil 99.5	103ms	56ms	51ms	-45,6%	1,10x
Percentil 99.9	2.048ms	631ms	1.901ms	-69,2%	3,01x
Desvio padrão	97ms	33ms	96ms	-66,0%	2,91x

Análise dos Resultados Revisados

Throughput Comparável
Com 8 workers, FastAPI alcançou 2.470 req/s, reduzindo significativamente a diferença para o Axum (2.774 req/s). A vantagem do Rust diminuiu de 2,04x para apenas 1,12x em throughput bruto.

Latência Ainda Superior no Rust
Apesar do throughput próximo, a latência mediana do Axum (9ms) permanece 2,33x menor que o FastAPI com 8 workers (21ms). Esta diferença é crítica para aplicações sensíveis a tempo de resposta.

Percentis Altos Melhoraram Drasticamente
O P99.9 do FastAPI caiu de 2.048ms para 631ms, uma melhoria de 69%. Isto sugere que o gargalo anterior estava mais relacionado à saturação dos workers do que a limitações fundamentais da stack Python.

Estabilidade e Consistência
O desvio padrão do FastAPI caiu de 97ms para 33ms, indicando respostas mais consistentes. Curiosamente, o Axum manteve desvio padrão alto (96ms), provavelmente relacionado a outliers externos (banco de dados ou ViaCEP).

Também como sugestão do @gleberdiniz, foi refeito ambos os testes (Axum e FastAPI com 8 workers) monitorando cpu e memória.

Os três primeiros picos de CPU foram os testes com FastAPI e chegou até 90%, enqunto os três últimos foram com o Axum parando em 70% do consumo, uma diferença de 20% de CPU menor.

Já memória não apresentou picos relavantes, além do platô quase no fim do gráfico quando foi aberto o editor para rodar os testes e se manteve bem estável com 25% de uso para ambos.

Problema Crítico Encontrado: Esgotamento de Conexões

Ao final do teste com 8 workers, o seguinte erro foi registrado:

error connecting in 'pool-1': connection failed: connection to server at "127.0.0.1",
port 5432 failed: FATAL: sorry, too many clients already

Análise do Problema:
A configuração original do pool (min_size=10, max_size=20) multiplicada por 8 workers resulta em:

Mínimo: 80 conexões simultâneas
Máximo: 160 conexões simultâneas

O PostgreSQL padrão limita conexões em 100, causando esgotamento sob carga. Este é um problema clássico de tuning que afeta qualquer stack ao escalar horizontalmente.

Recomendações:

Ajustar pool por worker: min_size=2, max_size=5 (16-40 conexões totais)
Aumentar limite do PostgreSQL: max_connections=200 no postgresql.conf
Considerar PgBouncer para pooling externo em produção

Implicações para a Comparação Original

O teste inicial não foi justo?
Parcialmente. Com 4 workers, o FastAPI não utilizava plenamente o hardware de 8 núcleos. No entanto, a escolha de 4 workers foi intencional e documentada, refletindo uma configuração comum em ambientes de produção.

Por que 4 workers era a configuração inicial?
A fórmula (2 × núcleos) + 1 sugere 17 workers para 8 núcleos, mas na prática, desenvolvedores frequentemente usam configurações conservadoras para evitar contenção excessiva e simplificar debugging.

Qual configuração é mais realista?
Ambas são válidas dependendo do contexto:

4 workers: Mais estável, menor consumo de memória, debugging mais simples
8 workers: Maior throughput, requer tuning cuidadoso de recursos (conexões DB, file descriptors, memória)

Conclusão Revisada

Com configuração otimizada de 8 workers, o FastAPI demonstrou que Python pode alcançar throughput competitivo com Rust em aplicações I/O bound. A diferença de 12% em requisições por segundo torna-se marginal para muitas aplicações.

No entanto, três vantagens fundamentais do Axum permanecem:

Latência consistentemente menor: 2,33x melhor na mediana, crítico para APIs de baixa latência
Configuração mais simples: Não requer tuning complexo de workers e pools de conexão
Eficiência de recursos: Menor consumo de memória e CPU por requisição

A escolha entre as stacks deve considerar:

FastAPI: Ideal quando throughput é suficiente e velocidade de desenvolvimento/manutenção é prioritária
Axum: Necessário quando latência, eficiência de recursos ou escala extrema são requisitos críticos

O benchmark revisado reforça que otimização de deployment é tão importante quanto a escolha da linguagem. Uma stack "inferior" bem configurada pode superar uma stack "superior" mal configurada.

Conclusões Finais

Os testes demonstram que Rust com Axum oferece vantagens mensuráveis de performance, mas o gap não é tão dramático quanto benchmarks sintéticos sugerem. Em aplicações I/O bound reais, a diferença entre stacks bem configuradas tende a ser menor que em CPU-bound workloads.

A decisão técnica adequada depende do contexto específico de cada projeto: volume esperado de tráfego, requisitos de latência, expertise da equipe, velocidade de iteração necessária e restrições de custo operacional. O reteste com 8 workers demonstra que tuning adequado é frequentemente mais impactante que a escolha da linguagem.

Quer Dominar Rust e Entender como uma API com Axum pode ajudar a aumentar a performance?

O Que Você Vai Aprender:

Fundamentos sólidos: Do zero ao avançado, sem pular etapas essenciais
Performance real: Entenda como Rust elimina o overhead que torna Python lento
Safety sem garbage collector: Como Rust garante segurança de memória em compile-time
Concorrência sem medo: Paralelização nativa sem data races (o que torna Polars tão rápido)
Projetos práticos: Construa aplicações reais, incluindo processamento de dados como vimos neste artigo.

[pt-BR] CNPJ alfanumérico e CPF na prática: Rust acelerando Python em regras fiscais críticas

Jose Luis da Cruz Junior — Tue, 07 Jul 2026 21:08:53 +0000

A partir de julho de 2026, o ecossistema brasileiro passa a conviver com o CNPJ alfanumérico (IN RFB 2.119/2022). Para quem opera sistemas de cadastro, antifraude, onboarding, faturamento e compliance, isso muda o jogo: validações que antes eram simples e numéricas agora precisam aceitar letras, manter compatibilidade retroativa e continuar performando sob alta carga.

Neste post, vamos para o modo hands-on usando o projeto rsfn4py: as regras de validação de CNPJ e CPF ficam em Rust e são expostas para Python via PyO3, com fallback em Python puro. A ideia não é trocar sua stack inteira, e sim turbinar o trecho mais crítico com custo de migração muito baixo.

O problema real

Em muitas aplicações Python, validar documento fiscal parece barato até virar gargalo. O cenário piora quando:

A validação acontece em lote (ETL, filas, conciliação, processamento massivo).
A regra passa a aceitar alfanumérico (no CNPJ) e exige normalização mais robusta.
O sistema precisa manter baixa latência em APIs e jobs simultâneos.

A pergunta certa deixa de ser "Python ou Rust?" e vira "onde Rust melhora meu throughput sem reescrever tudo?".

Hands-on em 5 minutos

1. Build local do módulo Rust para Python

cd rsfn4py
python -m venv .venv
source .venv/bin/activate
pip install -U pip maturin pytest
maturin develop --release

2. Rode os testes de compatibilidade

pytest -v tests/

Os testes cobrem CNPJ numérico e alfanumérico, CPF com e sem formatação, DV incorreto, repetição e entradas inválidas.

Incorporando em um projeto Python existente via PyPI

Se você não quer clonar o repositório e apenas precisa da validação de alta performance no seu projeto, basta instalar o pacote publicado:

pip install rsfn4py

Projeto no PyPI: https://pypi.org/project/rsfn4py/

O rsfn4py é mantido por @zejuniortdr, autor deste blog. Dúvidas, sugestões ou bugs? Abra uma issue no repositório — o feedback de quem usa em produção ajuda a evoluir o pacote.

O pacote distribui wheels pré-compilados para Linux, macOS e Windows nas versões mais recentes do Python, então não é necessário ter Rust instalado na máquina.

Uso básico

from rsfn4py import validate_cnpj_rust, validate_cpf_rust

cnpjs = [
    "12.345.678/0001-95",   # Numérico formatado
    "12345678000195",        # Numérico sem formatação
    "12ABC34501DE35",        # Alfanumérico (novo formato)
    "11.111.111/1111-11",   # Inválido (sequência repetida)
]

for cnpj in cnpjs:
    status = "✅ válido" if validate_cnpj_rust(cnpj) else "❌ inválido"
    print(f"{cnpj:<25} → {status}")

cpfs = [
    "529.982.247-25",       # CPF válido formatado
    "52998224725",          # CPF válido sem formatação
    "529.982.247-24",       # DV incorreto
    "111.111.111-11",       # Inválido (repetição)
]

for cpf in cpfs:
    status = "✅ válido" if validate_cpf_rust(cpf) else "❌ inválido"
    print(f"{cpf:<25} → {status}")

Em um endpoint FastAPI

from fastapi import FastAPI, HTTPException
from rsfn4py import validate_cnpj_rust, validate_cpf_rust

app = FastAPI()

@app.get("/cadastro/cnpj/{cnpj}")
def validar_cnpj(cnpj: str):
    if not validate_cnpj_rust(cnpj):
        raise HTTPException(status_code=422, detail="CNPJ inválido")
    return {"tipo": "cnpj", "documento": cnpj, "valido": True}


@app.get("/cadastro/cpf/{cpf}")
def validar_cpf(cpf: str):
    if not validate_cpf_rust(cpf):
        raise HTTPException(status_code=422, detail="CPF inválido")
    return {"tipo": "cpf", "documento": cpf, "valido": True}

Em processamento em lote (pandas/polars)

import pandas as pd
from rsfn4py import validate_cnpj_rust, validate_cpf_rust

df = pd.read_csv("cadastros.csv")

# Aplica a validação Rust em todo o DataFrame — sem loop Python explícito
df["cnpj_valido"] = df["cnpj"].apply(validate_cnpj_rust)
df["cpf_valido"] = df["cpf"].apply(validate_cpf_rust)

invalidos_cnpj = df[~df["cnpj_valido"]]
invalidos_cpf = df[~df["cpf_valido"]]
print(f"{len(invalidos_cnpj)} CNPJs inválidos encontrados")
print(f"{len(invalidos_cpf)} CPFs inválidos encontrados")

Nota: Como validate_cnpj_rust e validate_cpf_rust são funções C-Extension, o overhead por chamada é muito menor do que uma função Python pura, o que faz diferença especialmente em DataFrames com centenas de milhares de linhas.

4. Como ficou o core

No rsfn4py, os algoritmos de validação ficam no core em Rust:

#[pyfunction]
fn validate_cnpj_rust(cnpj: &str) -> bool {
    let cleaned: Vec<char> = cnpj.chars()
        .filter(|c| c.is_ascii_alphanumeric())
        .map(|c| c.to_ascii_uppercase())
        .collect();

    if cleaned.len() != 14 {
        return false;
    }

    if cleaned.iter().all(|&c| c == cleaned[0]) {
        return false;
    }

    let get_val = |c: char| -> i32 { c as i32 - 48 };

    let weights1 = [5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2];
    let mut sum1 = 0;
    for i in 0..12 {
        sum1 += get_val(cleaned[i]) * weights1[i];
    }
    let mod1 = sum1 % 11;
    let dv1 = if mod1 < 2 { 0 } else { 11 - mod1 };

    if get_val(cleaned[12]) != dv1 {
        return false;
    }

    let weights2 = [6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2];
    let mut sum2 = 0;
    for i in 0..13 {
        sum2 += get_val(cleaned[i]) * weights2[i];
    }
    let mod2 = sum2 % 11;
    let dv2 = if mod2 < 2 { 0 } else { 11 - mod2 };

    get_val(cleaned[13]) == dv2
}

#[pyfunction]
fn validate_cpf_rust(cpf: &str) -> bool {
    let cleaned: Vec<char> = cpf.chars().filter(|c| c.is_ascii_digit()).collect();

    if cleaned.len() != 11 {
        return false;
    }

    if cleaned.iter().all(|&c| c == cleaned[0]) {
        return false;
    }

    let get_val = |c: char| -> i32 { c as i32 - 48 };

    let mut sum1 = 0;
    for i in 0..9 {
        sum1 += get_val(cleaned[i]) * (10 - i as i32);
    }
    let mod1 = sum1 % 11;
    let dv1 = if mod1 < 2 { 0 } else { 11 - mod1 };

    if get_val(cleaned[9]) != dv1 {
        return false;
    }

    let mut sum2 = 0;
    for i in 0..10 {
        sum2 += get_val(cleaned[i]) * (11 - i as i32);
    }
    let mod2 = sum2 % 11;
    let dv2 = if mod2 < 2 { 0 } else { 11 - mod2 };

    get_val(cleaned[10]) == dv2
}

E o Python continua sendo a camada de integração e produtividade:

from rsfn4py import (
    validate_cnpj_rust,
    validate_cnpj_python,
    validate_cpf_rust,
    validate_cpf_python,
)

casos = [
    "12.345.678/0001-95",
    "12ABC34501DE35",
    "11.111.111/1111-11",
]

for cnpj in casos:
    print(cnpj, validate_cnpj_rust(cnpj))

cpfs = [
    "529.982.247-25",
    "52998224725",
    "111.111.111-11",
]

for cpf in cpfs:
    print(cpf, validate_cpf_rust(cpf))

Esse formato entrega o melhor dos dois mundos:

Python continua no fluxo principal do produto.
Rust assume o trecho matemático e intensivo em CPU.
O pacote sobe como dependência comum (wheel), sem dor para o time da aplicação.

Benchmark: onde o ganho aparece

Com make bench rodando 100.000 validações por cenário (CNPJ e CPF), os resultados coletados foram:

Análise 1: Tempo de execução (s)

Documento	Python	Rust
CNPJ	0,684318s	0,063321s
CPF	0,713108s	0,039088s

Análise 2: Throughput (validações/segundo)

Documento	Python	Rust
CNPJ	146.131/s	1.579.264/s
CPF	140.231/s	2.558.310/s

Speedup Rust sobre Python

Documento	Ganho
CNPJ	10,81x
CPF	18,24x

Os números variam por hardware, versão de Python, versão de Rust e flags de compilação, mas a vantagem do núcleo nativo se mantém clara nos dois documentos.

Por que funciona tão bem?

Compilação nativa: o código crítico roda como binário otimizado, sem custo de interpretação por iteração.
Menos overhead no hot path: loops, soma ponderada e checagem de DV ficam em uma rotina enxuta.
Fronteira clara entre linguagens: Python orquestra, Rust calcula.

Em termos práticos: quando a regra fiscal vira "hot path", esse padrão evita escalar infraestrutura apenas para compensar CPU em validação.

Compatibilidade com legado e com o novo formato

O mesmo pacote cobre:

CNPJ tradicional numérico.
CNPJ alfanumérico no formato novo.
CPF tradicional com e sem máscara.
Entradas com pontuação e caracteres extras (limpeza antes do cálculo).
Casos inválidos clássicos (DV errado, repetição, lixo textual).

Essa compatibilidade reduz risco de regressão durante a janela de transição regulatória.

Checklist de adoção em produção

Coloque a validação Rust atrás de feature flag no início.
Rode as duas implementações em paralelo por um período para comparar outputs.
Monitore latência P95/P99 no endpoint que usa validação.
Mantenha fallback Python para rollback rápido.

O que este caso ensina sobre o ecossistema Rust fora do Rust

A grande mensagem não é "abandone Python". É "use Rust como acelerador estratégico".

Para times de produto, isso significa:

Entregar melhoria de performance sem reescrever serviço inteiro.
Preservar stack e produtividade do ecossistema Python.
Ganhar previsibilidade para escalar regras de negócio críticas.

No contexto de CNPJ alfanumérico e CPF em alto volume, é um ótimo exemplo de como Rust deixa de ser apenas linguagem de sistema e vira componente de alto impacto em stacks já consolidadas.

Próximos passos

Se você quiser aplicar esse modelo no seu contexto:

Identifique funções CPU-bound no seu pipeline Python.
Extraia o núcleo em Rust com PyO3 e exponha API mínima.
Meça antes/depois com dados reais de produção.
Publique wheel para reduzir atrito de adoção no time.

Quando o assunto é regra fiscal crítica em alto volume, performance deixa de ser "otimização" e vira requisito de negócio. E, nesse ponto, Rust como extensão do Python faz muita diferença.

Quer se aprofundar em Rust de forma prática, aplicada ao mundo real e com foco em performance? Conheça o livro em desbravandorust.com.br.

DEV Community: Jose Luis da Cruz Junior

[pt-BR] Entendendo Ownership em Rust: Um Guia para Pythonistas

Por @zejuniortdr em Fev 22, 2026

Por que Ownership é tão importante em Rust?

Os três princípios do Ownership

Princípio 1: Cada valor tem um dono

Princípio 2: Um único dono por vez

Princípio 3: Descarte quando sai de escopo

Erros comuns de Pythonistas em Rust

1. Tentar usar uma variável após movê-la

2. Modificar uma referência imutável

3. Criar referências inválidas (dangling references)

Exemplo prático completo:

Versão Rust

Versão Python

Ownership em tipos customizados

Comparação: Gerenciamento de memória em Python vs Rust

Semântica de operações: Python vs Rust

Quando usar clone() em Rust?

Exercício prático

O que aprendemos? 📚

Próximos passos na sua jornada Rust

[pt-BR] De Django ORM para SQLx: A Jornada de um backend que desaprendeu a confiar em mágica

Por @zejuniortdr em Fev 16, 2026

O Conforto (e o Preço) da Magia do Django ORM

O Que o Django ORM Faz de Genial

Onde a Magia Começa a Doer

O Choque Inicial com SQLx

Comparação Técnica: Lado a Lado

Relacionamentos e JOINs

Agregações e Subqueries

Transactions

O Que SQLx Me Ensinou Sobre Bancos de Dados

Quando Usar Cada Um?

Use Django ORM quando:

Use SQLx quando:

Lições da Jornada

Conclusão

Quer Mergulhar Fundo no Rust e SQLx?

[pt-BR] Cargo contra rapa

Por @zejuniortdr em Dez 03, 2025

O Caos do Tooling Moderno

O Ecossistema JavaScript/TypeScript

O Ecossistema Python

O Ecossistema PHP

O Jeito Cargo de Ser

1. Criando Projetos (cargo new)

2. Gerenciando Dependências

3. Build e Execução (cargo run)

4. Testes Integrados (cargo test)

5. Formatação Padrão (cargo fmt)

6. O Professor Particular (cargo clippy)

7. Correções Automáticas (cargo fix)

8. Documentação Automática (cargo doc)

Por que isso importa?

Conclusão

Benchmarks

Quer experimentar esse poder na prática?

Garanta seu exemplar e pare de brigar com configurações!

[pt-BR] Pandas vs Polars: Benchmark com 3 Milhões de Registros

Por @zejuniortdr em Nov 21, 2025

O que são DataFrames?

Semelhanças: O Território Comum

Diferenças: Onde Polars se Destaca

1. Linguagem de Implementação: A Base de Tudo

2. Modelo de Execução: Eager vs Lazy

3. Sintaxe e Estilo de Código

Pandas - Flexível Demais

Polars - Consistente e Expressivo

4. Paralelização e Concorrência

Pandas - Praticamente Single-Threaded

Polars - Paralelização Nativa

5. Tipos de Dados e Strictness

Pandas - Loose Typing (Tipagem Flexível)

Polars - Strict Typing (Tipagem Estrita)

6. Uso de Memória

Pandas - Guloso com RAM

Polars - Eficiente e com Streaming

7. Operações Complexas: Apply vs Expressões Nativas

Pandas - Dependente de .apply()

1. Criando Projetos (`cargo new`)

3. Build e Execução (`cargo run`)

4. Testes Integrados (`cargo test`)

5. Formatação Padrão (`cargo fmt`)

6. O Professor Particular (`cargo clippy`)

7. Correções Automáticas (`cargo fix`)

8. Documentação Automática (`cargo doc`)

Pandas - Dependente de `.apply()`