Skip to main content
As you type, the editor works out which SQL dialect the query reads as and shows a badge for each engine - DuckDB, Bloom, Spark, and Polars - stacked in the bottom-right corner, ranked most-viable-first:
  • Green - the engine runs the query exactly as written.
  • Amber - the engine needs a rewrite. Click the badge to preview it; nothing is applied until you click Replace editor contents.
  • Red - the query cannot be expressed on that engine.
Hovering a badge shows the match score - how much of the query survives unchanged, which separates a one-function rename from a full restructuring. This is a syntax check, not a routing decision: it tells you whether the SQL reads as a given engine’s dialect, not whether that engine has the tables or functions the query needs. Query routing still decides what actually runs. The same analysis is available to agents over MCP as query_dialect_analyze. Set transpile_to to get a rewrite back in transpiled.sql; show it to the user before running rather than substituting it silently.

​
Dialect as a tiebreaker

When DuckDB and Bloom are both otherwise viable for an auto-routed query, the detected dialect is the last tiebreaker: an unambiguous query written in DuckDB’s dialect (EXCLUDE, time-travel AT (...), and similar) stays on DuckDB rather than being routed to Bloom, which would need it rewritten. This never overrides the routing rules - a query that needs Spark or is capped to DuckDB by an external connection or a foreign catalog is decided before dialect is ever considered. It only breaks a tie between engines that are already both able to run the query.