Examples
The examples below are illustrative of the evidence DBReplay produces. Exact figures depend on the workload and the engine pair in question; the substance — what gets reported, and how — is the same in every engagement.
The coverage report, before anything replays
The first artefact a customer sees is a coverage report from their own captured workload, generated by pre-process before any replay has run:
| Classification | By template | By execution volume |
|---|---|---|
| Unmodified | 71% | 88% |
| Translated, semantics-preserving | 21% | 10% |
| Translated, semantics-uncertain | 4% | 1% |
| Untranslatable / unparseable | 4% | <1% |
Reporting both ways matters: 96% of templates translating cleanly reads well until you notice the remaining 4% might be the statements that run the most. Publishing both numbers is what keeps the coverage figure honest.
The cross-tab that matters
Every comparison report centres on one table: translation applied, against results matched.
| Results matched | Results mismatched | |
|---|---|---|
| Unmodified | The baseline — most of the workload should land here. | The genuinely interesting finding: an engine semantics difference, not a translation bug. |
| Translated | Evidence the translation rule is sound. | Highest priority to investigate — suspect the rule first. |
A single merged “mismatch” list hides which of these four cells a given finding belongs to — and each one has a different owner and a different next action.
A fit-for-replay verdict
Before a full replay-and-compare run, DBReplay reports whether the captured workload is technically sound to run at all: zero drops and desync, every eBPF-instrumented process reconciled against the expected inventory, no unhandled SQL, no stored procedure created or altered and then called mid-capture, and a stated discard rate with the surviving session count. It also reports what it can measure but not judge — auth ID diversity, read/write split, TPS profile — so the customer can decide whether the captured window is representative of the workload that matters.
Ranking a performance regression correctly
Two statements come back slower on the target. One runs twice, ten times slower. The other runs eight million times, twenty percent slower. Ranked by ratio, the first looks worse. Ranked by total time added — the number that actually predicts production impact — the second is the migration blocker and the first is noise. DBReplay reports ranked by total-time delta for exactly this reason.
Diagnosing drift instead of chasing it
A target that's slightly slower under sustained load doesn't announce itself as one dramatic failure — it shows up as cumulative schedule lag climbing and never recovering, from some specific point in the run onward. DBReplay reports the changepoint — the first statement where lag crosses a threshold and stays there — so the investigation starts at the onset and works forward, rather than working backward from a failed endpoint check across an entire run.