O que é SQL direto (sem ORM)

SQL (Structured Query Language) e a linguagem padrão para interagir com bancos de dados relacionais. Existe desde os anos 70, foi padronizada pela ANSI e até hoje e o coração de sistemas em produção ao redor do mundo. Quando falamos em SQL sem ORM, estamos falando de escrever consultas diretamente, sem passar por uma camada de abstração que traduz seu código para SQL automaticamente.

ORMs (Object-Relational Mappers) como Hibernate, SQLAlchemy, Entity Framework e Sequelize existem para facilitar a vida do desenvolvedor. Em vez de escrever SELECT * FROM usuários WHERE ativo = true, você escreve algo como Usuário.findAll({ where: { ativo: true } }). Mais legível, menos SQL para aprender - pelo menos na teoria.

O problema e que essa abstração tem um custo. Ela esconde o que realmente acontece no banco, gera queries ineficientes sem que você perceba, e deixa o desenvolvedor sem ferramentas quando algo da errado. Em 2026, com bancos de dados processando volumes cada vez maiores, essa ignorância tem um preço alto.

Como funciona o SQL direto

Quando você escreve SQL diretamente, o banco de dados recebe a query exatamente como você escreveu (ou com parâmetros preparados, o que é a forma correta). O query planner do banco analisa a query, escolhe o índice mais eficiente, e executa. Você tem controle total sobre o que acontece.

Com um ORM, existe uma camada intermediaria. O ORM analisa suas chamadas de método, gera SQL dinamicamente, e as vezes gera consultas que nenhum desenvolvedor humano escreveria. O problema clássico e o N+1: você busca uma lista de usuários, e o ORM faz uma query separada para cada usuário para buscar os pedidos relacionados - em vez de um único JOIN que resolveria tudo de uma vez.

SQL direto também é mais portável do que parece. SQL:2023 e o padrão atual, e a maioria dos bancos modernos suporta o núcleo da linguagem. PostgreSQL, MySQL, SQLite, SQL Server e Oracle todos entendem SELECT, INSERT, UPDATE, DELETE, JOIN, GROUP BY e WINDOW FUNCTIONS. O conhecimento transfere.

💡
Dica

Aprenda SQL em cima do PostgreSQL. E open source, poderoso, e tem uma das melhores documentações de qualquer software de banco de dados. O que você aprender aqui funciona também em outros bancos com pequenas adaptações.

Principais recursos do SQL que ORMs escondem

A maioria dos devs que usam ORMs nunca aprende algumas das features mais poderosas do SQL. Aqui estão as que fazem mais diferença no dia a dia:

  • Window Functions: calculam valores sobre um conjunto de linhas relacionadas sem colapsar os resultados como o GROUP BY faz. Perfeitas para rankings, medias moveis e comparações entre linhas.
  • CTEs (Common Table Expressions): permitem nomear subconsultas e reutiliza-las dentro da mesma query. Tornam queries complexas muito mais legíveis.
  • Índices compostos e parciais: você só consegue projetar índices eficientes se entender como o query planner funciona. ORMs raramente criam os índices certos automaticamente.
  • EXPLAIN e EXPLAIN ANALYZE: comandos que mostram como o banco vai executar sua query antes de executar de verdade. Essencial para debugging de performance.
  • Transactions explicitas: controle fino sobre o que é commitado ou revertido. ORMs abstraem isso, mas em cenários complexos você precisa de controle manual.
  • UPSERT e ON CONFLICT: inserir ou atualizar em uma única operação atómica. Muito mais eficiente do que buscar e depois inserir ou atualizar.

Cada um desses recursos existe ha anos nos principais bancos. A diferença e que sem conhecer SQL, você vai reinventar a roda no código da aplicação, em memoria, de forma mais lenta e com mais linhas de código.

Como começar: instalação e primeiros passos

A forma mais rápida de começar a praticar SQL direto e com o PostgreSQL localmente ou com o SQLite, que não precisa nem de servidor. Para PostgreSQL:

# Ubuntu/Debian
sudo apt install PostgreSQL PostgreSQL-contrib
sudo systemctl start PostgreSQL

# macOS com Homebrew
brew install PostgreSQL@16
brew services start PostgreSQL@16

Depois de instalar, acesse o terminal interativo do PostgreSQL e crie seu banco de prática:

sudo -u postgres psql
CREATE DATABASE prática;
\c prática

CREATE TABLE usuários (
  id SERIAL PRIMARY KEY,
  nome VARCHAR(100) NOT NULL,
  email VARCHAR(254) UNIQUE NOT NULL,
  criado_em TIMESTAMPTZ DEFAULT NOW()
);

Para quem prefere não instalar nada agora, o site db-fiddle.com oferece um ambiente online onde você pode escrever e executar SQL diretamente no navegador, com suporte a PostgreSQL, MySQL e SQLite.

⚠️
Atenção

Nunca pratique SQL direto em banco de produção. Crie sempre um banco separado para testes. Um DELETE sem WHERE apaga todos os dados da tabela sem confirmação.

Exemplo prático: o problema N+1 e como SQL resolve

Imagine um sistema com usuários e pedidos. Você precisa listar os 10 últimos usuários com o total de pedidos de cada um. Com um ORM típico, o banco receberia algo assim por baixo dos panos:

-- O que o ORM faz por baixo (problema N+1)
SELECT * FROM usuários ORDER BY criado_em DESC LIMIT 10;
-- Depois, para cada usuário encontrado:
SELECT COUNT(*) FROM pedidos WHERE usuario_id = 1;
SELECT COUNT(*) FROM pedidos WHERE usuario_id = 2;
-- ... mais 8 queries separadas

São 11 queries no banco para buscar dados de 10 usuários. Em uma aplicação com tráfego real, isso vira gargalo rapidamente. A solução em SQL puro resolve tudo em uma única query:

SELECT
  u.id,
  u.nome,
  u.email,
  COUNT(p.id) AS total_pedidos
FROM usuários u
LEFT JOIN pedidos p ON p.usuario_id = u.id
GROUP BY u.id, u.nome, u.email
ORDER BY u.criado_em DESC
LIMIT 10;

Uma query, um round-trip ao banco, resultado completo. Para analisar a performance, use EXPLAIN ANALYZE antes da query e veja o plano de execução. O banco mostra exatamente quais índices usou e quanto tempo levou cada etapa.

Comparação com alternativas

ORM completo (Hibernate, Entity Framework, SQLAlchemy): ideal para CRUDs simples e prototipagem rápida. O custo e performance e debugging mais difícil quando algo sai do esperado.

Query Builder (Knex.js, JOOQ, Dapper): o meio-termo. Você escreve as queries em código, mas com uma API que cuida de parâmetros e escape. Menos magica que o ORM, mais conforto que SQL puro.

SQL direto com prepared statements: máximo controle, melhor performance, debugging mais direto. Requer disciplina para não criar vulnerabilidades de SQL injection. Perfeito para queries críticas de performance, relatórios complexos e operações em lote.

🚀
Pro tip

A abordagem que mais funciona na prática e híbrida: ORM para CRUDs básicos e SQL direto para queries complexas, relatórios e operações de performance crítica. Não precisa escolher um ou outro para o projeto inteiro.

Pontos positivos e limitações

O que fala a favor do SQL direto: performance previsível, controle total sobre o que o banco executa, acesso a todas as features do banco sem limitações da camada ORM, e portabilidade do conhecimento entre projetos e linguagens diferentes.

O que pesa contra: mais verboso para operações simples, exige disciplina para evitar SQL injection, sem mapeamento automático para objetos da aplicação, e migração de schema precisa ser gerenciada com ferramentas separadas como Flyway ou Liquibase.

A limitação mais subestimada e a curva de aprendizado. SQL parece simples no começo, mas recursos avançados como window functions, CTEs recursivas e otimização de índices levam tempo para dominar de verdade. O investimento vale, mas não espere produtividade máxima na primeira semana.

Casos de uso reais

Dev backend em startup: o sistema processa dados de vendas e o relatório mensal demora 40 segundos. Depois de substituir as queries geradas pelo ORM por SQL com CTEs e índices compostos, o mesmo relatório passa a rodar em menos de 2 segundos.

Engenheiro de dados: trabalha com pipelines de ETL que movem milhões de registros entre bancos. SQL direto com bulk insert, COPY no PostgreSQL, e queries analíticas com window functions e o padrão da área. ORMs não existem nesse contexto.

Dev full stack em empresa de médio porte: mantem um sistema legado. Precisa otimizar sem reescrever tudo. Conhecer SQL profundamente permite identificar os gargalos e melhorar ponto a ponto.

Freelancer construindo SaaS: começa com ORM para velocidade de desenvolvimento, mas mantem SQL direto para as partes críticas como autenticação, cobrança e relatórios.

Dicas e boas práticas

💡
Dica

Sempre use parâmetros preparados. Nunca concatene valores do usuário diretamente na query. Em Python com psycopg2: cursor.execute com %s e uma tupla de valores. O driver faz o escape correto automaticamente.

💡
Dica

Use EXPLAIN ANALYZE antes de colocar qualquer query complexa em produção. No PostgreSQL: EXPLAIN ANALYZE SELECT ... Preste atenção em Seq Scan em tabelas grandes - provavelmente você precisa de um índice.

🔴
Cuidado

DELETE e UPDATE sem WHERE afetam todas as linhas da tabela. Antes de rodar em produção, escreva o SELECT equivalente primeiro para confirmar quais registros seriam afetados. Só depois troque para DELETE ou UPDATE.

Vale a pena aprender SQL direto em 2026?

Sim, especialmente se você já trabalha com bancos de dados ha algum tempo mas sempre passou pelo filtro de um ORM. O investimento em aprender SQL de verdade retorna em forma de sistemas mais rápidos, debugging mais eficiente e menos dependência de camadas de abstração que você não controla.

Para quem esta começando: aprenda o básico do SQL junto com o ORM da sua stack. Invista tempo em entender o SQL que o ORM gera, use EXPLAIN ANALYZE para ver o que acontece por baixo, e quando a performance importar, saiba escrever a query certa você mesmo.

O próximo passo sugerido: pegue uma das queries geradas pelo ORM da sua aplicação atual e tente reescreve-la em SQL puro. Depois rode EXPLAIN ANALYZE nas duas versões e compare. Você vai aprender mais com esse exercício do que com qualquer tutorial.