SQL Formatter & Beautifier

1. Uppercase keywords

Industry convention: SQL keywords (SELECT, FROM, WHERE, JOIN) in UPPERCASE; identifiers (table/column names) in lowercase or original case. This makes structure visually distinct.

SELECT id, name, email
FROM users
WHERE created_at > '2024-01-01'
ORDER BY created_at DESC;

2. Vertical column lists

Each SELECT column on its own line, comma-first or comma-last. Comma-first style (Python/Haskell-influenced) makes adding/removing columns easier in version control.

-- Comma-first
SELECT
    id
  , name
  , email

-- Comma-last (more common)
SELECT
    id,
    name,
    email

3. Aligned JOINs

Each JOIN on its own line, with ON conditions clearly indented. Helps trace relationships at a glance:

SELECT u.id, o.total
FROM users u
INNER JOIN orders o ON u.id = o.user_id
LEFT JOIN payments p ON o.id = p.order_id
WHERE u.active = TRUE;

4. CTEs (WITH clauses) for readability

Modern SQL prefers Common Table Expressions over nested subqueries — easier to read, debug, and refactor:

WITH recent_orders AS (
    SELECT user_id, COUNT(*) AS order_count
    FROM orders
    WHERE created_at > NOW() - INTERVAL '30 days'
    GROUP BY user_id
),
top_users AS (
    SELECT user_id
    FROM recent_orders
    WHERE order_count > 10
)
SELECT u.email
FROM users u
INNER JOIN top_users t ON u.id = t.user_id;

5. Snake_case for identifiers

created_at, user_id, order_total — snake_case is conventional in PostgreSQL, MySQL, BigQuery. Some systems (Oracle, SQL Server) traditionally use UPPER_CASE for identifiers, but snake_case has won in modern use.

1. SELECT only what you need

SELECT * is convenient for ad-hoc queries but costly in production — sends unnecessary bytes over the wire and prevents some index optimizations. List columns explicitly.

2. Use EXPLAIN to see the plan

EXPLAIN SELECT ... shows how the database will execute your query. EXPLAIN ANALYZE actually runs it and shows real row counts. Look for Seq Scan on large tables (need an index) and Hash Join on huge result sets.

3. Index your WHERE columns

Any column you filter on (WHERE clause) or sort by (ORDER BY) should usually be indexed. Without indexes, the database scans every row. With indexes, it jumps directly to matching rows. Indexes have a write cost — don't index everything.

4. Avoid functions on indexed columns

WHERE LOWER(email) = 'foo@bar.com' can't use the index on email. Either store pre-lowercased values, use a functional index (CREATE INDEX ON users(LOWER(email))), or use case-insensitive collation.

5. Use LIMIT for previews

When testing queries, always LIMIT 100 first. SELECT statements without LIMIT on large tables can cause memory issues or block writers — especially in MySQL with InnoDB row locking.

Which SQL dialects are supported?

The formatter handles standard SQL common across MySQL, PostgreSQL, SQLite, SQL Server, Oracle, BigQuery, and Snowflake. It focuses on structural formatting rather than dialect-specific validation. Most queries — even with dialect-specific functions — format correctly.

Does it validate my SQL?

No — this tool only formats whitespace and indentation. It doesn't check syntax, validate against a schema, or evaluate logic. Always test queries against your actual database. For validation, use your DB client's syntax checker or tools like sqlfluff (linter) and pganalyze.

Should I uppercase or lowercase keywords?

Industry convention favors UPPERCASE for SQL keywords — makes structure visually distinct from identifiers. Some modern style guides (BigQuery's, dbt's) prefer lowercase for everything. Consistency within a project matters more than which convention.

Where do my SQL comments go?

The formatter preserves comments — both -- inline and /* block */ styles — at their original positions. They appear above or alongside the line they annotated.

Can I format DDL (CREATE TABLE, ALTER TABLE)?

Yes. CREATE TABLE column definitions, foreign key constraints, and ALTER TABLE statements format with aligned column types and constraints.

What about stored procedures?

Basic procedural SQL (BEGIN/END blocks, IF/ELSE, loops) formats reasonably, but very long procedures may need manual cleanup. For complex stored procedure work, dialect-specific tools like SSMS (SQL Server) or pgFormatter (PostgreSQL) provide better support.