Pour checks that a copy of your data matches its source, row by row and value by value, and names exactly what doesn't.

Your data stays on your own infrastructure by default (see below for what an opt-in --submit sends). Point it at a source and a target, whether that is an old database and a new one after a migration, a source table and the copy a job produced, a file and its converted version, or this run's output and a known-good version you pinned, and it tells you if they are the same table.

It compares the data itself, so the same table in CSV, Parquet or a database still matches.

Two ways teams use it

A migration you sign off on. A pipeline you stop trusting blindly.

Where your data goes

Nowhere, by default. The check runs on your own runner.

Pour reads your files and your database rows where they already are, inside your own pipeline, and prints an ID. No rows, no cell values and no column names are sent to us or to anyone else unless you pass --submit, which matters when the table holds patient, payment or customer records. A content ID cannot be reversed into the data, though like any hash it can confirm a guess about a very small, predictable table, so treat it as a fingerprint rather than as encryption.

With --submit, the CLI additionally sends the content IDs, the file basenames, the profile name, and CI metadata: repository, commit, ref and run ID, read from whichever CI system detected the run (GitHub Actions, GitLab CI, Jenkins, Azure DevOps, Bitbucket Pipelines, CircleCI or Buildkite). It never sends rows, cell values, column names or directory paths, and never the local diff file, which is the one place cell values are written. The server rejects any other field, so this holds even if the client were changed.

What it will not do

When it cannot be sure, it fails. It never guesses.

Nested values, such as a list or a struct inside a cell, are supported and compared exactly, including any decimals or timestamps inside them; struct members and map entries have no order of their own, so only the order of a list itself is kept.

Works with any CI

A GitHub Action, built and not yet published. A command line everywhere else.

A GitHub Action wraps the check for GitHub Actions specifically; it is built and tested, and will be available on the Marketplace once Pour ships (see Where it stands, below). Anywhere else, and today, run the same command-line tool as a regular shell step and let its exit code fail the job: it needs only a shell and Node 22, so it runs anywhere those are available. CI-provider metadata is detected for seven systems: GitHub Actions, GitLab CI, Jenkins, Azure DevOps, Bitbucket Pipelines, CircleCI and Buildkite. Only GitHub Actions is exercised in our own CI.

Once signed receipts (below) are live, a pour run --submit receipt will record that provider alongside the repository, commit, ref and run ID. A single verify --submit receipt, which is what the Action produces, does not carry it.

A record of the check your own team could not have written afterwards.

Auditors already test whether the data a company relies on is complete and accurate. The usual evidence is row counts, totals and screenshots, produced by the same team being audited, often well after the fact. A signed receipt adds the two things a team's own log cannot prove on its own: when the check ran, by a clock the team does not control, and that the record has not been edited since.

Each receipt is signed with both Ed25519 and ML-DSA-65 and can be checked later, entirely offline, against our published public keys. A receipt proves what was recorded and when. It does not prove the data was right, only that these tables had these IDs at that time. If our service is unreachable, --submit prints a warning and your build's own result stands; a missing receipt never fails a build.

The hosted dashboard is the same idea made visible: a history of the receipts your team has submitted, and watches you can set on a table so a pinned or previously-seen content ID that changes unexpectedly emails or messages someone, instead of waiting for a person to read a build log.