Overview
During the Discovery phase of the conversion pipeline, 3XCode runs a static, regex-only pass over your SQL text to identify which specific database platform it came from: Databricks, Snowflake, PostgreSQL, MySQL, SQL Server, Oracle, Redshift, BigQuery, Teradata, or Hive. This is a separate, deterministic layer that runs alongside dialect classification and never involves a model call.
The detector scores every candidate platform against a bank of syntax markers found in the file and returns the winning platform along with a confidence label and the exact markers that fired. Nothing about the result is a black box: you can see precisely why the tool decided your file came from, say, Teradata rather than generic ANSI SQL.
Dialect vs. Platform
The pipeline classifies source SQL at two different levels of specificity. It's easy to conflate them, so it's worth being precise about what each one is for.
Dialect: the syntax family
An LLM classifies the file into one of seven SQL dialect families during Discovery: tsql, plsql, plpgsql, mysql, ansi, spark_sql, or unknown. This determines which parsing rules and gotchas apply. ansi is a catch-all family, covering generic ANSI SQL syntax shared by Snowflake, BigQuery, and Teradata that isn't distinct enough to have its own dialect.
Platform: the specific vendor
Platform detection runs one layer deeper: given a dialect family like ansi or spark_sql that could plausibly be several vendors, the regex-based detector figures out which one it actually is, e.g. distinguishing genuine Databricks SQL from plain Hive within the spark_sql family, or Snowflake from BigQuery within ansi.
In short: dialect answers "which parsing rules apply?" and platform answers "which vendor actually wrote this file?" Platform detection is strictly more specific, and it's the piece that's fully deterministic: no LLM call, no variance between runs on the same input.
Supported Platforms
The detector scores every SQL file against syntax markers for these 10 platforms and returns the highest-scoring match:
| Platform | Typical Dialect Family |
|---|---|
 Databricks | spark_sql |
 Snowflake | ansi |
 PostgreSQL | plpgsql |
 MySQL | mysql |
 SQL Server | tsql |
 Oracle | plsql |
 Redshift | plpgsql |
 BigQuery | ansi |
 Teradata | ansi |
 Hive | spark_sql |
How It Works
Dialect classified
The Discovery LLM call classifies the file into a dialect family (tsql, plsql, plpgsql, mysql, ansi, spark_sql, unknown) as part of building the object inventory.
Markers scanned
A separate, static regex pass scores the raw SQL text against syntax markers for all 10 platforms: no model call, pure pattern matching.
Best match wins
The highest-scoring platform is selected, along with a confidence label reflecting how many distinct markers fired.
Evidence attached
The winning platform, its confidence, and the exact markers that fired are attached to the result, fully explainable and never a black box.
Platform detection is wrapped defensively: if the scan itself hits an unexpected error, it's swallowed and detection is simply skipped for that file rather than failing the whole Discovery phase. A file that can't be fingerprinted still proceeds through the rest of the pipeline normally.
Why It Matters
Zero LLM cost
Platform detection is pure regex scoring: it adds no tokens, no latency from a model round-trip, and no variance between identical runs on the same file.
Fully explainable
Every detection result carries the exact markers that fired, so you can see precisely why a file was classified as, e.g., Redshift instead of generic PostgreSQL.
Sharper knowledge targeting
Knowing the specific vendor, not just the dialect family, helps the pipeline reason about vendor-specific quirks that a broader dialect classification alone wouldn't surface.
Never blocks the pipeline
Detection failures are swallowed silently and simply skipped: a file that can't be fingerprinted still converts normally through Discovery, Planning, Conversion, Validation, and Auto-Fix.
In the Output
Every generated PySpark module gets a one-line header comment naming the detected source platform, its confidence, and the markers that matched, a best-effort annotation that never blocks the pipeline if the write fails. Run analysis-only on a file to see discovery output, including dialect and platform, before committing to a full conversion:
# Analyze a file (Discovery + Planning only, no conversion) 3xcode pyspark analyze legacy_report.sql # Full conversion: the resulting .py file's header comment # will note the detected platform, confidence, and markers 3xcode pyspark convert legacy_report.sql
Because detection is deterministic, running the same file through analyze or convert repeatedly always produces the same platform result. There's no model variance to account for when you're debugging why a file was matched to a particular vendor.