> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleander.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Transpilation

> Dialect detection, engine badges, and SQL rewrites across DuckDB, Bloom, Spark, and Polars.

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](/platform/query-routing/overview) still decides what actually runs.

The same analysis is available to agents over MCP as [`query_dialect_analyze`](/mcp/protocol#queries). 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](/platform/query-routing/overview) - 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.