SQL Formatting Best Practices: How to Write Clean, Readable Queries

SQL queries frequently live in production codebases, business intelligence dashboards, and data engineering pipelines for years. Yet unformatted SQL—written as a 300-word single-line wall of lowercase text—is among the most common sources of production bugs, accidental full-table scans, and wasted code review time.

Adopting consistent SQL formatting standards transforms complex data logic into readable, self-documenting code that entire engineering teams can maintain effortlessly.

---

The Four Golden Rules of SQL Style

Whether your team uses PostgreSQL, MySQL, Snowflake, BigQuery, or SQL Server, following these four rules guarantees clarity:

1. Capitalize All SQL Reserved Keywords

Always capitalize clauses, functions, and operators (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, COUNT(), COALESCE). Keep table and column names in lowercase snake_case. This provides immediate visual separation between relational language syntax and schema entities.

2. Put Each Selected Column on Its Own Line

Avoid stacking column names on a single horizontal line. Placing each column on a dedicated indented line makes Git diffs clean when columns are added, removed, or aliased. Leading commas are optional, but consistent comma placement is essential.

3. Structure JOINs and ON Conditions Logically

Isolate table references and their respective join conditions:

• Place the JOIN keyword on a new line.
• Indent the ON condition by 2 or 4 spaces directly underneath.
• State explicit join types (INNER JOIN, LEFT JOIN) rather than plain JOIN or comma-separated tables.

4. Align AND / OR Predicates in WHERE Clauses

When combining multiple search conditions, put each AND or OR operator on a new line. Always wrap mixed AND and OR logic in explicit parentheses to avoid precedence ambiguity.

---

Before and After: Real-World Formatting Example

Unformatted Spaghetti Query

select u.id, u.email, count(o.id) as order_count, sum(o.total) as lifetime_spend from users u left join orders o on u.id = o.user_id where u.status = 'active' and o.created_at >= '2026-01-01' and (u.country = 'US' or u.country = 'CA') group by u.id, u.email having count(o.id) > 5 order by lifetime_spend desc;

Formatted, Production-Ready Query

SELECT
  u.id,
  u.email,
  COUNT(o.id) AS order_count,
  SUM(o.total) AS lifetime_spend
FROM users AS u
LEFT JOIN orders AS o
  ON u.id = o.user_id
WHERE u.status = 'active'
  AND o.created_at >= '2026-01-01'
  AND (u.country = 'US' OR u.country = 'CA')
GROUP BY
  u.id,
  u.email
HAVING COUNT(o.id) > 5
ORDER BY lifetime_spend DESC;

---

CTEs (Common Table Expressions) vs Deeply Nested Subqueries

Deeply nested subqueries force developers to read queries "inside-out." Modern SQL standards recommend replacing nested derived tables with WITH clause Common Table Expressions (CTEs):

WITH customer_orders AS (
  SELECT user_id, COUNT(*) AS total_orders
  FROM orders
  GROUP BY user_id
)
SELECT u.name, co.total_orders
FROM users AS u
JOIN customer_orders AS co
  ON u.id = co.user_id;

CTEs break complex analytical pipelines into sequential, modular logic blocks that can be inspected and tested independently.

---

Beautify Your SQL in 1 Click

Need to format a gnarly multi-table query right now without configuring local linters? Paste your code into our free SQL Formatter. It supports dialect-specific indentation, automatic keyword capitalization, and instant clipboard copying in zero latency.