A 600-million-row replay shows when self-sizing sketches beat Merkle reconciliation

A new database-reconciliation benchmark reports a result that disappears when the network is fast: on a 600-million-row production-shaped replay over a 10 Mbps link, a self-sizing Invertible Bloom Lookup Table (IBLT) completed in 657 seconds, versus 1,020 seconds for a tuned Merkle-style localization method. That is a 1.55× speedup. At 100 Mbps, however, the gap on the same workload was only 2.5%, within the paper’s reported run-to-run noise.

The distinction matters because this is not a claim that one algorithm universally wins. The August 27 paper evaluates three Oracle 11g-to-PolarDB/MySQL 8.0 replay profiles. Its P1 profile has 600 million rows and about 93,000 multiset differences; P2 has 30 million rows and about 1,400 differences; P3 has 150 million rows but only 18 differences. At 10 Mbps, self-sizing IBLT led P1 by 1.55× and P2 by 1.25×. On P3, where the 18 differences occupied a narrow key range, Merkle localization was about 12 seconds faster: 137.5 seconds versus 149.5 seconds.

The reason is transfer geometry, not SQL generation or model quality. The IBLT sizes its second sketch from a count statistic in the failed first sketch. On P1, its first-round payload was 16,400 bytes per side and its second sketch was about 5.2 MB. The tuned Merkle method divided the key space into 60,294 ranges, marked 677 dirty, and then reread those ranges. At 10 Mbps, that drill-down added about 389 seconds. When differences were deliberately scattered, the Merkle run reached 18,502 seconds at 10 Mbps and 22.5 ms latency; the IBLT runs rose only 2%–9% because their payload depended on how many differences existed, not where they appeared.

The production evidence needs careful labeling. The paper analyzes 41,603 NineData reconciliation records from April 29 through July 28, 2026. In those logs, nonzero difference cardinality ran from a median of 24 to a maximum of 44.1 million, while the most expensive 5% of runs accounted for 81% of cumulative table-level time. But NineData’s online jobs used the existing Merkle-style service; the self-sizing method was not run on those customer tasks. Its measured timings come from the production-shaped cross-engine replay and a separate China Mobile Redis/Pika deployment.

That field deployment used a roughly 10 Mbps, 28.8 ms cross-city link and about 4.89 million keys. Across six scenario groups, the implementation recovered the expected differences without false positives or false negatives in the fixed-ground-truth cases. A full scan took about 28.1 seconds, and scanning consumed 93.7%–99.1% of IBLT end-to-end time in the five G1–G2 tiers.

The practical benchmark lesson is narrower and more useful than a headline speedup: report bandwidth, latency, difference count and difference placement. Without all four, a reconciliation score hides the condition that decided the winner.