What SQL formatting changes
SQL formatting standardizes the visual presentation of a query without changing what it does. Keywords like SELECT, FROM, WHERE, JOIN, and GROUP BY are uppercased. Each clause starts on a new line. Nested subqueries are indented to show hierarchy. Column lists are aligned.
The before and after are functionally identical — the database executes both the same way. The formatted version just lets a human understand the query's structure in a few seconds instead of a few minutes.
Consistent formatting across a codebase also makes version control diffs more useful. A diff between two versions of a query is meaningful when both follow the same formatting convention; otherwise a reformatting commit obscures the actual logic change.
- Uppercase SQL keywords (SELECT, WHERE, JOIN, etc.)
- Line breaks between major clauses
- Indentation for subqueries and nested conditions
- Consistent comma placement
- Alignment of column lists in SELECT
SQL dialects and compatibility
Standard SQL (ANSI SQL) covers the core syntax, but every major database has its own extensions. PostgreSQL, MySQL, SQL Server, Oracle, and SQLite each have proprietary syntax for things like window functions, string functions, and data types.
A general-purpose SQL formatter works on the common syntax but may not handle dialect-specific features perfectly. For most formatting tasks — indenting SELECT queries, formatting WHERE clauses, breaking up long JOINs — dialect differences don't matter.
The Irreva SQL Formatter handles standard SQL and common syntax from MySQL, PostgreSQL, and SQL Server. If you use exotic dialect-specific syntax, review the output after formatting.
Best practices for readable SQL
Use meaningful aliases. FROM customers AS c is more readable than FROM customers c, and JOIN orders AS o instead of just o. Abbreviations are fine as long as they're consistent.
Put each selected column on its own line when the SELECT list is long. This makes it easy to add or remove columns and makes the query's output clear at a glance.
Write JOINs in the order they logically relate. The main table first, then the tables that extend it. Add comments above complex subqueries or CTEs explaining what they compute. SQL doesn't get enough inline documentation.