Datafold's data-diff Is Archived: 5 Alternatives in 2026

Datafold archived the open-source `data-diff` repository on GitHub in 2024, and it no longer receives maintenance. If your team depended on it for cross-database comparison or dbt change validation, you need a replacement. This guide assesses five honest alternatives — reladiff, dbt-audit-helper, SQLMesh table_diff, Recce, and Data Workers' Data Guardrail Agent — and which fits your stack.

The archival was not a surprise to people watching the project. Datafold's commercial focus shifted to its paid platform — its Migration Agent automates legacy-ETL-to-modern-stack migrations and uses diffing under the hood for validation — and the MIT-licensed open-source tool stopped being where the company invested. The repository remains readable on GitHub, and the last published package still installs, but archived means archived: no bug fixes, no new database adapters, no security patches, and no response to issues. For a tool whose whole job is talking to your production warehouses, that is not a posture most teams want to depend on indefinitely.

What made data-diff popular was a genuinely useful pair of capabilities: fast cross-database comparison (checksum-based hashing to verify that a table in PostgreSQL matches its replica in Snowflake) and in-database joindiff for validating dbt model changes. The alternatives below cover that ground from different angles, and the right pick depends on which half of the job you actually used.

1. reladiff — the maintained fork

reladiff is a fork of data-diff maintained by the original author of the data-diff engine. It is the most direct continuation of the archived project: it keeps the two core comparison modes — hashdiff for efficient cross-database comparison (segmenting tables and comparing checksums so you only pull mismatched rows over the network) and joindiff for comparing two tables that live inside the same database. If your use case is replication validation — "did this table land in the destination warehouse identical to the source?" — reladiff is the closest drop-in replacement, with familiar CLI ergonomics.

One thing to check before adopting it in a company setting: the license posture. The repository does not carry a standard OSI license string on GitHub the way data-diff carried MIT, so run it past whoever approves open-source dependencies at your organization before it lands in production tooling. That is not a knock on the project — it is simply due diligence that the archived predecessor did not require.

2. dbt-audit-helper — pure SQL, zero new infrastructure

dbt-audit-helper is an Apache-2.0 macro package from dbt Labs. It gives you compare_relations, compare_all_columns, and compare_row_counts macros that compile to plain SQL and run inside your warehouse — no Python service, no new binary, no network egress. If you are already a dbt shop, this is the lowest-friction option on this list: you add the package, write a small audit model or analysis, and diff a dev relation against its production counterpart in the same warehouse where both already live.

The trade-offs are the mirror image of the convenience. It is dbt-only — the macros assume dbt's adapter and relation abstractions — and it does not do cross-database comparison, so it cannot validate a Postgres-to-Snowflake replication the way hashdiff-style tools can. There is also no review workflow: the output is query results, and turning those into a PR comment or an approval gate is glue code you write yourself. For ad-hoc model validation inside one warehouse, though, it is hard to beat free macros that need nothing new installed.

3. SQLMesh table_diff — diffing built into the framework

SQLMesh (Apache-2.0) ships a table_diff command as a built-in, with join-key-level statistics on how two tables differ. The deeper point is architectural: SQLMesh's virtual data environments mean every change is materialized into an isolated environment by construction, so "compare my change against production" is a cheap, first-class operation rather than something you bolt on. If you are evaluating a migration off dbt anyway, the diffing story comes along for free.

The honest caveat: table_diff is a reason to use SQLMesh, not a reason to install SQLMesh. Adopting an entire transformation framework to get a diff command is the wrong order of operations. It belongs on this list because teams already migrating — or starting greenfield — should know the capability is built in rather than a separate purchase.

4. Recce — PR-native data review for dbt

Recce is an open-source (Apache-2.0) data-review toolkit built specifically for dbt pull requests. It bundles the diff types you actually want in review — row-count diffs, profile diffs, value diffs, top-k diffs, and histogram diffs — behind a review UI, so a reviewer can see what a model change did to the data rather than just what it did to the SQL. Of the open-source options here, it has the most developed review workflow: checks can be saved, shared, and attached to the PR conversation.

Recce also has a cloud tier that adds hosted PR integration; as of June 2026 there is a free tier with monthly review limits, with paid plans above it — check current pricing since packaging changes. Like dbt-audit-helper, it is dbt-centric: if your pipelines are not dbt, or you need to compare across different databases, it is not the tool for that job.

5. Data Workers' Data Guardrail Agent — agent-driven review, no dbt required

The Data Guardrail Agent from Data Workers approaches the same problem from the agent side. Instead of a CLI you run or a macro you call, it is an agent that reviews what a change does to your data on Snowflake, BigQuery, PostgreSQL, or Databricks, using plain SQL and INFORMATION_SCHEMA — no dbt project required, no proprietary metadata format. It runs progressive, cost-aware checks (cheap row-count and schema checks first, escalating to deeper comparison only when something looks off, so you are not paying warehouse compute for full diffs on every change) and ends with a risk verdict plus machine-actionable remediation handoffs rather than a wall of numbers a human has to interpret.

Because it speaks MCP, it runs where your workflow already is: inside Claude Code, inside Cursor, or as a CI step. The differentiator versus everything above is what happens after a finding — the verdict is structured so another agent or a CI gate can act on it, instead of a diff report waiting for a human to read it. See the product overview for how it fits into the broader Data Workers swarm.

Comparison Table

Which Should You Pick?

• •You used data-diff for replication validation across databases: reladiff is the closest drop-in — same hashdiff engine, maintained by the original author. Clear the license posture with your open-source review process first.
• •You are a dbt shop and want zero new infrastructure: dbt-audit-helper. Apache-2.0 macros, pure SQL, nothing to deploy. Accept that you will write your own CI glue.
• •You want data review as a PR workflow on dbt: Recce. It has the richest diff types and an actual review UI, with a cloud tier when you want hosted PR integration.
• •You are migrating to SQLMesh anyway: use the built-in table_diff and the virtual environments that make comparison cheap by construction. Do not adopt the framework just for the diff.
• •You are not on dbt, work across multiple warehouses, or want review that ends in an actionable verdict instead of a report: the Data Guardrail Agent — agent-driven, plain SQL + INFORMATION_SCHEMA, runs in Claude Code, Cursor, or CI.

The archival of data-diff is a reminder that open-source tools backed by a single vendor inherit that vendor's commercial priorities. The good news is that the replacement landscape in 2026 is stronger than the original: a maintained fork for the cross-database case, two solid dbt-native options, a framework with diffing built in, and an agent-driven approach that closes the loop from finding to fix. Pick by workflow, not by nostalgia — and check our resources for more guides on data-change review.