Your code, correct and fast.
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.
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.
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
Built into every test, not bolted on
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
Timing across every object type
Tables
Time to read and return all rows from source vs. target. Identifies tables where data retrieval performance differs significantly.
Views
Query execution time on source vs. target. Reveals views where the target engine's query plan diverges from the source.
Procedures
Full execution time including all side effects. Captures the total cost of procedure execution, not just the return value.
Functions
Execution time for return value computation. Flags functions where the translated implementation takes measurably longer.
The payoff
Find the slowdown before it finds production.
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
Know where to tune.
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
- Performance measurement is built into every correctness test, so timing evidence arrives without another test run or separate tool.
- Execution time is recorded for source and target and shown alongside the result, giving every comparison a useful baseline.
- Record counts stay beside timing data, so a fast result cannot disguise a missing row or an incorrect output.
- Performance regressions surface before go-live, while the team still has time to change an index, emulation, or query pattern.
- No separate performance configuration is required, because the measurements travel with the correctness tests your team already runs.
Validate correctness and performance in one pass
Every test you run already includes performance data. No extra steps. No extra tools.