Unformatted SQL appears everywhere: pull requests, Stack Overflow questions, queries shared on Slack. SQL formatting tells you more about the author than you'd expect.
The Cost of Reading Bad SQL
Here's the kind of query that shows up in code reviews all the time:
SELECT u.name, o.total, o.created_at FROM users u JOIN orders o ON u.id = o.user_id WHERE o.total > 100 AND u.active = 1 AND o.status = 'completed' ORDER BY o.created_at DESC LIMIT 50;
This is one line. One hundred thirty characters. Parsing it takes about 45 seconds. The joins, the filters, and the ordering all run together. Now the same query formatted:
SELECT
u.name,
o.total,
o.created_at
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.total > 100
AND u.active = 1
AND o.status = 'completed'
ORDER BY o.created_at DESC
LIMIT 50;
The structure is obvious. Joins, filters, and ordering sit in separate visual blocks. It reads in about 5 seconds. You don't parse it mentally; you just see it.
If you work with SQL every day, those 40 seconds per query add up. Ten queries a day is seven minutes. A year of that is roughly 30 hours of reading time you get back.
What Formatting Actually Does For You
Formatting has a second job beyond looks: It surfaces bugs.
Missing JOIN conditions hide easily inside a wall of unformatted text. So do WHERE clauses that filter in ways the developer didn't intend. Laid out properly, these problems stick out.
Take this:
SELECT * FROM users WHERE role = 'admin' AND status = 'active' OR status = 'pending';
Without parentheses, operator precedence decides the outcome. This returns all users with role = 'admin' AND status = 'active', plus any user with status = 'pending'. Non-admins included, which is probably not what the query author wanted. The PostgreSQL operator precedence table shows why: AND binds tighter than OR.
Formatted:
SELECT *
FROM users
WHERE role = 'admin'
AND status = 'active'
OR status = 'pending';
The logic stands out immediately. A good SQL Formatter highlights these patterns so you catch them before they hit production.
The same applies to missing JOIN conditions. A query that joins two tables without an ON clause becomes a cross join:
SELECT o.id, c.name
FROM orders o
JOIN customers c
WHERE o.total > 100;
Every order pairs with every customer. In a small table it looks fine; with a few thousand customers it returns millions of rows. Formatted, the missing ON is obvious at a glance.
What Your IDE Won't Do
A common objection: "My IDE formats SQL for me, I don't need a separate tool."
Open your IDE, write a query with 4 JOINs, 2 subqueries, and a CASE statement, and see what the built-in formatter does.
Most IDE formatters are basic. They capitalize keywords and add indentation, but they don't understand structure. Subqueries get flattened. CASE statements become unreadable. Long IN lists overflow onto one line.
| What it handles | Basic IDE formatter | Dedicated formatter |
|---|---|---|
| Keyword capitalization | Yes | Yes |
| Nested subquery indentation | Flattens them | Indents properly |
| CASE / WHEN blocks | Runs together | One WHEN per line |
| Long IN lists | One line | Broken into chunks |
| JOIN alignment | Inconsistent | Aligned |
| CTE separation | Ignored | Separated |
A dedicated SQL formatter handles nested subqueries with proper indentation, CASE statements with each WHEN on its own line, long IN lists broken into readable chunks, JOIN conditions aligned, and CTEs separated. It's the kind of thing you don't notice until you need it at 2 AM debugging a production query.
It's Not Just About You
Junior developers often overlook that other people have to read your SQL.
Your queries end up in code reviews. They get debugged during an incident. They get modified by someone who joined the team six months after you left. SQL formatting is a team habit, not a personal preference. It saves everyone time, including your future self when you're on call.
Make It A Habit
Run every query you write through a formatter, even the simple ones. It takes ten seconds. The formatter handles MySQL, PostgreSQL, SQL Server, and most other dialects. Nothing leaves your browser.
Formatting won't fix a poorly designed query. It will make the poor design visible, which is the first step to fixing it. A query that's hard to read is usually a query that's hard to reason about, and those are the ones where the expensive bugs live.