Wirekite Validate

Validate every row. Source vs target.

Most migration tools tell you the load succeeded. Wirekite proves it — row by row, column by column, with type-aware comparison across cross-database edge cases.

After a migration completes, the question every operator asks is the same: did all the data actually make it? Most tools answer with a row count. A few add a hash comparison on sampled rows. Neither catches the subtle stuff — a timestamp precision loss, a numeric rounding, a NULL-vs-empty-string slip in the type mapping.

Wirekite Validate walks both source and target result sets in lockstep, sorted by primary key, and compares every column in every row. Discrepancies surface as missing, extra, or value mismatch — with the offending row sampled so you can see exactly what differs.

Wirekite Validate tab showing source vs target row counts for five tables (500,000 rows each), Missing/Extra/Differences all zero, all results OK
Source rows · Target rows · Missing · Extra · Differences · Result — per table, per migration.

How it works.

1

Window the table

Wirekite splits each table into windows (default ~100K rows). Sample percentage selects how many windows to validate. Small tables always validate fully — the slider can't skip them.

2

Stream both sides

For each window, Wirekite issues a sorted-by-PK query on the source and the target. The two cursors walk forward in lockstep. No staging, no full table copy — bounded memory regardless of table size.

3

Compare cell by cell

Each row is compared column-by-column with engine-aware logic. Up to 100 diffs per error type are sampled into the report so you can read them, but every row is counted.

Cross-database comparison is hard.
Wirekite knows the gotchas.

A "1.0" in Postgres and a "1" in Snowflake are the same number. Wirekite knows that. Naive comparison thinks they're a diff.

Numeric precision

1.0 vs 1, NUMBER(38) vs BIGNUMERIC, big.Float-backed.

Timestamps

MySQL 3 ms vs Postgres microseconds. Timezone offsets ± HH:MM. Fractional seconds normalization. 1-second tolerance for MySQL.

Dates & times

2024-01-01 vs 2024-01-01 00:00:00. Microsecond tolerance.

JSON

Semantic equality — key order, whitespace, and indentation don't matter.

NULL handling

Oracle's empty-string-as-NULL, opt-in EmptyEqualsNull flag, per-source null equivalence rules.

UUIDs & binary

Case-insensitive UUIDs. Trailing-zero padding for binary/hex between SQL Server and Google Spanner.

Geometric types

Postgres point / line / box with engine-side normalization.

Intervals, XML, money, booleans

Oracle YEAR-MONTH vs Postgres interval string. XML whitespace. Currency formatting. 0/1 vs false/true.

Why most products stop at row counts.

Validation is expensive. Walking both sides of a migration in lockstep means two full table scans, sorted by PK, with engine-aware comparison for every column type. Most migration tools punt — they verify the row count, maybe a checksum on a few sample rows, and call it done.

Wirekite ships full row-level validation as a first-class feature because we built the engines to make it fast. The same engine that moves data quickly also walks the validation cursors quickly.

A green "OK" on every table means every row matches. Not "the count matches" — every row.

Want to see it on your data?

We'll run a migration on a sample of your workload — and validate every row of the result during the demo.

Book a Demo