> ## Documentation Index > Fetch the complete documentation index at: https://docs.synq.io/llms.txt > Use this file to discover all available pages before exploring further. # Reconciliation overview > Prove that two datasets agree — across databases, across clouds, without moving the data Reconciliation answers one question: **do these two datasets actually agree?** You point Coalesce Quality at a dataset in a source database and a dataset in a target database. It compares them, tells you whether they match, and — when they don't — narrows the difference down to the specific rows or groups involved. **Only counts and checksums leave the database.** By default a reconciliation retrieves row counts and aggregate checksums, never row values. Both sides can be in different databases, different clouds, or different accounts, and nothing is copied between them. Revealing more than that is opt-in, per reconciliation — see [privacy levels](/reconciliation/how-comparison-works#privacy-levels). ## When you need it Monitors and tests tell you whether one dataset looks healthy. Reconciliation tells you whether two datasets tell the same story. Reach for it when correctness depends on a copy staying faithful to its origin: You are moving from one warehouse to another and need evidence — not a spot check — that the new platform returns the same data before you cut over. A change-data-capture stream or read replica quietly falls behind, drops rows, or applies an update twice. Nothing in either system is "broken", so nothing alerts. A transformation is supposed to preserve totals. Comparing the summary table against the operational source catches the day it stopped. Finance reads the warehouse, the application writes Postgres. A reconciliation makes "the numbers don't match" a measurable, scheduled check instead of an argument. ## How a comparison runs Every reconciliation runs in up to two stages, and the second one only happens if the first finds something. A single aggregate query per database returns the row count and a checksum over the compared columns. It is fast and cheap no matter how large the tables are, and for the common case — the data agrees — this is the whole run. If the totals disagree, the drill-down splits the key range into segments and re-compares each one, recursing only into the segments that differ. Finding a handful of bad rows in a large, mostly-identical table takes a logarithmic number of queries rather than a full row-by-row diff. The result is a set of key ranges (or, in aggregate mode, groups) where the two sides disagree, each with ready-to-run SQL that returns the offending rows. The algorithm is described in full on [How comparison works](/reconciliation/how-comparison-works). ## Three stages, one suite A **suite** is a YAML file holding one or more reconciliations plus the connections they use. The same suite moves through three stages, and the file never has to change to do it. ```mermaid theme={null} flowchart LR A[Local — author and run on your machine] B[Development — stored and versioned in your workspace] C[Production — a scheduled deployment] A -- upload-config --> B B -- promote --> C C -- edit, then re-promote --> B ``` | Stage | What it is for | Where it is driven from | | --------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | **Local** | Authoring and iterating. Fast feedback, no workspace state, nothing to clean up. | [The CLI](/reconciliation/running-locally) | | **Development** | A stored, versioned suite anyone on the team can run on demand, without local database access. The shared draft. | [CLI or UI](/reconciliation/workspace-suites) | | **Production** | A scheduled or API-triggered deployment whose results feed the rest of the platform. | [CLI or UI](/reconciliation/workspace-suites#promote-to-production) | You can stop at any stage. A suite that only ever runs locally, reporting nothing to the cloud, is a supported way to use the tool — see [standalone runs](/reconciliation/running-locally#standalone-and-air-gapped-runs). ## Where results show up Once a suite is promoted, each reconciliation in it becomes a first-class part of your workspace rather than a line of terminal output: * **Assets** — every reconciliation in a deployment appears as an asset, so it shows up in search, lineage and folders alongside your tables and models. * **Checks** — each run produces a check result, which means reconciliations participate in [check categorisation](/analytics/check-categories) and health reporting like any other check. * **Issues and incidents** — a failing reconciliation opens an [issue](/incidents/incident-overview), with the mismatch detail attached. * **Alerts** — issues route through your existing [alert channels](/alerts/alert-overview) and [ownership](/ownership/ownership-overview) rules. There is no separate notification setup. * **Annotations** — labels you put on a suite or reconciliation follow it into the platform and annotate the resulting assets and checks. In the app, reconciliations live under **Health → Reconciliations**, split into **Development** and **Production**. ## Where to go next Install, authenticate, and locate a real difference in a sample dataset. Suite, reconciliation, connection, deployment, run — the words used everywhere else. The YAML anatomy, choosing key columns, and the validation loop. The operating guide for a coding agent driving the CLI.