18 dialects, and what works for each

A dialect is one database's particular version of SQL. The core — SELECT, JOIN, GROUP BY — is standardised and portable, but every engine adds its own syntax for limiting rows, quoting identifiers, declaring auto-incrementing keys, handling dates and naming types. Two databases can both claim SQL support and still refuse each other's queries.

Leave the source on auto-detect. The parser reads the query and infers the dialect from what it finds — backticks imply MySQL, square brackets imply SQL Server, SELECT TOP is a strong signal, and so on. Set it explicitly only when a query is ambiguous enough to be valid in several.

Because support is per-capability, not per-engine, and the table above is generated from the registry rather than written by hand — so it cannot claim something the engine does not do. Formatting and validation work anywhere the grammar is known. Translation needs a mapping in both directions. Diagramming needs DDL. A dialect with a partially implemented grammar shows fewer capabilities rather than silently producing wrong output.

No, and it is not treated as one. It is listed because converting SQL to a MongoDB query or aggregation pipeline is a common need, and the conversion is a genuine translation rather than a syntax swap — JOIN becomes $lookup, GROUP BY becomes $group, and a WHERE clause becomes either a filter document or a $match stage.

No. Every dialect's grammar ships in the page as JavaScript, so parsing and printing happen in your browser. Nothing is uploaded, there is no account, and it works with the network disconnected once the page has loaded.