Does the dialect setting in a SQL formatter really matter?

More than most people expect. In our test, three of five dialect-specific queries failed to parse at all under generic standard SQL, returning a parse error instead of formatted output. The dialect does not adjust cosmetics — it decides whether the formatter understands the query.

Why did some queries format identically under the wrong dialect?

Because the parser happened to tolerate the syntax. Backtick-quoted BigQuery table names and Oracle's legacy plus-in-parentheses outer join both came out byte-identical under standard SQL. That is luck, not compatibility, and it teaches the wrong lesson — the dropdown looks like it does nothing until the day it does.

What is the difference between MySQL and MariaDB in a formatter?

For everyday queries, very little — MariaDB began as a MySQL fork and the core grammar overlaps heavily. They are listed separately because the keyword sets have drifted apart over time. If one throws a parse error on a statement, try the other before assuming the SQL is wrong.

Does formatting change what the query does?

No. A formatter rewrites whitespace, line breaks and keyword case. It does not reorder clauses or alter semantics. If output ever differs semantically from input, that is a bug, and the safe habit is to run the formatted version against a plan or a test before committing it.

Should keywords be uppercase?

It is a house-style question with no correct answer. Uppercase keywords are the older convention and make structure scan quickly in long queries; lowercase reads more calmly and is common in modern dbt and analytics codebases. Pick one and apply it consistently — a formatter with a keyword-case setting makes that a single toggle.

Is it safe to paste production SQL into an online formatter?

It depends entirely on whether the tool sends it anywhere. Query text routinely contains table names, column names, business logic and sometimes literal values from real records. Pickrack's formatter runs in the browser, so nothing is transmitted — open DevTools and watch the Network tab while you format to confirm it.

SQL Formatter Dialects: What Actually Breaks When You Pick the Wrong One

Q: Which dialect should I pick if I am not sure?

Read the syntax rather than guessing the database. Double-colon casts mean PostgreSQL, Redshift or Snowflake. Square brackets mean T-SQL. TOP means T-SQL. LATERAL FLATTEN means Snowflake. The query usually identifies itself.

Q: How many dialects does Pickrack support?

Eleven: MySQL, MariaDB, PostgreSQL, SQLite, T-SQL, BigQuery, Snowflake, Redshift, Oracle PL/SQL, Spark, and generic standard SQL, plus keyword case and indentation options.

Most SQL formatters have a dialect dropdown. Most people leave it wherever it was.

So we tested what that costs. Same five queries, each formatted twice — once under its correct dialect, once under generic standard SQL — using the same engine that powers Pickrack's SQL Formatter.

The results were more lopsided than expected, and the surprising half is not the failures.

What happened

Query	Correct dialect	Under generic SQL
Double-colon cast, `->>` JSONB operator	PostgreSQL	Parse error
Bracket identifiers, `TOP 10`	T-SQL	Parse error
`LATERAL FLATTEN`	Snowflake	Parse error
Backtick-quoted `project.dataset.table`	BigQuery	Byte-identical
Legacy `(+)` outer join	Oracle PL/SQL	Byte-identical

Three of five did not produce badly formatted SQL. They produced no SQL at all:

Error: Parse error: Unexpected "::int as a" at line 1 column 57.
Error: Parse error: Unexpected "[Order ID]" at line 1 column 15.
Error: Parse error: Unexpected "::string a" at line 1 column 15.

The dialect setting is not a cosmetic preference. It decides whether the formatter can read your query.

The dangerous half is the two that worked

A BigQuery query with backtick-quoted table names formatted perfectly under standard SQL. So did Oracle's legacy outer join, plus sign and all — byte-for-byte identical output.

That is not compatibility. That is a parser that happened to tolerate the syntax it was handed.

And it is exactly how people learn that the dropdown does not matter. You format a few queries, nothing goes wrong, you stop thinking about it. Then one day a colleague sends you a Snowflake query with a :: cast and the tool throws a parse error at column 15, and now you are debugging SQL that was never broken.

The setting looks inert right up until it isn't.

The four things that pin a dialect

You rarely need to know which warehouse a query came from. The query says so.

Double-colon casts. (payload->>'age')::int is PostgreSQL, Redshift or Snowflake. Standard SQL has no :: operator — its parser stops dead at the first one. This was the single most common failure in the test, appearing in two of the three errors.

Identifier quoting. Square brackets — [dbo].[Orders] — are T-SQL and nothing else. Backticks are MySQL, MariaDB, BigQuery and Spark. Double quotes are the standard form, used by PostgreSQL and Oracle.

Vendor-only keywords. TOP 10 is T-SQL, where everyone else writes LIMIT. LATERAL FLATTEN is Snowflake. QUALIFY is Snowflake and BigQuery.

Legacy join syntax. A plus sign in parentheses inside a WHERE clause is Oracle's pre-ANSI outer join. It parses under standard SQL by accident, but seeing it tells you what you are holding.

One quirk worth knowing

Formatting the Snowflake case under its correct dialect produced this:

select
  v.value::string as
tag
from
  orders o,
  lateral flatten(input => o.tags) v

The alias broke onto its own line at the wrong point. Not a correctness problem — the SQL is unchanged and still valid — but a cosmetic wobble in how :: casts and aliases interact in the current release. Worth knowing so you do not spend ten minutes wondering whether you broke something.

We use the sql-formatter library and report what it does rather than what we would like it to do.

What formatting does not do

A formatter rewrites whitespace, line breaks and keyword case. It does not reorder clauses, rewrite joins, or change semantics. Format-then-commit is safe in a way that "optimise this query" tooling is not.

Two settings beyond the dialect are worth setting once:

Keyword case. Upper, lower, or preserve. Uppercase is the older convention and makes structure scannable in a long query; lowercase reads more quietly and is the norm in modern dbt and analytics code. There is no right answer — the win is picking one and never arguing about it in review again.

Indentation. Two spaces, four, or tabs. Match whatever your repository already uses.

Where the query goes

Worth a thought before pasting production SQL into any web tool: query text carries table names, column names, business logic, and often literal values pulled from real records. That is a reasonable description of your schema, handed to a third party.

Pickrack's SQL Formatter runs entirely in the browser — the library is loaded into the page and the formatting happens there, so the query is never transmitted. You do not have to take that on trust: open DevTools, go to the Network tab, clear it, and format something. Zero requests. We wrote about why that check matters more than the claim when we covered JWT decoders.

The eleven supported dialects: MySQL, MariaDB, PostgreSQL, SQLite, T-SQL, BigQuery, Snowflake, Redshift, Oracle PL/SQL, Spark, and generic standard SQL.

Bottom line

Set the dialect from the syntax in front of you, not from the database you assume you are querying.

Double colon means PostgreSQL, Redshift or Snowflake. Square brackets mean T-SQL. TOP means T-SQL. LATERAL FLATTEN means Snowflake.

And when a formatter throws a parse error, check the dropdown before you start editing the query. Three times out of five in our test, the query was fine and the dialect was wrong.

Format one now: Pickrack SQL Formatter — eleven dialects, browser-side, no upload.