Reconciliation Consumption¶
Paridity is a consumption reporter. It records what your systems consumed while running Paridity's own comparison statements, in each provider's own units, and shows that consumption per run, per mapping, per system and per period. It never converts consumption to money: there is no currency, no rate, no cost estimate and no cost budget anywhere in the product. If you need a monetary figure, multiply the reported units by your own contract rate — the numbers here are the ones your provider meters, so that multiplication is yours to make and to check.
Governing design: docs/specs/plan_reconciliation_consumption_v1.md.
The units¶
| Unit | Provider | What it is |
|---|---|---|
| bytes scanned | any engine that reports it | Bytes the engine read for Paridity's statements |
| TiB billed | BigQuery on-demand | The billed-bytes figure BigQuery records per job, in binary TiB (2^40 bytes) |
| slot-hours | BigQuery reserved capacity | Slot time BigQuery records per job |
| credits | Snowflake | Provider-reported execution time × the warehouse size's documented credits per hour |
| DBUs | Databricks | Allocated from provider-reported execution time × the SQL warehouse's DBUs per hour; warehouse startup and idle time are not included. Rates are verified for Azure, and for AWS serverless 2X-Small; any other combination shows Not estimated |
| bytes transferred | worker-side | Bytes Paridity pulled out of a system during fallback comparison, key extraction or field diff |
Units are never added together. A page or card that lists several units lists each one on its own; there is no combined total, because a credit and a DBU and a byte are not the same thing.
What is recorded for a run¶
A run's ledger is in Evidence > Process steps, in the Resources used section at the bottom of the run's process-step timeline. It is collapsed until you open it, and nothing is fetched until then.
The section is grouped by side, then by phase. Each side's header names the system; a side whose engine has no provider meter (for example Trino, PostgreSQL or Redshift, which report bytes but no credits, DBUs or billed TiB) is labelled usage only, no provider meter. Under each phase (proof, field diff, in-flight recheck) the section lists the amounts in the provider's own units with the basis of each figure, and a query IDs disclosure that opens to the provider query or job IDs, in monospace with a copy button, so any figure can be checked against the provider's own query history. It also shows:
- for a side with a credit or DBU amount, the compute arithmetic: the provider-reported execution time multiplied by the warehouse size's documented units per hour, so the figure can be checked by hand;
- for a BigQuery side, billed bytes, slot time and whether the job ran on-demand or on reserved capacity;
- Typical for this mapping: per unit, this run's figure beside the median (p50) and 95th percentile (p95) of comparable runs.
An amount the provider did not report is shown as unmeasured. It is never converted to zero. A measured zero remains zero, for example when a query result cache reports no scanned bytes. A metered side whose unit could not be calculated for this run lists the unit as unmeasured with the reason recorded.
The run detail page carries no consumption card. Bytes and rows are on its Data volume card; below it, a single Resources used line appears only when a provider-metered unit (credits, DBUs, billed TiB or slot-hours) has a value for the run, and links to the Evidence section with the run preselected. A run on engines without a provider meter shows no such line. The full ledger for the run, including bytes, is in the Evidence section.
Measurement support depends on the connector, query path, provider metadata and the permissions available to the connection. Read the section as the record of what was available for that run rather than as a promise of uniform measurement coverage. A phase whose provider telemetry was incomplete is reported as unmeasured for that unit rather than as a partial number.
The consumption record for a run is written once when the run reaches a terminal state and is append-only evidence. It is never recomputed.
Metered vs usage¶
Every unit above is one of two kinds, decided by what the engine declares it can report, never by a list kept in the page:
- Metered - the engine reports a unit the provider itself bills or allocates: credits (Snowflake), DBUs (Databricks), TiB billed or slot-hours (BigQuery).
- Usage only - the engine reports volume but no provider meter: bytes scanned, and bytes transferred by Paridity's own workers. Trino, PostgreSQL and Redshift are of this kind.
Self-hosted engines (for example PostgreSQL, MySQL, Oracle, SQL Server and DB2 LUW) have no provider meter at all, because there is no provider billing the statements. Their systems are labelled no provider meter and report usage only where the engine exposes it. A usage figure is real evidence of volume, but it is not a provider-billed amount and is never converted into one.
Reading the Reconciliation Consumption page¶
/administration/cost-usage is available to platform and tenant admins. It
summarises compared runs - runs that actually compared data; runs that found
no new data are excluded - for a chosen period:
| Period | Window |
|---|---|
| Month to date | The calendar month so far |
| Last 30 days | Rolling 30 days ending now |
| Last 90 days | Rolling 90 days ending now |
The page is system-first: one card per system, in that system's own units. By default only metered systems are listed. Turn on Show systems without a provider meter to add the usage-only systems, each labelled no provider meter. Nothing on the page is added across systems or across units, and there is no tenant-wide figure.
Each card shows:
- one block per unit the system reports, with the period total and its coverage: how many compared runs recorded that unit and how many did not;
- a trend per unit - one point per day (month to date, 30 days) or per ISO week (90 days). A bucket with no compared run, or with runs that did not record the unit, is a gap in the line, never a zero;
- Top mappings on that system, ranked in the card's primary unit, with proof-only and full-window runs split out, and See the full ranking to page through every mapping;
- a link to Recommendations, where the Cost advisor view lives.
In the mapping rows, not reported means the engine has no such unit at all; unmeasured means the engine could have reported it and this run did not. Neither is ever shown as zero. A row where some runs recorded the unit and some did not is marked partial.
The coverage line states how many compared runs recorded any consumption at all and names the engines that report none, so an estate whose engines report nothing is never read as consuming nothing.
The pre-run estimate¶
Before a single run, Paridity can show an estimate for that mapping. It uses comparable compared runs from recent history, matching full or automatic window mode and proof-only mode. For each unit it reports the median (p50) and the 95th percentile (p95) of those runs' consumption, with the number of comparable runs and how many of them were unmeasured for that unit. Duration, row and byte estimates use medians of the same history.
A unit with no measured history reads not measured. Paridity does not invent a figure. The estimate is for one run; the Schedules page multiplies the per-unit median by the schedule's runs per day to show a daily figure per unit, and the bulk-run dialog sums the per-unit medians across the selected mappings — each unit on its own, never across units.
The consumption advisor¶
The AI consumption advisor proposes changes (a lower cadence, proof-only mode,
a narrower window) and states each proposal's monthly saving as a vector of
units — for example ~3.6 credits, 360.0 GiB scanned/mo. Materiality is
judged per unit against that unit's own monthly consumption. A saving is
never expressed in a currency.
What Paridity does not do¶
- It does not price consumption, store a rate, or accept a currency.
- It does not enforce or warn on a cost budget.
- It does not reproduce or reconcile a provider invoice. Consumption excludes startup and resume time, idle time, auto-suspend minimums, committed-capacity adjustments, account allowances, licensing and the effect of other workloads sharing the same warehouse or instance.
- It does not project a period total or offer what-if modelling. Use the recorded history for external planning if you need those analyses.