SQL beautifier examples

See How Easy SQL Formatting and Beautification Can Be with AI

Explore practical before-and-after SQL formatting examples to find the best style for your team. Use these samples to standardize SQL formatting and improve readability across analytics and production queries.

  • Compare unformatted SQL and formatted SQL side by side
  • See DEFAULT, COMPACT, COLLAPSED, LEADING COMMA, RIGHT and LEFT alignment styles
  • Improve query readability for debugging, review, and documentation
  • Apply consistent SQL formatting patterns across PostgreSQL workflows

What these SQL formatter examples cover

This page shows unformatted SQL query input and formatter output side by side, so you can evaluate readability differences quickly. The examples are for PostgreSQL database but all common databases are support, e.g. MySQL, Oracle, MS SQL Sever.

Use these SQL formatting examples to create team standards, reduce review friction, and keep SQL scripts consistent across repositories.

SQL formatter style examples

Compare the same SQL query formatted in different styles to pick the output that best fits your team conventions and review workflow.

Example 1: DEFAULT style

Unformatted SQL input

select p.name as product_name,u.username,r.comment,tag_element.tag from reviews r join products p on r.product_id=p.product_id join users u on r.user_id=u.user_id cross join lateral jsonb_array_elements_text(r.metadata -> 'tags') as tag_element(tag) where r.rating=5 and r.metadata ->> 'verified_purchase'='true';

Formatted SQL output

SELECT
  p.name AS product_name,
  u.username,
  r.comment,
  tag_element.tag
FROM
  reviews r
  JOIN products p ON r.product_id = p.product_id
  JOIN users u ON r.user_id = u.user_id
  CROSS JOIN LATERAL jsonb_array_elements_text(r.metadata -> 'tags') AS tag_element(tag)
WHERE
  r.rating = 5
  AND r.metadata ->> 'verified_purchase' = 'true';

Balanced readability for day-to-day SQL development, pull requests, and pair review sessions.

Example 2: COMPACT style

Unformatted SQL input

select p.name as product_name,u.username,r.comment,tag_element.tag from reviews r join products p on r.product_id=p.product_id join users u on r.user_id=u.user_id cross join lateral jsonb_array_elements_text(r.metadata -> 'tags') as tag_element(tag) where r.rating=5 and r.metadata ->> 'verified_purchase'='true';

Formatted SQL output

SELECT p.name AS product_name,
       u.username,
       r.comment,
       tag_element.tag
FROM reviews r
JOIN products p ON r.product_id = p.product_id
JOIN users u ON r.user_id = u.user_id
CROSS JOIN LATERAL jsonb_array_elements_text(r.metadata -> 'tags') AS tag_element(tag)
WHERE r.rating = 5
  AND r.metadata ->> 'verified_purchase' = 'true';

Uses fewer line breaks while keeping each clause legible for dashboards, docs, and runbooks.

Example 3: COLLAPSED style

Unformatted SQL input

select p.name as product_name,u.username,r.comment,tag_element.tag from reviews r join products p on r.product_id=p.product_id join users u on r.user_id=u.user_id cross join lateral jsonb_array_elements_text(r.metadata -> 'tags') as tag_element(tag) where r.rating=5 and r.metadata ->> 'verified_purchase'='true';

Formatted SQL output

SELECT p.name AS product_name, u.username, r.comment, tag_element.tag FROM reviews r JOIN products p ON r.product_id = p.product_id JOIN users u ON r.user_id = u.user_id CROSS JOIN LATERAL jsonb_array_elements_text(r.metadata -> 'tags') AS tag_element(tag) WHERE r.rating = 5 AND r.metadata ->> 'verified_purchase' = 'true';

Best for logs or metadata fields where SQL must stay on one line.

Example 4: LEADING COMMA style

Unformatted SQL input

select p.name as product_name,u.username,r.comment,tag_element.tag from reviews r join products p on r.product_id=p.product_id join users u on r.user_id=u.user_id cross join lateral jsonb_array_elements_text(r.metadata -> 'tags') as tag_element(tag) where r.rating=5 and r.metadata ->> 'verified_purchase'='true';

Formatted SQL output

SELECT
  p.name AS product_name
 ,u.username
 ,r.comment
 ,tag_element.tag
FROM
  reviews r
  JOIN products p ON r.product_id = p.product_id
  JOIN users u ON r.user_id = u.user_id
  CROSS JOIN LATERAL jsonb_array_elements_text(r.metadata -> 'tags') AS tag_element(tag)
WHERE
  r.rating = 5
  AND r.metadata ->> 'verified_purchase' = 'true';

Popular for teams that want cleaner diffs when adding or removing columns in SELECT lists.

Example 5: RIGHT ALIGNED style

Unformatted SQL input

select p.name as product_name,u.username,r.comment,tag_element.tag from reviews r join products p on r.product_id=p.product_id join users u on r.user_id=u.user_id cross join lateral jsonb_array_elements_text(r.metadata -> 'tags') as tag_element(tag) where r.rating=5 and r.metadata ->> 'verified_purchase'='true';

Formatted SQL output

SELECT p.name          AS product_name,
          u.username,
          r.comment,
          tag_element.tag
     FROM reviews r
     JOIN products p ON r.product_id = p.product_id
     JOIN users u ON r.user_id = u.user_id
CROSS JOIN LATERAL jsonb_array_elements_text(r.metadata -> 'tags') AS tag_element(tag)
    WHERE r.rating = 5
      AND r.metadata ->> 'verified_purchase' = 'true';

Emphasizes visual alignment to scan selected columns and SQL blocks quickly.

Example 6: LEFT ALIGNED style

Unformatted SQL input

select p.name as product_name,u.username,r.comment,tag_element.tag from reviews r join products p on r.product_id=p.product_id join users u on r.user_id=u.user_id cross join lateral jsonb_array_elements_text(r.metadata -> 'tags') as tag_element(tag) where r.rating=5 and r.metadata ->> 'verified_purchase'='true';

Formatted SQL output

SELECT    p.name AS product_name,
          u.username,
          r.comment,
          tag_element.tag
FROM      reviews r
JOIN      products p ON r.product_id = p.product_id
JOIN      users u ON r.user_id = u.user_id
CROSS JOIN LATERAL jsonb_array_elements_text(r.metadata -> 'tags') AS tag_element(tag)
WHERE     r.rating = 5
AND       r.metadata ->> 'verified_purchase' = 'true';

Keeps SQL keywords vertically aligned when your team prefers fixed-column layouts.

Readable SQL transformation examples

Review before-and-after SQL formatting for real-world patterns such as CTEs, window functions, and conditional updates.

Example 1: CTE + grouped revenue query

Unformatted SQL input

with monthly_sales as (select date_trunc('month',o.order_date)::date as sales_month,sum(oi.quantity*oi.price_at_purchase) as revenue from orders o join order_items oi on oi.order_id=o.order_id where o.order_date>=date '2025-01-01' and o.order_date<date '2026-01-01' group by 1) select sales_month,revenue from monthly_sales where revenue>10000 order by revenue desc;

Formatted SQL output

WITH monthly_sales AS (
  SELECT
    date_trunc('month', o.order_date)::date AS sales_month,
    SUM(oi.quantity * oi.price_at_purchase) AS revenue
  FROM orders o
  JOIN order_items oi ON oi.order_id = o.order_id
  WHERE
    o.order_date >= date '2025-01-01'
    AND o.order_date < date '2026-01-01'
  GROUP BY 1
)
SELECT
  sales_month,
  revenue
FROM monthly_sales
WHERE revenue > 10000
ORDER BY revenue DESC;

Formatting CTEs with clear blocks makes aggregate logic easier to audit and debug.

Example 2: Window function query

Unformatted SQL input

select department,employee_id,salary,sum(salary) over(partition by department order by hire_date rows between unbounded preceding and current row) as running_salary from employees where is_active=true;

Formatted SQL output

SELECT
  department,
  employee_id,
  salary,
  SUM(salary) OVER (
    PARTITION BY department
    ORDER BY hire_date
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS running_salary
FROM employees
WHERE is_active = true;

Window clauses become substantially easier to read when each frame and partition line is isolated.

Example 3: UPDATE with CASE expression

Unformatted SQL input

update subscriptions set status=case when canceled_at is not null then 'canceled' when expires_at<now() then 'expired' else 'active' end,updated_at=now() where tenant_id=42 returning subscription_id,status,updated_at;

Formatted SQL output

UPDATE subscriptions
SET
  status = CASE
    WHEN canceled_at IS NOT NULL THEN 'canceled'
    WHEN expires_at < now() THEN 'expired'
    ELSE 'active'
  END,
  updated_at = now()
WHERE tenant_id = 42
RETURNING
  subscription_id,
  status,
  updated_at;

Multi-branch CASE updates are safer to review when conditions and returned fields are fully expanded.

Example 4: JSON filter with explicit predicates

Unformatted SQL input

select id,event_name,payload->>'source' as source,created_at from events where payload ? 'source' and payload->>'source' in ('web','api') and created_at>=now()-interval '30 days' order by created_at desc limit 100;

Formatted SQL output

SELECT
  id,
  event_name,
  payload ->> 'source' AS source,
  created_at
FROM events
WHERE
  payload ? 'source'
  AND payload ->> 'source' IN ('web', 'api')
  AND created_at >= now() - interval '30 days'
ORDER BY created_at DESC
LIMIT 100;

Formatted JSON operators improve readability and reduce predicate mistakes in analytics queries.

SQL formatting checklist for readability

Use this checklist to keep SQL style consistent and easy to scan across code reviews, migrations, and analytics notebooks.

  • Break long SELECT lists into one column per line for easier diff review.
  • Keep JOINs and predicates on separate lines to reduce missed conditions.
  • Use consistent casing and indentation to improve SQL team readability.
  • Choose one comma strategy and enforce it in every query example.

After formatting, validate and improve your query with the SQL validator, SQL optimizer, and SQL explainer.

SQL formatter FAQ

What does an SQL formatter do?

An SQL formatter rewrites query layout without changing query logic. It adds line breaks, indentation, and consistent keyword styling to make SQL easier to read.

Does SQL formatting change query performance?

Formatting itself does not change runtime behavior. It only changes presentation, but better readability helps teams identify optimization opportunities faster.

Which SQL formatting style should I use?

Pick the style that matches your code review culture and stick to it. Consistency across all queries is usually more important than the specific style selected.