Quando um ORM É a Ferramenta Errada

Um ORM é o padrão correto para CRUD e a ferramenta errada no momento em que sua consulta deixa de parecer acesso a objetos e passa a parecer um relatório.

Você provavelmente conhece o momento em que a coisa vira: um endpoint de listagem que parecia tranquilo em staging leva quatro segundos em produção, e o log de consultas está cheio de SELECTs quase idênticos que ninguém escreveu à mão. Window functions, CTEs, agregações com múltiplos joins e operadores específicos de fornecedor são exatamente onde o SQL gerado por um ORM se torna ineficiente ou impossível, e onde descer ao SQL puro compensa. Este artigo traça a linha com precisão: onde o mapeamento objeto-relacional é o padrão correto, onde ele silenciosamente se torna o gargalo, e como ir além dele sem abrir mão da segurança contra injeção.

SQL puro, query builders, ORMs: um espectro de abstração

“ORM vs SQL puro” nunca foi binário. Acesso a dados é um espectro que vai do controle total à conveniência total, com uma camada intermediária que a maioria das comparações ignora. Em um extremo, o SQL puro lhe dá a linguagem nativa do banco de dados sem camada de tradução. No outro, ORMs como o ORM do Django, ActiveRecord, Hibernate, Prisma, Sequelize e SQLAlchemy mapeiam linhas para objetos e geram SQL para você. No meio ficam os query builders.

Um query builder formaliza padrões de consulta como métodos encadeáveis, mantendo-se próximo do SQL que emite. A maioria dos ORMs também expõe uma forma de entregar uma string bruta ao banco de dados, o que descarta o escaping que seus métodos normais de consulta fazem por você e reabre a porta para SQL injection. Um builder é uma ferramenta diferente: ele compõe SQL programaticamente sem fingir ser acesso a objetos. O Knex é um query builder JavaScript ativamente mantido, na linha 3.3.0 desde junho de 2026 de acordo com seu changelog; na JVM, o jOOQ é uma DSL SQL typesafe, atualmente na linha 3.21, cuja Open Source Edition tem como alvo o JDK 21. Nenhum dos dois é um ORM, e ambos mantêm a parametrização intacta, que é justamente o ponto. Quando a abstração do ORM luta contra você, a camada de builder costuma ser o passo certo antes do SQL escrito à mão.

Quando um ORM é a ferramenta errada?

O sinal para mudar não é uma sensação: é específico. Vá além do ORM quando você se deparar com um destes cinco padrões:

1. Consultas analíticas e em formato de relatório. Window functions, CTEs recursivas, rollups com GROUP BY ... HAVING e relatórios com múltiplos joins são onde o SQL gerado se torna ineficiente ou impossível de expressar. Um ORM otimiza para acesso a objetos, não para saída em formato OLAP.
2. Hot paths e operações em lote. Em um endpoint de alto tráfego ou em um UPDATE/INSERT em lote, chamadas save() por linha e round-trips extras se acumulam. Um único comando baseado em conjuntos substitui centenas de escritas do ORM.
3. A armadilha da consulta N+1. Detalhada abaixo: a falha de desempenho mais comum de ORMs.
4. Recursos específicos do banco de dados. Operadores JSONB do Postgres como @> e ->>, busca full-text com tsvector/tsquery, joins LATERAL e funções geoespaciais do PostGIS são recursos que muitos ORMs não conseguem expressar de forma completa ou idiomática. Alguns ORMs expõem helpers (o contrib.postgres do Django), mas a cobertura é parcial.
5. Comportamento opaco, “mágico”. Quando você não consegue ver ou ajustar o SQL que o ORM emite, depuração e trabalho de desempenho viram adivinhação. Isso é o descompasso de impedância objeto-relacional aparecendo como um custo real, e há um viés de segurança: os métodos de consulta bruta que a maioria dos ORMs oferece ficam fora do escaping deles próprios, então interpolar um valor em um deles deixa você exposto.

O problema da consulta N+1, nomeado e resolvido

O problema N+1 é a forma mais comum de um ORM silenciosamente se tornar a ferramenta errada: o lazy loading dispara uma consulta por linha, então uma lista de 100 itens vira silenciosamente 101 round-trips. O laço parece inocente:

# One query for authors, then one MORE per author for their books
for author in Author.objects.all():
    print(author.name, author.books.count())

A correção é eager loading, não SQL puro. O select_related e o prefetch_related do Django colapsam esses round-trips em um JOIN ou em uma única consulta IN:

# Two queries total, regardless of author count
authors = Author.objects.prefetch_related("books")

Corrija o N+1 primeiro com eager loading, e recorra ao SQL puro apenas quando até mesmo o formato com eager loading estiver errado, por exemplo quando você precisa de um agregado com window function por autor que o ORM expressaria como mais um round-trip. Consultas ineficientes de ORM raramente se anunciam no seu código; elas aparecem como respostas lentas de API e carregamentos de página lentos. Uma ferramenta de session replay como o OpenReplay mostra a requisição de rede lenta na linha do tempo da sessão, apontando para o endpoint cuja consulta de backend precisa de atenção: a localização do sintoma, não a consulta em si. Para o tradeoff mais profundo, veja o guia do OpenReplay para prevenir SQL injection.

O que você abre mão ao escrever SQL puro?

Quando você escreve SQL puro, você herda o único trabalho que o ORM fazia silenciosamente por você: segurança contra injeção. Sempre passe a entrada do usuário por placeholders de parâmetro e nunca a concatene na string da consulta. O guia do Django sobre executar consultas SQL puras expõe a mecânica: cursor.execute() recebe placeholders %s mais uma lista separada de valores, e o driver faz o escaping de cada valor na entrada, de modo que ele nunca se torna parte do texto do comando.

# Safe: %s is the psycopg/DB-API placeholder, not string formatting
from django.db import connection
with connection.cursor() as cursor:
    cursor.execute("SELECT * FROM book WHERE author = %s", [user_input])
    rows = cursor.fetchall()

Deixe os placeholders sem aspas: colocar %s entre aspas dentro da string SQL joga fora essa proteção. O SQLx do Rust toma seu placeholder do banco de dados, então $1 no Postgres, mas ? no MySQL, MariaDB e SQLite. Além da injeção, você também assume mais boilerplate, acoplamento mais forte a um dialeto SQL e mapeamento manual das linhas de resultado de volta para objetos.

Você não precisa abrir mão da rede de segurança para abrir mão do ORM. Ferramentas com verificação em tempo de compilação a mantêm: o SQLx (0.9) verifica consultas contra o schema antes de a aplicação rodar e sua própria documentação afirma que ele não é um ORM; o jOOQ (3.21) faz o mesmo na JVM. Os query builders ficam no meio. “ORM vs SQL puro” é um falso binário: o eixo real é quanta abstração cada consulta específica merece.

O veredito pragmático entre ORM e SQL puro

Use o ORM para os ~80% de CRUD simples e desça ao SQL puro pela própria válvula de escape dele nas consultas específicas que justificam isso. Sair do ORM não significa removê-lo. O Django documenta três caminhos: RawSQL para encaixar um fragmento parametrizado dentro de uma consulta do ORM, Manager.raw() para uma consulta bruta que ainda retorna instâncias de modelo, e connection.cursor() para contornar completamente a camada de modelos. O SQLAlchemy expõe text(); o Prisma oferece o TypedSQL, atualmente um recurso em preview, além de $queryRaw para acesso não tipado.

A decisão se reduz a uma tabela curta:

SQL puro não é uma reescrita; é uma válvula de escape direcionada para o punhado de consultas em que o SQL gerado é o gargalo. Mantenha o ORM como seu padrão, faça o profiling do endpoint lento e substitua por SQL parametrizado escrito à mão exatamente onde o plano de execução prova que isso se justifica, e em nenhum outro lugar.

Perguntas Frequentes

SQL puro é realmente mais rápido que um ORM?

Não inerentemente. Uma consulta bem escrita no ORM e uma consulta bruta bem escrita chegam ao mesmo planejador de consultas, então SQL puro não é automaticamente mais rápido. O SQL puro vence especificamente quando a consulta gerada pelo ORM é o gargalo — round-trips extras, padrões N+1, seleções amplas e sem limite, ou hot paths onde comandos baseados em conjuntos substituem escritas linha a linha. A vantagem de velocidade vem de corrigir SQL gerado ruim, não do SQL puro em si.

Qual é a diferença entre um query builder e um ORM?

Um query builder compõe SQL programaticamente por meio de métodos encadeáveis, mantendo-se próximo do SQL que emite; ele não mapeia linhas para objetos. Um ORM mapeia linhas do banco de dados para objetos da linguagem e esconde o SQL por completo. O Knex é um query builder para JavaScript e o jOOQ é uma DSL SQL typesafe para a JVM — nenhum dos dois é um ORM. Ambos mantêm a parametrização intacta, então você abandona a abstração de mapeamento de objetos sem perder a segurança contra injeção.

Como escrevo SQL puro sem expor minha aplicação a SQL injection?

Passe todo valor fornecido pelo usuário por placeholders de parâmetro e nunca concatene a entrada na string da consulta. No Django com psycopg o placeholder é %s, e o driver do banco de dados faz o escaping dos parâmetros automaticamente; o SQLx do Rust toma seu placeholder do banco de dados, então $1 no PostgreSQL, mas ? no MySQL, MariaDB e SQLite. Não coloque aspas ao redor dos placeholders na string SQL. Ferramentas com verificação em tempo de compilação como o SQLx verificam as consultas contra o schema antes de a aplicação rodar, adicionando mais uma camada de segurança.

Posso usar SQL puro dentro de um ORM sem remover o ORM?

Sim. Todo ORM importante oferece uma válvula de escape que permite executar SQL puro mantendo o ORM como padrão. O Django oferece connection.cursor() para execução direta, Manager.raw() para retornar instâncias de modelo e RawSQL para fragmentos parametrizados dentro de consultas do ORM; o SQLAlchemy expõe text(); o Prisma oferece o TypedSQL como recurso em preview, além de $queryRaw para acesso não tipado. Use o ORM para CRUD padrão e recorra através dele ao SQL puro apenas nas consultas específicas em que o SQL gerado é o gargalo.