The 2026 Data Contracts Software Landscape: Open Source and Commercial

Your supplier changed a column type last Tuesday. You found out Thursday, from a dashboard, in front of your boss. There was a spec. Nobody ran it.

That’s the whole case for data contracts. A contract is a promise with tests attached. If the tests don’t run, you have a PDF.

This is the fourth post in our 2026 series on the tools. The first three covered open source data quality and observability, commercial data quality and observability, and open source data profiling. This one covers the tools that read, write, and enforce data contracts, with GitHub stats, pricing where anyone publishes it, and a hard filter on what counts.

A disclosure, since you’d ask: we make TestGen. It’s in both tables, scored on the same criteria as everyone else, and its ODCS support ships on November 12, 2026, after this post goes up. What we’d say in its favor, and where it falls short, is in its own section near the end.

Part 1: The 2026 data contract tools

Why now

The format war is over. The Open Data Contract Standard (ODCS), maintained by Bitol under the Linux Foundation AI & Data, shipped v3.1.0 in December 2025. The competing Data Contract Specification deprecated itself in favor of ODCS the same month. Bitol counts 114 adopting organizations, up from nine in 14 months. If a tool invents its own contract format in 2026, you can’t hand that contract to anyone who doesn’t use the tool. That’s a problem, since the supplier who sends you garbage every Friday is the person you most need to hand it to.

How we judged the tools

We started with roughly 30 tools, most of them from Bitol’s own vendor list, and applied two filters. First, can you put an ODCS file in, edit it, and get a faithful ODCS file back? Second, does the tool run tests against your data and fail when a term is broken? A tool that fails either test is a catalog or a text editor, whatever it calls itself.

For the survivors we scored five things. Does the ODCS round trip lose fields? Do tests run on real data? Can you point it at an existing table and get back a complete ODCS contract, schema plus a runnable test suite covering types, nulls, ranges, patterns, uniqueness, freshness, and volume, with no hand-written YAML? Can someone without a terminal use it? And does it have an MCP server, so an agent can read and act on the contract? For open source tools we also pulled GitHub stars, forks, license, release cadence, last commit, and how many humans actually commit, as of 26 October 2026.

Open source data contract tools

Five projects pass both filters. Two are built around ODCS with a company behind them, though ours adds ODCS support on November 12. Two treat contracts as one feature of a bigger platform. One is a single engineer in Singapore.

Below that line sit the solo projects: DataVow, ContractGate, odcs-java-sdk, FLUID Forge, datacontract-x, SemaPact, dc43. Each has one author and under 20 stars. Three of them haven’t had a commit since summer. We looked. You don’t need to.

Two things to notice in the table. Only one open source tool turns an existing table into a complete ODCS contract with tests and hands the file back intact: TestGen, once its ODCS support ships on November 12. OpenMetadata gets there but loses fields on export. DQX generates rules from a profile and from plain English, then stops, because it reads contracts and never writes them, and it only runs on Databricks under a non-OSI license. And the Entropy Data stack, the purest ODCS implementation on the list, has no profiler at all. It tests what you declare. It can’t tell you what you forgot to declare.

Commercial data contract tools

Four vendors pass both filters. Soda is here too, because you’ll ask, with the caveat that it fails the round-trip test. Three publish prices. Two want a sales call.

What didn’t make the cut

Most of the field fails on round-trip, not on enforcement. DataHub ingests ODCS one way and never exports it; a contract lands as a logical dataset, not a contract. Soda sits in the commercial table on strength of enforcement alone; its format is its own and Soda Core is no longer open source. Atlan uses its own YAML. Gable enforces schema agreements on application code at pull-request time, which is useful and a different product. Great Expectations never had a contract format and now lives under Fivetran. IBM, Databricks Ontos, Actian, Witboost, and DQC.ai are on Bitol’s list, but we couldn’t verify round-trip or enforcement from their public docs. Confluent Schema Registry and dbt model contracts enforce for real and speak no ODCS.

Part 2: Our data contract evaluation criteria

Building a data contract is hard. Keeping it updated is harder. Running it often enough that it actually tells you whether your data is right is the hardest of all. Most teams barely have time to test their data, let alone publish a contract to a standard and republish it every time a column changes. A contract nobody updates goes stale, a contract nobody runs proves nothing, and either one is worse than none: it looks like protection while the data drifts underneath it.

So the columns in both tables measure one thing, which is how much of that upkeep the tool does for you. Here’s why each column matters, and what separates a contract that protects you from one that decorates a wiki.

The round trip

If you can’t get your ODCS file back out, you don’t own your contracts. The tool does. OpenMetadata is honest about this: import a long ODCS file and you get a short contract back, with servers, pricing, support terms, and custom properties gone. Collibra keeps the file but only maps the fields it recognizes. DataHub keeps nothing. Ask any vendor one question: if I import this file, edit one threshold in your UI, and export, what’s different? If they can’t answer, the contract lives in their database, and so does your bargaining power with your supplier.

A UI the business can use

A contract is an agreement between a producer and a consumer. Half the time one of those people is a data steward or the person who owns the P&L for the report. Neither will open a YAML file. If the only way to read or change a contract is a text editor and a git commit, the business side will nod in the kickoff meeting and never look again. You want the contract on a screen where a steward can see every term, which ones passed last night, and which one failed, with the table, column, and the threshold it missed.

Tables to contract, with tests, automatically

A contract with four tests is a schema check. A real contract on a 40-column table needs something closer to 150 terms: types, nulls, ranges, patterns, uniqueness, referential checks, freshness, volume. Nobody writes 150 tests by hand. Nobody maintains them by hand either, which is why most contract programs quietly decay into a schema check within six months.

This is the part of the market that’s thin. Most ODCS tools generate tests from what you declared in the contract. That’s deterministic and useful, and it only covers what you already knew to write down. Your supplier’s file has four different spellings of null in the comment column. You didn’t declare that because you didn’t know. A profiler finds it. The tools that generate tests from profiling, from the declared schema, and from a sentence you type to an LLM are the ones that produce enough coverage to matter. In open source that’s TestGen and OpenMetadata, though OpenMetadata’s export is lossy. In commercial it’s Collibra across two SKUs, Collate with the same lossy export, and TestGen Enterprise.

Profiling plus automatic test generation

You need both, connected. Profiling is how the tool learns what normal looks like before you ask it to defend normal. Profiling and semantic metadata give you the context. Test generation turns that context into coverage, and an MCP server wired to the same profiling context is how an LLM adds the tests a rule engine can’t think of. A profiler that writes a report gives you context and zero tests. A generator with no profile can only restate the schema you declared.

OpenMetadata and Collate pair a profiler with test proposals. Collibra pairs ML-generated rules with its catalog. DQX profiles and generates rules on Databricks. TestGen profiles every column and generates the suite from the result.

Entropy Data, the most faithful ODCS implementation on the list, doesn’t profile. It will enforce every term you write. It won’t tell you what to write.

MCP, because the next consumer is an agent

In 2026 the thing reading your data is increasingly a model, and a model doesn’t notice when a column changes meaning. An MCP server on your contract tool lets an agent check a contract before it queries, create a term when it finds a gap, and read last night’s results. Every catalog now ships one. The differences are whether the agent can write as well as read (Collibra and Soda can, most catalogs can’t), and whether it can run a governed query through the contract (Entropy Data can).

Where data contracts earn their keep

Four places. Put the first contract wherever it hurts most.

Figure 1: One contract, four gates. The same ODCS file and the same tests run at each one.

At the supplier: before the file leaves their building

You receive a file from a vendor every week. Some weeks it has an extra column. Some weeks it’s 40% shorter and nobody mentions it. Write the contract for that file and send it to the supplier along with a free tool that runs it. They run it before they ship. If it fails, they fix the data, not you, and you never see the broken file. This is why the tool has to be open source with no seat count: you can’t ask a supplier to buy a license to prove their own file is right. Our consulting team deals with suppliers who send garbage on a schedule. A contract they can run themselves is the most useful thing we’ve handed them.

On ingest: the moment it lands

Not every supplier will run your contract. Some won’t answer the email. So the same contract runs again on your side, the moment the file lands and before anything downstream touches it. Today you find out about a bad file when the load fails, or worse, when it doesn’t and the numbers are quietly wrong. With the contract at ingest, the file fails in a quarantine table, the supplier gets the failing terms with the table, the column, and the threshold, and your pipeline never sees it. Same contract, same tests, second line of defense.

On delivery: prove what you shipped

You build the gold table, the extract, the feed to the downstream team. Attach the contract. Run it before the export goes out. If it fails, the export doesn’t ship, and the first person to know is you, not the analyst who built the board deck on it. The contract is also your receipt. When the business asks what the data team did this quarter, a list of passing terms on every dataset you delivered is an answer. A Jira velocity chart is not.

In CI/CD: break the build, not the dashboard

Every pipeline change runs the contracts for the tables it touches, in a test environment, before merge. A changed column type fails the build. A dropped constraint fails the build. The engineer sees the failure in the pull request, where it costs five minutes, instead of in production, where it costs a Monday. This is the oldest idea in software engineering and the newest one in data engineering. The contract is the test suite you never wrote because you were busy.

Test coverage drives data contract coverage

A data contract covers exactly as much as its tests do. A contract on a table with no tests is a promise nobody checks, and a contract that tests three of 40 columns tells you nothing about the other 37. The question is whether every table you receive and ship has tests on it, so that when data arrives, it’s right. Our guide to test coverage makes the case for testing every table and every column, at every layer. In practice that’s three tests per table (freshness, volume, and schema) and an average of two per column. Ten tables with 20 columns each comes to 430 tests, before a single multi-table check. At 10 minutes a test, that’s 72 hours of writing, and every schema change means revisiting them.

Run your own numbers:

That arithmetic is why contract coverage stalls when people write the tests by hand. Manual tests don’t cut it. You’ll write 10, feel good, and discover the eleventh failure mode in production. It’s also why the tools in this post that generate tests matter more than the ones that only store the YAML.

The business value of data contracts

A data contract converts an argument into a test result. Before the contract, a bad file costs you two meetings and a week of blame with no evidence either way. After, it costs a failed check with the table, the column, and the threshold, timestamped, which the supplier fixes before you ever see it. Multiply that by every feed you ingest and every dataset you ship. The 1:10:100 rule puts a price on where you catch it: preventing a defect at the source costs 1, fixing it after it’s created costs 10, and letting it reach a customer costs 100. A contract at the supplier is the 1. A dashboard in front of your boss is the 100. The budget conversation changes too. You stop asking for money to fix data quality and start showing the receipt for the quality you already deliver. And the AI you’re putting into production gets the one thing it can’t do for itself: a checkpoint that catches a shifted column before a model reasons over it.

Start with one contract. Pick the export you’re most nervous about or the supplier who sends you the most garbage. Write it, run it for a month, and show someone the results.

Where TestGen fits

This is the section where we sell, so read it that way.

TestGen is built around the combination this post argues for. It profiles 55 characteristics per column and runs 32 hygiene detectors on the result. Point it at a few database tables, and in 60 seconds you have a working data contract with 80% of the data tests you need. Add your favorite LLM and the open source TestGen MCP server, which exposes the whole loop, profiling included, through more than 100 tools, plus the metadata TestGen already holds. Review what it proposes, and you’re at 90%. Total time: five minutes. The last 10% are unique to your business. Your business users create or configure those right in the TestGen UI, with no SQL and no ticket to the data team. That’s 100% contract test coverage. It’s Apache 2.0 with no seat count, so you can hand it to a supplier.

Where it falls short. ODCS import and export ship on November 12, 2026, so on the day this post goes up you’re taking our word for the round trip. The community is small: 223 GitHub stars against 1,101 for the Data Contract CLI and 15,586 for OpenMetadata. And if your contracts are already written and you only need to enforce them in CI, the Data Contract CLI is the most faithful free option on the list.

Install the open source TestGen. It takes about 10 minutes. TestGen Enterprise adds multi-user roles on the same engine.

Read more

We wrote about why contracts are receipts, not documentation, in The Data Contract Is Your Receipt, and the Data Contracts solution page has the FAQ and the one-contract starting plan. We’re running a webinar on data contracts on November 17, 2026, at 12 pm ET, which will show the ODCS round trip in TestGen live.

FAQ