SQL Formatter

Why formatting SQL matters

A SQL query on one line with no formatting is the closest thing to reading assembly in a business setting. When that query fails in production at 3 AM and you need to debug, you lose minutes just mentally parsing it. Well-indented SQL: each clause on its line, joins aligned, conditions stacked. The difference between finding the bug in 30 seconds or in 5 minutes.

Most-used formatting conventions

• Uppercase keywords. SELECT, FROM, WHERE, JOIN. Visual contrast against lowercase table and column names.
• Each clause on a new line. SELECT, FROM, WHERE, GROUP BY, ORDER BY, LIMIT always break.
• JOINs on their own line. Easy to read each join when isolated.
• Leading or trailing commas. Two schools; the formatter respects your team style if configured.
• Indent subqueries. Subqueries indent further than the main query.

When NOT to format

• Trivial queries. SELECT * FROM users WHERE id = 1 doesn't need line breaks.
• Bulk migrations. A script with hundreds of INSERTs becomes huge and unreadable when formatted line-by-line.
• ORM-generated SQL. SQL emitted by Sequelize or Hibernate is optimized for machines; manual formatting adds nothing.

Stripe / Linear / Vercel SQL style

Modern companies tend toward this style: uppercase keywords, one column per line in SELECT, consistent 2-space indent, JOINs after FROM. A SELECT returning 8 columns looks like:

SELECT
  u.id,
  u.name,
  u.email,
  COUNT(o.id) AS total_orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name, u.email
ORDER BY total_orders DESC
LIMIT 10;

Formatter limitations

This is a basic formatter that handles most everyday queries: SELECT, INSERT, UPDATE, DELETE with joins, where, group by, order by, having, limit. It doesn't fully interpret complex CTEs (WITH RECURSIVE), window functions with peculiar syntax, or strongly-deviating dialects (T-SQL, PL/SQL). For those edge cases, consider dialect-specific formatters.

Readable SQL and internal hygiene

In larger companies a pattern emerges: critical queries live in a versioned folder in git. The data team edits, reviews, commits them. Unformatted queries make reviews painful and bugs slip through. Pinning a uniform format and enforcing it in pre-commit hooks is one of those small changes that compounds.

Productivity tips

• If you use DataGrip, IntelliJ or DBeaver, they ship formatters that respect your preferences. Configure once and stop fighting format.
• In JavaScript/TypeScript, consider tagged template literals like sql\`SELECT ...\`. Editor extensions such as vscode-sql-template-literal give you autocomplete and formatting.
• For long queries living in migrations, comment each major block with -- purpose of this JOIN. Future-you will thank you.