Every correctness test in SQL Tran also measures execution time. Compare source and target timing, identify the meaningful gaps, and focus optimization on the objects that need it most.
The usual approach
A migration can be functionally perfect and still fail in production if the translated code runs significantly slower than the original. Performance regressions are one of the most common, and most dangerous, surprises after a database migration.
The SQL Tran approach
SQL Tran eliminates the surprise. Performance measurement is built into every test, not a separate step. Every time you validate correctness, you also get a clear picture of how execution time compares between source and target.
How it works
Performance testing in SQL Tran is not a separate mode or a different kind of test. It is an additional dimension of every correctness test. When SQL Tran runs a test against both databases, it records execution time for each side. The result UI displays match status, record counts, and timing data, all in one view.
By the time you have validated correctness across your database, you already have a complete performance profile for every tested object. No extra configuration, no extra test runs, no separate tooling.
What it measures
Time to read and return all rows from source vs. target. Identifies tables where data retrieval performance differs significantly.
Query execution time on source vs. target. Reveals views where the target engine's query plan diverges from the source.
Full execution time including all side effects. Captures the total cost of procedure execution, not just the return value.
Execution time for return value computation. Flags functions where the translated implementation takes measurably longer.
Package procedures and functions are measured too. SQL Tran compares their execution time, returned values, result sets, and observable table side effects between source and target.
The payoff
A translated query can return the right rows and still consume too much time or capacity. SQL Tran gives you the comparison while the code is still in review, when an index, an emulation, or a target-specific rewrite can still change the outcome.
You see the regression before go-live, with correctness and timing read together. That gives the team a concrete place to investigate instead of discovering the cost through production workload.
Interpreting results
Source and target execute against the same data, so a timing gap means something. SQL Tran puts both durations next to each other and shows whether the target is faster or slower, giving your team a clear place to focus optimization.
Need realistic volume? The synthetic data generator creates as much test data as you need while honoring your exact schema, constraints, and relationships. When production-shaped behavior matters more, test anonymized production data instead.
Timing comparison
Same input. Different runtime.
Customer query
Target faster
Order summary
Target slower
Green marks a faster target. Red points to an object worth optimizing before go-live.
Key benefits
Every test you run already includes performance data. No extra steps. No extra tools.