PostgreSQL Query Formatter
Format PostgreSQL queries with the PostgreSQL grammar, so :: casts, JSONB operators, dollar-quoted strings, CTEs and window functions are formatted correctly. The compatibility check then looks for syntax from MySQL or SQL Server that PostgreSQL rejects or reads differently: backticks, LIMIT offset, count, double-quoted strings, IFNULL, GROUP_CONCAT, ON DUPLICATE KEY and more.
- Runs in your browser
- No sign-up
- Free to use
How to use PostgreSQL Query Formatter
- Paste your PostgreSQL query.
- Choose keyword and function case and indentation.
- Click Format and review the compatibility notes.
- Copy or download the result.
PostgreSQL Query Formatter features
Postgres grammar
CTEs, :: casts, ->> operators, arrays and window functions.
Style options
Keyword and function case, indentation and statement spacing.
MySQL detection
Backticks, LIMIT x, y, IFNULL, GROUP_CONCAT, AUTO_INCREMENT.
Quote check
Finds "text" used as a string, which Postgres reads as a column.
Case-sensitivity hint
Reminds that LIKE is case-sensitive; ILIKE is not.
Local
Formatted in your browser; nothing is executed.
When to use PostgreSQL Query Formatter
- Formatting queries before committing them to a repository.
- Migrating an application from MySQL to PostgreSQL.
- Reading queries copied from pg_stat_statements or logs.
- Teaching PostgreSQL syntax and conventions.
PostgreSQL Query Formatter FAQ
Why are double quotes flagged?
In PostgreSQL, double quotes delimit identifiers. WHERE name = "Ada" looks for a column called Ada and fails; strings need single quotes.
Why is LIKE mentioned?
LIKE is case-sensitive in PostgreSQL, unlike MySQL. Use ILIKE or compare lower(column) when you need case-insensitive matching.
What happens to LIMIT 10, 20?
That is MySQL syntax. PostgreSQL needs LIMIT 20 OFFSET 10, which the checker suggests.
Are dollar-quoted function bodies kept?
Yes, $$ … $$ blocks are treated as strings and left untouched.
Does it change my query?
Only whitespace and keyword case change.
Is anything uploaded?
No. Formatting runs in your browser.
Formatting and porting PostgreSQL
PostgreSQL’s SQL dialect is rich: common table expressions, lateral joins, window functions, arrays, JSONB operators and casts written with ::. A formatter that does not know these constructs breaks them or formats them oddly. This tool uses the PostgreSQL grammar of the sql-formatter library, which understands them and keeps operators such as ->> and @> intact.
Style options cover the usual preferences. A common PostgreSQL convention writes keywords in upper case and function names in lower case, matching the documentation, with four-space indentation; you can switch any of these.
The compatibility check is aimed at a frequent situation: queries written for MySQL or SQL Server moving to PostgreSQL. Backtick-quoted names must become double quotes, LIMIT offset, count must become LIMIT count OFFSET offset, IFNULL becomes COALESCE, GROUP_CONCAT becomes string_agg, DATE_FORMAT becomes to_char and ON DUPLICATE KEY UPDATE becomes ON CONFLICT … DO UPDATE.
One difference causes errors that are hard to understand: double quotes. MySQL accepts "text" as a string; PostgreSQL treats it as an identifier and complains that a column does not exist. The checker recognises comparisons with double-quoted values and explains the fix.
Another difference changes results without an error. LIKE is case-sensitive in PostgreSQL, so a search that found “Ada” in MySQL may find nothing. The checker reminds you of ILIKE, together with general warnings about UPDATE or DELETE without WHERE, = NULL and NOT IN with subqueries.