SQL Keywords Aren't Case-Sensitive — So Why Does Everyone Write Them in Caps?

A convention, not a requirement

Writing SELECT * FROM users versus select * from users makes no functional difference at all — SQL keywords are case-insensitive in every major database engine. Yet the uppercase convention has persisted since SQL's earliest days in the 1970s and remains the dominant style in professional codebases, style guides, and formatting tools today.

Why the convention caught on

The practical reason is pure readability: capitalizing keywords (SELECT, FROM, WHERE, JOIN) creates an immediate visual distinction from your actual data — table names, column names, and values — which usually stay lowercase or mixed case. In a long, complex query with several joins and conditions, that visual separation makes it much faster to scan the query's structure at a glance, rather than reading every word to figure out which parts are SQL syntax and which are your own database's names.

Where case sensitivity actually does matter in SQL

While keywords are always case-insensitive, whether table and column names are case-sensitive depends entirely on the specific database engine and its configuration. PostgreSQL treats unquoted identifiers as case-insensitive but folds them to lowercase internally, while quoted identifiers become case-sensitive. MySQL's behavior for table name case-sensitivity actually depends on the operating system and a specific server setting. This inconsistency across engines is a genuine, recurring source of "works on my machine" bugs when a team moves a database between different systems.

Dialect differences beyond casing

Real dialect differences go well beyond capitalization style: T-SQL (SQL Server), PL/SQL (Oracle), and standard/MySQL SQL have different syntax for things like limiting result rows, string concatenation, and date functions, which is why a formatter or query written for one database often needs adjustment to run correctly on another.

Format consistently across dialects

Our SQL Formatter supports multiple dialects (Standard SQL, MySQL, PostgreSQL, SQL Server, Oracle, SQLite) and reformats a query with proper capitalization and line breaks for whichever one you're targeting.