Seu ORM está mentindo para você (Parte II): o N+1 que o SQLx te obriga a enxergar

Por @zejuniortdr em Jun 29, 2026

No post sobre Django ORM vs SQLx eu defendi uma ideia incômoda: a “mágica” do ORM tem um preço, e quase sempre quem paga é o seu banco de dados em produção. Recebi muita mensagem concordando — e algumas dizendo que eu estava sendo injusto com o ORM.

Então vamos para o caso mais concreto possível dessa mágica cobrando a conta: o problema N+1. Ele é tão comum que provavelmente está acontecendo agora em alguma rota da sua aplicação, silencioso, escondido por uma linha de código que parece inofensiva.

O problema real

Imagine uma API que lista autores e os livros de cada um. Em Django, o código sai dos dedos quase sozinho:

# views.py
from django.http import JsonResponse
from .models import Autor

def listar_autores(request):
    autores = Autor.objects.all()
    data = []
    for autor in autores:
        data.append({
            "nome": autor.nome,
            "livros": [livro.titulo for livro in autor.livros.all()],
        })
    return JsonResponse({"autores": data})

Esse código está correto. Ele roda, passa no teste, vai para produção. E é exatamente aí que mora a mentira.

A mentira: uma query que virou cento e uma

Ative o log de SQL do Django e olhe o que aquele for inocente produziu com 100 autores:

-- 1 query para buscar os autores
SELECT id, nome FROM autores;

-- depois, UMA query por autor para buscar os livros (100 queries!)
SELECT id, titulo FROM livros WHERE autor_id = 1;
SELECT id, titulo FROM livros WHERE autor_id = 2;
SELECT id, titulo FROM livros WHERE autor_id = 3;
-- ... e assim por diante, até o autor 100

São 1 + N queries: uma para a lista e mais uma para cada item dela. Com 100 autores, são 101 idas ao banco. Com 10.000 autores, são 10.001. O ORM nunca te avisou disso — o autor.livros.all() parece um simples acesso a atributo, mas cada chamada abre uma conexão, faz round-trip de rede, espera o banco responder e desserializa o resultado.

O N+1 raramente aparece em desenvolvimento, onde a tabela tem 10 linhas. Ele explode em produção, quando os dados crescem e a latência de rede entre app e banco entra na conta. É o bug de performance mais democrático que existe.

Como o SQLx te obriga a ver

A grande diferença filosófica do SQLx não é ser “mais rápido”. É que ele não te deixa fingir que o banco não existe. Você escreve SQL. E quando você escreve SQL, escrever 100 queries num loop dá trabalho — o caminho natural é o caminho certo: um JOIN.

use sqlx::PgPool;

#[derive(serde::Serialize)]
struct AutorComLivros {
    nome: String,
    livros: Vec<String>,
}

async fn listar_autores(pool: &PgPool) -> Result<Vec<AutorComLivros>, sqlx::Error> {
    // UMA query. O banco faz o trabalho que ele foi feito para fazer.
    let linhas = sqlx::query!(
        r#"
        SELECT a.id, a.nome, l.titulo
        FROM autores a
        LEFT JOIN livros l ON l.autor_id = a.id
        ORDER BY a.id
        "#
    )
    .fetch_all(pool)
    .await?;

    // Agrupa em memória, em Rust, sem tocar no banco de novo.
    let mut mapa: indexmap::IndexMap<i32, AutorComLivros> = indexmap::IndexMap::new();
    for linha in linhas {
        let entrada = mapa.entry(linha.id).or_insert_with(|| AutorComLivros {
            nome: linha.nome.clone(),
            livros: Vec::new(),
        });
        if let Some(titulo) = linha.titulo {
            entrada.livros.push(titulo);
        }
    }

    Ok(mapa.into_values().collect())
}

Repare: não existe um caminho “preguiçoso” aqui que silenciosamente vire 100 queries. Para acessar os livros, você teve que decidir, na hora de escrever o SQL, como buscá-los. O custo é visível na fonte do código — e custo visível é custo que você otimiza.

O ORM tem a saída de emergência — se você souber que precisa dela

Em defesa do Django: ele resolve o N+1. Basta uma palavra:

# Agora são 2 queries no total, não importa quantos autores existam
autores = Autor.objects.prefetch_related("livros").all()

O prefetch_related faz o Django buscar todos os livros numa segunda query e juntar em memória. O select_related faz algo parecido com JOIN para relações ForeignKey/OneToOne. Funciona muito bem.

O problema não é a ausência de solução. É que a solução é opt-in e invisível. O código errado e o código certo têm a mesma cara — a única diferença é uma chamada de método que você precisa lembrar de adicionar. Esqueceu? Nenhum erro, nenhum aviso. Só uma rota lenta que ninguém entende seis meses depois.

No SQLx, o “esquecimento” não existe: você não consegue escrever a query sem decidir o que buscar.

Benchmark: a conta da mentira

Rota retornando 100 autores com ~10 livros cada, banco PostgreSQL com ~0,4ms de latência de round-trip (cenário realista de app e banco em redes diferentes):

Tempo de resposta da rota

Speedup sobre o N+1 ingênuo

Os números variam por latência de rede, tamanho do dataset e índices, mas o formato da curva é sempre o mesmo: o N+1 escala com o número de linhas, as outras duas abordagens não. Em 10.000 autores, a diferença deixa de ser de milissegundos e vira de segundos.

Por que isso importa além do benchmark

1. Round-trip de rede domina. A query em si é rápida; o caro é o ir-e-voltar até o banco. N+1 multiplica justamente a parte cara.
2. O ORM otimiza para escrita de código, não para leitura do banco. Isso é ótimo para produtividade e péssimo quando o custo fica escondido.
3. Custo visível é custo gerenciável. Quando você é forçado a escrever a query, você é forçado a pensar nela.

A tese da Parte I se confirma aqui: abstração que esconde custo é dívida disfarçada de produtividade. Você pega o empréstimo na hora de escrever e paga os juros em produção.

Contraponto honesto

Não é para você sair jogando seu ORM no lixo — eu mesmo não jogaria:

1. Para CRUD comum, ORM entrega velocidade de desenvolvimento que SQL puro não encosta.
2. O N+1 tem solução trivial quando você sabe que ele existe — e agora você sabe.
3. Migrations, validações e o ecossistema do Django ORM são um valor real e enorme.

A pergunta certa não é “ORM ou SQL?”. É “eu sei o que meu ORM está fazendo com o meu banco?”. Se a resposta for não, o problema não é a ferramenta — é a mágica.

Checklist anti-N+1 em produção

1. Ligue o log de SQL em ambiente de staging e conte as queries das suas rotas mais quentes.
2. Use o django-debug-toolbar (ou nplusone) para capturar N+1 automaticamente.
3. Adote prefetch_related/select_related por padrão em qualquer rota que itere sobre relações.
4. Defina um teto de queries por request em teste (ex.: assertNumQueries) para travar regressões.
5. Para os hot paths mais críticos, considere descer para SQL explícito — onde o custo nunca mais se esconde.

O que esse caso ensina

O ORM não é o vilão. O vilão é o custo invisível. Rust e o SQLx não são mágicos — eles são o oposto da mágica, e é exatamente por isso que te protegem: o que você não consegue esconder, você não esquece de otimizar.

No próximo post dessa pegada, eu vou ainda mais longe e mostro o que acontece quando você decide que nem o seu worker de tarefas precisa mais ser Python.

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.