SQL Dialect Migration Data: Stored Procedure and Query Conversion Pairs for AI

Why dialect pairs from real migrations beat synthetic or benchmark SQL

Real migration pairs are valuable because the hard parts of dialect conversion live in procedural extensions, date and null semantics, and vendor functions that benchmarks rarely exercise. Many public SQL datasets are built on SQLite, which has no stored procedures and a loose type system. Synthetic pipelines handle this by generating and validating records per dialect, as NVIDIA's NeMo Data Designer does with separate MySQL, PostgreSQL and SQLite validators [2]. Synthetic data still cannot reproduce the 3,000-line package body that someone at a bank had to rewrite.

Enterprise SQL is long, multi-statement and bound to large schemas. Spider 2.0 was built on that observation, running its 632 tasks against real databases with large schemas and several dialects [1]. Public procedural translation benchmarks remain relatively small and specialized, and anything public is exposed to contamination, so a private held-out set from real migrations is worth more for evaluation than for volume.

This page covers SQL-to-SQL conversion. If you need natural-language-to-SQL pairs, see text-to-SQL training data from real enterprise schemas in the structured cluster; for single-dialect query logs and procedure libraries, see production SQL query corpora. For COBOL, RPG or other application-language conversion, see legacy code translation pairs.

Which dialect pairs and constructs decide difficulty

Specify every source and target dialect pair explicitly, because difficulty varies more by construct than by line count. A request for "SQL migration data" will return mostly trivial SELECT rewrites; a request naming Oracle 19c to PostgreSQL 16 with packages, autonomous transactions and CONNECT BY gets you the signal you want. The work spans syntax mapping, stored procedures, triggers and views, not single queries.

Constructs worth asking for by name:

• Oracle to PostgreSQL: packages and package state, %ROWTYPE, BULK COLLECT/FORALL, MERGE, DECODE/NVL, empty string equals NULL, DATE carrying a time component, sequences and ROWNUM, CONNECT BY to recursive CTEs.
• SQL Server T-SQL to Snowflake or PostgreSQL: TRY...CATCH, temp tables and table variables, @@ROWCOUNT, IDENTITY, OUTPUT clauses, DATETIME rounding, collation-dependent comparisons, cursor loops rewritten as set operations.
• Teradata or Netezza to BigQuery or Snowflake: QUALIFY, SET versus MULTISET tables, BTEQ control scripts, CASESPECIFIC columns, volatile tables, distribution and partition keys that disappear in the target.

Failure modes in these areas are silent: a converted procedure compiles and runs, but NULL handling or integer division changes a total. That is why the label matters more than the pair.

How to evaluate SQL conversion result equivalence

The equivalence label for a conversion pair is result reconciliation on representative data, not string similarity or successful compilation. Migration teams already produce this evidence. Open-source validators such as Google's Data Validation Tool, and warehouse vendors' own migration validators, compare source and target tables using row counts, column aggregates (count, sum, min, max, group by) and row-level hashes. Hash functions differ by engine, so ask how hashes were made comparable across dialects.

Ask suppliers three questions. Do reconciliation outputs exist per object, or only per release? Were they run on production-scale data or a dev snapshot? Can masked test data be shared so you can rerun the checks inside your own execution harness? The third matters if you plan RL with execution-equivalence rewards, because a reward needs a database state to execute against, not just a stored verdict.

Treat partial evidence honestly. A pair that matched on row counts but was never checksummed is weaker than one with column diffs at zero, and the metadata should say which level was reached.

What each conversion record should contain

A training-ready record links one source object to its final target, with the dependency context and the edit history in between. The most valuable signal is usually the hand correction: what engineers changed after AWS SCT, ora2pg, SQLines or a vendor converter produced its first pass. Keep the three versions (source, tool output, final) separate so you can train on corrections and evaluate against the final.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "pair_id": "mig-0412-proc-117",
  "object_type": "stored_procedure",
  "source_dialect": "oracle_19c_plsql",
  "target_dialect": "postgresql_16_plpgsql",
  "source_sql": "CREATE OR REPLACE PROCEDURE post_daily_accruals ...",
  "tool_output_sql": "CREATE OR REPLACE PROCEDURE post_daily_accruals ...",
  "converter": "tool_name_and_version",
  "final_sql": "CREATE OR REPLACE PROCEDURE post_daily_accruals ...",
  "hand_edit_diff": "unified diff tool_output -> final",
  "constructs": ["bulk_collect", "nvl", "date_with_time", "exception_block"],
  "ddl_refs": ["ddl/ledger_entries.sql", "ddl/accrual_rates.sql"],
  "reconciliation": {
    "method": "row_count+column_aggregates+row_hash",
    "dataset": "masked_snapshot_2025q4",
    "row_count_match": true,
    "column_diffs": 0,
    "row_hash_mismatches": 0
  },
  "literal_masking": "customer and account literals replaced with format-preserving tokens",
  "status": "in_production"
}

Ask for DDL with every procedure, including indexes, constraints and view definitions, since a conversion model that never sees column types cannot learn why NUMBER became NUMERIC(18,2) rather than BIGINT. Deduplicate before training: migration estates contain hundreds of near-identical generated procedures, and near-duplicates distort training and evaluation [3]. Document how pairs were selected and filtered, in the style of a data card, so evaluators know what the set omits [4].

Masking literals without breaking executability

Literal values embedded in SQL, such as customer IDs, names, account numbers and hard-coded email addresses, need masking that keeps queries executable and reconcilable. Replacing WHERE acct_no = '4410093321' with a random string can break joins, check constraints or LIKE patterns, so the masked literal must keep type, length and format, and the same token must be used in the masked test data.

SourceX removes or replaces personal details such as names, emails, phones and account numbers before delivery, records the method and checks a sample; no method is perfect. Run your own scan on comments and dynamic SQL strings, where identifiers and credentials hide. Secrets in connection strings and DBMS_SCHEDULER job definitions deserve the same treatment as in any code corpus; see secrets removal in code datasets.

Sample review checklist before licensing

Check a sample against these points before you agree terms. The code dataset sample evaluation guide covers general repository checks; these are specific to migration pairs.

Ownership matters because migration code is often written by systems integrators under contracts that may assign or retain rights; see code ownership due diligence. Retirement projects are a natural source, because a company decommissioning a warehouse holds both sides of the conversion; see data licensing for legacy software retirements.

How SourceX sources migration pairs

SourceX sources operational datasets from US companies on request, including engineering records such as proprietary codebases; nothing is held in stock, and a request does not guarantee a match. You describe the data, such as dialect pairs, constructs, reconciliation evidence and volume, and SourceX looks for US businesses that hold it. The process runs Find, Assess (data and licensing permissions), Agree (pricing and allowed uses in a license), Transact and Manage, and every release is approved by the supplying company. Start a request at the SourceX buyer page, or browse the wider code and software engineering data map and the AI data hub.

Request SQL dialect translation data

Every SourceX dataset is rights-reviewed for ownership and consents and delivered under a license that defines records, uses, term and delivery. Diligence materials covering source, rights, preparation and allowed use are prepared per dataset, and nothing is contracted until a supplier agrees. Describe the dialect pairs and evidence you need at https://sourcex.si/buyers.