Only counts and checksums leave the database. By default, a reconciliation reads row counts and aggregate checksums, never row values. The two sides can be in different databases, different clouds or different accounts, and no data is copied between them. To read more than that, you must set it on each reconciliation. See privacy levels.
When you need it
Monitors and tests tell you if one dataset looks healthy. Reconciliation tells you if two datasets contain the same data. Use it when a copy must stay identical to its origin:Migrations and replatforming
You move from one warehouse to another. Before you cut over, you need evidence, not a spot check, that the new platform returns the same data.
Replica and CDC drift
A change-data-capture stream or a read replica falls behind, drops rows, or applies an update two times. Neither system is broken, so nothing alerts.
Pipeline correctness
A transformation must keep the totals. A comparison of the summary table with the operational source finds the day the totals stopped agreeing.
Source of truth vs warehouse
Finance reads the warehouse, and the application writes to Postgres. A reconciliation makes “the numbers do not match” a scheduled check with a measured result.
How a reconciliation runs
Every reconciliation runs in one or two stages. The second stage runs only if the first stage finds a difference.1
Quick check: one query per side
One aggregate query on each database returns the row count and a checksum over the compared columns. In aggregate mode, it returns grouped totals. It is fast and cheap for tables of any size. When the data agrees, which is the usual case, this is the full run.
2
Drill-down: split the key range
If the totals do not agree, the drill-down splits the key range into segments and compares each segment again. It continues only into the segments that differ. In a large table that is mostly identical, it finds a small number of bad rows with a logarithmic number of queries, not with a full row-by-row diff.
Three stages, one suite
A suite is a YAML file that holds one or more reconciliations and the connections they use. The same suite moves through three stages, and you do not have to change the file.
You can stop at any stage. A suite that only runs locally and reports nothing to Coalesce Quality is a supported way to use the tool. See standalone runs.
Where results show up
When you promote a suite, each reconciliation in it becomes part of your workspace:- Assets. Each reconciliation in a deployment is an asset. It shows in search, lineage and folders with your tables and models.
- Checks. Each run gives a check result. Thus reconciliations are part of check categorisation and health reporting, as other checks are.
- Issues and incidents. A failed reconciliation opens an issue with the mismatch details.
- Alerts. Issues go through your alert channels and ownership rules. You do not set up notifications separately.
- Annotations. Labels on a suite or a reconciliation go into the platform with it, and annotate the assets and checks that it makes.
Where to go next
Getting started
Install, sign in, and find a real difference in a sample dataset.
Concepts
Suite, reconciliation, connection, deployment, run: the words that all other pages use.
Authoring suites
The structure of the YAML, how to choose key columns, and how to validate a suite.
Agent workflow
The operating guide for a coding agent that uses the CLI.