Introdução

A linguagem SQL (Structured Query Language) é case-insensitive para suas palavras-chave.
Ou seja: SELECT, select, SeLeCt — tudo é interpretado da mesma forma.

Então surge uma pergunta inevitável:

Se SQL não diferencia maiúsculas e minúsculas, por que vemos alguns códigos misturando maiúsculas e minúsculas?

A resposta envolve convenção, legibilidade, história da computação e detalhes técnicos que podem afetar seus projetos.

Neste post, vamos abordar de forma definitiva por que, como, e quando usar maiúsculas e minúsculas em SQL — sem achismos.

---

SQL é case-insensitive, mas há boas práticas

SQL foi projetado para não diferenciar maiúsculas e minúsculas nas suas palavras-chave.

Exemplo: estes três comandos são idênticos:

SELECT nome FROM usuarios;
select nome from usuarios;
SeLeCt nome FrOm usuarios;

Entretanto, as convenções de escrita existem para melhorar a legibilidade — tanto para você quanto para toda a equipe de desenvolvimento.

---

Palavras-chave em MAIÚSCULAS

Palavras-chave SQL (SELECT, FROM, WHERE, INSERT, UPDATE, DELETE, etc.) são tradicionalmente escritas em maiúsculas.

Motivos:

• Separar visualmente comandos dos dados.
• Facilitar leitura rápida de grandes scripts SQL.
• Padronizar o estilo de escrita.
• Seguir tradição histórica (falaremos sobre isso mais abaixo).

Exemplo:

SELECT nome, idade
FROM usuarios
WHERE idade > 18;

Compare com a mesma consulta sem destacar:

select nome, idade from usuarios where idade > 18;

A leitura do primeiro é muito mais rápida e organizada.

---

Identificadores (tabelas e colunas) em minúsculo

A maioria das boas práticas recomenda que nomes de tabelas e colunas sejam escritos em minúsculas, usando snake_case quando necessário.

Exemplos recomendados:

• usuarios
• data_nascimento
• endereco_residencial

Exemplos a evitar:

• Usuarios
• DataNascimento
• EnderecoResidencial

Por quê?

• Evita inconsistências (principalmente em bancos como PostgreSQL, onde o uso de aspas pode diferenciar maiúsculas e minúsculas).
• Facilita digitação e manutenção.
• Torna o padrão mais simples e previsível.

---

Histórico: Terminais só tinham maiúsculas

Quando SQL foi criado, nos anos 1970 (projetos como IBM System R e o estudo da Relational Model de E. F. Codd), os terminais de computador só conseguiam exibir letras maiúsculas.

Por isso, todos os comandos SQL foram concebidos em maiúsculas — era a única opção visual.

Mesmo quando as telas passaram a suportar letras minúsculas, a prática se manteve: comandos SQL continuam sendo escritos em MAIÚSCULAS como tradição.

---

Algumas exceções: bancos que tratam case-sensitivity em identificadores

Importante!
Embora SQL seja case-insensitive para palavras-chave, não são todos os bancos que ignoram case em identificadores.

Banco de Dados	Palavras-chave	Identificadores (sem aspas)	Identificadores (com aspas)
MySQL	Insensível	Insensível (depende do sistema de arquivos)	Sensível
PostgreSQL	Insensível	Converte para minúsculo	Sensível
Oracle	Insensível	Converte para maiúsculo	Sensível
SQL Server	Insensível	Insensível (depende do collation)	Sensível

Exemplo prático no PostgreSQL:

CREATE TABLE Usuarios (ID INT);

No PostgreSQL:

• Sem aspas: o banco vai tratar como usuarios, id (minúsculo).
• Com aspas: "Usuarios", "ID" devem ser usados exatamente como foram criados (case-sensitive).

Consulta obrigatoriamente correta:

SELECT "ID" FROM "Usuarios";

Caso contrário, o erro será:

ERROR: relation "usuarios" does not exist

---

Padrões recomendados para projetos sérios

Para projetos de banco de dados duradouros, portáveis e de fácil manutenção:

• Palavras-chave sempre em MAIÚSCULAS.
• Tabelas e colunas em minúsculas e snake_case.
• Evitar uso de aspas em identificadores, exceto quando absolutamente necessário.
• Seguir convenções mesmo que o banco atual não exija, pensando em portabilidade futura.

Exemplo de escrita ideal:

SELECT id, nome, data_nascimento
FROM usuarios
WHERE idade > 18
ORDER BY nome ASC;

---

Bônus: E se eu quiser escrever tudo em minúsculo?

Tecnicamente é possível:

select id, nome from usuarios where idade > 18;

Mas profissionalmente, não é recomendado.
Se você quer demonstrar domínio técnico e respeito por padrões consolidados, mantenha as boas práticas.

---

Conclusão

Embora SQL seja case-insensitive por padrão, a diferença entre escrever palavras-chave em maiúsculas e identificadores em minúsculas vai além da interpretação do motor de banco de dados: é uma questão de padrão técnico, clareza, manutenção e respeito ao histórico da linguagem.

Em ambientes sérios, usar convenções claras é sinal de profissionalismo — e pode evitar dores de cabeça no futuro.

Escrever SQL bonito é escrever para humanos.