SQL Keywords: Uppercase or Lowercase? The Casing Debate Settled

Few style arguments in programming have run as long as this one: should SQL keywords be written as SELECT, FROM, and WHERE — or as select, from, and where? The database does not care. Every major engine treats keywords as case-insensitive, so both versions run identically. Yet teams still argue about it in code reviews, and style guides still take opposite sides. This article walks through where the uppercase convention came from, the honest arguments for each style, what popular guides actually recommend, and the one rule that matters more than the choice itself.

Where the Uppercase Convention Came From

SQL was designed in the 1970s and spread through terminals, printed manuals, and plain monochrome text editors. There was no syntax highlighting. On a green-on-black screen, the only way to make keywords visually distinct from table and column names was to change their shape — and uppercase letters do that very effectively:

-- On a 1980s terminal, this structure is instantly visible:
SELECT customer_name, SUM(order_total)
FROM orders
WHERE order_date >= '1989-01-01'
GROUP BY customer_name;

-- Without casing or colour, this is a wall of words:
select customer_name, sum(order_total)
from orders
where order_date >= '1989-01-01'
group by customer_name;

Textbooks, vendor documentation, and certification exams all adopted uppercase keywords because it genuinely was the best readability tool available. Generations of developers learned SQL from those materials, and the convention became self-reinforcing: uppercase looked "professional" because everything professional used uppercase.

The Case for Uppercase Keywords

• Structure survives anywhere — log files, error messages, plain-text emails, chat messages, and terminal output rarely have highlighting. Uppercase keywords keep the query skeleton visible in all of them.
• Matches most documentation — official docs for MySQL, PostgreSQL, SQL Server, and Oracle overwhelmingly use uppercase, so your code visually matches the references your team reads.
• Clear keyword/identifier split — when keywords are uppercase and identifiers are lowercase snake_case, you can tell at a glance that order is a column but ORDER is part of ORDER BY.
• Easier scanning of long scripts — in a 500-line migration file, uppercase SELECT and UPDATE act like headings you can skim for.

The Case for Lowercase Keywords

• Highlighting already does the job — every modern editor, IDE, and code host colours keywords. The original problem uppercase solved largely no longer exists.
• Less typing friction — no hammering Shift or toggling Caps Lock while writing exploratory queries. Small, but it adds up over hundreds of queries a week.
• Reads like prose — some developers find all-caps words visually loud, like scattered shouting in an otherwise calm paragraph.
• Consistent with host languages — SQL embedded in Python, JavaScript, or Go sits inside codebases that are almost entirely lowercase; lowercase SQL blends in rather than jumping out.

What Popular Style Guides Choose

The published guides split roughly along generational lines:

• Joe Celko's SQL Programming Style — the classic enterprise reference: uppercase keywords, lowercase identifiers.
• Simon Holywell's sqlstyle.guide — one of the most-cited modern guides: uppercase keywords, aligned rivers of whitespace.
• GitLab's SQL style guide — lowercase keywords throughout, on the grounds that highlighting makes uppercase redundant.
• dbt community conventions — most public dbt projects and linters like SQLFluff default to lowercase, though SQLFluff lets you enforce either with a single config line.
• Most ORMs and query builders — generated SQL is typically uppercase, so teams that read a lot of generated queries often stick with uppercase for consistency.

Notice the pattern: guides written for printed books and heterogeneous tooling choose uppercase; guides written for modern analytics codebases with enforced linting choose lowercase. Both are defensible because both are optimising for the environment their authors work in.

Consistency Beats Either Choice

Here is the uncomfortable truth for both camps: mixed casing is worse than either pure style. A query like this forces the reader to stop and check whether the inconsistency means something:

-- Mixed casing: was "Select" edited by a different person?
-- Is "LEFT JOIN" uppercase because it is important? (No.)
Select u.name, count(o.id) AS order_count
FROM users u
LEFT JOIN orders o on o.user_id = u.id
where u.status = 'active'
Group By u.name;

Inconsistency creates noise in code review diffs, makes grep-style searching harder, and signals that nobody owns the codebase's standards. The fix is procedural, not philosophical:

• Pick one style as a team — flip a coin if you must, the decision matters less than making it.
• Write it down in your style guide or CONTRIBUTING file.
• Enforce it with tooling — a formatter or linter — so humans never argue about it in review again.

Teams that automate formatting stop having the debate entirely, which is the real win. If you want a deeper look at team-wide standards, see our guide on why consistent SQL style matters for teams.

A Balanced Conclusion

If your SQL lives mostly in modern editors with highlighting, reviewed on GitHub or GitLab, lowercase is a perfectly rational modern default. If your SQL regularly appears in logs, plain-text runbooks, terminal sessions, or documentation — or your team simply grew up on uppercase — uppercase remains a solid choice that costs nothing. What is not rational is letting each developer choose per file. Choose once, automate enforcement, and spend your review energy on logic instead of letter shapes.

Frequently Asked Questions