ORM vs Raw SQL 🪑

O eterno flamewar, onde uns defendem a "conveniência" e outros o "controle".

🪑 Cadeira nº1: SQLAlchemy ORM

ORM não é sobre velocidade de código, é sobre velocidade de entrega de funcionalidades. Você trabalha com objetos, não com strings.

✅ Por que é legal:
— Unit of Work: A Alquimia monitora as mudanças nos objetos e as envia para o banco em um único pacote transacional.
— Segurança: Injeção SQL? Esqueça. Se você não usar .text(), está protegido por padrão.
— Migrações: Sincronizar o esquema do banco com seus modelos é mágica que economiza horas de rotina.
— Lógica de Domínio: Ideal para sistemas de e-commerce complexos e painéis administrativos, onde as relações entre tabelas são mais emaranhadas que o enredo de "Interestelar".

❌ Qual o problema:
— Overhead: Mapeamento de objetos é uma operação cara. Em grandes conjuntos de dados (100k+ linhas), você sentirá o processo Python consumir memória e CPU.
— Problema N+1: O principal assassino de desempenho. Um .joinedload() esquecido e seu serviço cai sob uma enxurrada de pequenas consultas.

🪑 Cadeira nº2: Raw SQL / asyncpg (Escolha para Highload)

Quando você esbarra no desempenho, as camadas intermediárias começam a atrapalhar.

✅ Por que é legal:
— Velocidade extrema: A diferença de 2,5 vezes não é brincadeira. O protocolo binário do asyncpg permite extrair o máximo do canal de rede.
— Controle total: Você escreve exatamente o SQL que irá para o planejador do banco. Nenhuma mágica extra do ORM.
— Funcionalidades específicas do banco: Tente usar eficientemente JSONB ou índices específicos do Postgres via ORM — às vezes vira um trabalho de Sísifo.

❌ Qual o problema:
— Sua responsabilidade: Esqueceu de escapar parâmetros? Parabéns, o banco foi comprometido.
— Boilerplate: Você terá que mapear manualmente tuplas do banco para modelos DTO/Pydantic. É chato e gera erros.
— Manutenção: Ler 500 linhas de SQL puro no código depois de seis meses é um prazer duvidoso.


💡 Veredito: O padrão ouro é a abordagem híbrida

Não precisa escolher apenas um. A arquitetura moderna se parece com isso:
1. SQLAlchemy ORM — para 90% das tarefas: CRUD, lógica de negócios, migrações e painel administrativo.
2. SQLAlchemy Core — quando os objetos ORM são muito pesados, mas você ainda não quer escrever strings puras.
3. Raw SQL (asyncpg) — para gargalos: relatórios analíticos, inserções em massa e microsserviços com carga de 10k+ RPS.

Escolha a cadeira de acordo com o tamanho da carga ☝️

E você, o que usa?
👨‍💻 Só ORM, a vida é muito curta para escrever SQL manualmente.
👨‍💻 Só Raw SQL, não confio nessa mágica.

#dois_cadeiras