Skip to content
koducathome

PostgreSQL Formatter

Format and beautify PostgreSQL queries: $1 parameters, ::casts, RETURNING and JSONB operators like ->> and @> — with keyword case and indentation options.

How to use this tool

Steps for using the SQL Formatter.

  1. Paste your PostgreSQL query into Input SQL — PostgreSQL is already selected under Dialect, so its quoting, parameters and operators are understood.
  2. Pick Keyword case (UPPERCASE, lowercase or Preserve) and Indentation, and open Formatting options for indent style, AND / OR placement and line width.
  3. Choose an Action: Format to beautify, Minify to put it on one line, Validate to check the syntax, or Explain for a plain-English summary.
  4. Copy or download the result. Formatting only changes whitespace and keyword case — the query does the same thing.

Example

Parameters and RETURNING

PostgreSQL
update accounts set balance = balance - $1, updated_at = now() where id = $2 and balance >= $1 returning id, balance
Formatted
UPDATE accounts
SET
  balance = balance - $1,
  updated_at = now()
WHERE
  id = $2
  AND balance >= $1
RETURNING
  id,
  balance

Common use cases

  • Reading queries from pg_stat_statements, logs or an ORM's SQL output.
  • Reviewing migrations and views before committing them.
  • Making JSONB queries readable when debugging application data.
  • Formatting SQL for pull requests and documentation.

Formatting PostgreSQL's extra syntax

PostgreSQL adds syntax that generic formatters often trip over: positional parameters ($1, $2) from prepared statements and drivers like node-postgres, casts with :: ('{}'::jsonb), and JSON operators such as ->, ->> and @>. With the PostgreSQL dialect selected, all of these are recognised.

RETURNING, ON CONFLICT … DO UPDATE and LIMIT/OFFSET keep their meaning and get their own lines. The formatter only changes layout and keyword case — the second example is the same JSONB query, laid out so each condition is visible.

Formatting is especially useful for queries copied from pg_stat_statements, server logs or an ORM's debug output, which arrive as one long line with parameters already in place.

The same dialect works for Amazon Aurora PostgreSQL and most Postgres-compatible services; Amazon Redshift has its own dialect in the full formatter. Other databases: SQL Server, MySQL, Oracle.

Limitations

  • The formatter doesn't know your database schema — unknown tables or columns aren't detected.
  • PL/pgSQL function bodies inside $$ … $$ are kept as written rather than reformatted.
  • Comments are kept, but their position may change slightly around reformatted lines.

Frequently asked questions

Does the formatter understand $1 parameters?

Yes. With the PostgreSQL dialect selected, $1, $2 … are treated as parameters and left as written.

Are ::casts and JSON operators kept?

Yes. Casts like ::text and ::jsonb and operators such as ->, ->> and @> are recognised; only spacing and line breaks change.

How do I format SQL in psql or pgAdmin?

psql has no formatter. pgAdmin's Query Tool has a Format SQL option; for consistent keyword case and indentation everywhere, paste the query here.

Is my query sent to a server?

No. The PostgreSQL formatter runs entirely in your browser.