TL;DR. OpenMetadata shipped 2.0.0 as a stable release on August 24, 2026, three days after the last 1.13 patch. The upgrade checklist is honest about what will fail: embedding config moves, Databricks auth restructures, ingestion images rebuild on Python 3.12. But the changes most likely to matter in six months are three defaults that produce no error at all. The profiler switches from full-table scans to dynamic sampling, cardinality distribution stops being collected, and the MCP server that exposes catalog metadata to AI agents starts enabled. Each one changes what your metadata means, or who can read it, without a single failed job to flag the change.
On August 24, 2026, OpenMetadata published 2.0.0-release, closing out a release-candidate window that ran since July 30. The timing is worth noticing: 1.13.4, the final patch on the old line, landed on August 21, three days earlier. The project effectively finished maintaining the old major and shipped the new one in the same week, and every team running the most widely deployed open-source metadata platform now has an upgrade on its backlog.
Major-version upgrades get read as configuration work. You diff the config schema, fix what errors, rerun what fails, and call the migration done when the dashboards are green. OpenMetadata 2.0 will reward that reading with a working deployment and quietly punish it afterward, because its most consequential changes are not in the category that errors. They are defaults, and defaults do not fail. They just start being true.
The loud breaking changes are the safe ones
The release notes list the changes that will stop you, and they are exactly as tedious as breaking changes should be. Semantic search embedding settings move out of their old block into a new LLM configuration structure, and the server wants an explicit flag before it will run them. Databricks pipeline connections stop accepting a bare token and want it wrapped in a structured auth object, which means externally stored ingestion YAMLs need editing by hand. Ingestion images jump from Python 3.10 to 3.12, so anything custom-built on top of them has to be rebuilt, and teams still on Great Expectations 0.x have to migrate to the 1.3 line before touching the upgrade at all.
None of this is dangerous, and that is the point. A config the server rejects, a YAML the connector refuses, a Docker build that dies on a missing wheel: these failures are self-announcing. Someone gets assigned, the fix is mechanical, and when the errors stop, that part of the migration is genuinely finished. The S/4HANA migration numbers make the same point at a larger scale: the visible cutover is rarely the part of a migration that ends up hurting.
That leaves the three changes the checklist has no line item for.
The 1.13 to 2.0 upgrade sorts into self-announcing failures and silent defaults.
A passing check no longer says what it used to
The headline of 2.0's data-quality revamp is that the profiler now defaults to dynamic sampling instead of scanning 100 percent of rows. The motivation is real and creditable: on large tables, full-scan profiling is a recurring query bill and a recurring load spike against production, and plenty of teams turned the profiler off entirely rather than pay it. Sampling is how you keep profiling alive at scale, and OpenMetadata is right that most consumers of a null ratio do not need it computed to the last row.
But a profile computed on a sample is a different claim than a profile computed on a full scan, and nothing in the UI changes shape to say so. Before the upgrade, a row count, a null ratio, a min and max came from every row. After it, on configurations that follow the default, they come from a dynamically chosen sample. A rare violation, a handful of nulls in a column that promises none, a single out-of-range value, can now sit in the unsampled remainder while the metric reads clean. The check is probabilistic where it used to be exhaustive, and the green state it feeds looks identical either way.
The release notes are careful here, and the care deserves passing on precisely: existing profiler configurations are preserved, and the new behavior applies to default agent configurations. The exposure sits elsewhere: every table where nobody made a choice, which in most deployments is most tables, plus everything onboarded after upgrade day. If a data contract, an alert, or a downstream consumer treats a profile metric as an exhaustive statement, that table has just become a place where you need to configure the old semantics explicitly rather than inherit them.
The second default is smaller and sneakier: cardinality distribution comes out of the default metric set, so distinct-value counts stop being collected automatically. Nothing deletes the old values. They stay where they are and stop updating, which is the worst of the available behaviors, because a consumer reading them sees plausible numbers, not gaps. We made this argument about propagated metadata going stale in the catalog layer generally: a value that silently stops being maintained is more dangerous than a missing one, because absence prompts a question and staleness answers it, wrongly. If anything downstream keys on distinct counts, joins estimation, dedupe heuristics, drift alerts, it has to be found before the upgrade, not discovered by it.
Your catalog starts answering agents on day one
The third default is a different kind entirely. The MCP server that exposes catalog metadata to AI assistants and agents, present since the 1.13 line, is now enabled by default: after the upgrade it starts ready, no activation step, with cursor-based paging added for its read tools. Any MCP-compatible client that can reach and authenticate to your deployment can query the catalog, traverse lineage, and search the estate without a line of custom integration.
For the project's positioning, this is coherent. OpenMetadata spent 2026 renaming itself from a data catalog to an agent-facing platform, and a platform whose primary consumer is supposed to be an agent should ship with the agent door open. Adoption follows defaults, and the maintainers know it.
For an operator, the calculus is less comfortable, because the wider MCP ecosystem's security record in 2026 is exactly the argument against defaults like this one. A large-scale measurement study published this month, Exposed by Design, found over 21,000 MCP server instances detectable on the public internet, and of the production servers it audited dynamically, 91.8 percent ran without OAuth. The protocol layer has had its own problems this summer; we covered what the specification's caching model permits in August. A metadata catalog is a peculiarly high-value thing to attach to that ecosystem by default: it is the map of your estate, schema names, ownership, lineage, quality signals, the exact reconnaissance a catalog exists to centralize. The Polaris credential-vending record showed what happens when catalog-adjacent surfaces get treated as infrastructure plumbing rather than as security boundaries.
None of this says disable it. An agent-readable catalog is the direction the category is going, and for good reasons. It says the decision about who can read your metadata graph, from where, with what authentication, is being made for you by an upgrade, on the same day, with no error to mark it. That decision deserves to be made by you, before the migration runs.
Decide the defaults before the upgrade decides them
The mechanical sequence is short. Patch to 1.13.4 first: the wheel cleanup that custom images otherwise need is already handled coming from there. Clear the loud list, embeddings config, Databricks YAMLs, image rebuilds, the Great Expectations migration, against a staging copy of your metadata store. Expect the Knowledge Center's content to come across automatically under the new Context Center, and expect its old URLs not to.
The judgment work is the three defaults, and it is small if done deliberately. List the tables where profile metrics carry contractual weight and pin full-scan configs on them, letting everything else sample. Search for consumers of cardinality metrics and either re-enable collection where they exist or retire them knowingly. Decide the MCP posture, authentication, network reachability, and which clients are expected, before upgrade day rather than in response to it. An afternoon of decisions, against the alternative of inheriting all three answers implicitly and finding out which ones were wrong from whatever breaks downstream, months later, with nothing in the logs pointing back to the upgrade.
One deprecation notice belongs on the same planning page: the maintainers state that Airflow as the internal orchestrator will be deprecated in 2.1 in favor of a Kubernetes Orchestrator. Externally managed Airflow is unaffected, but if your deployment leans on the bundled one, the clock on that migration has already started.
Where Datapace sits
The sampling default is a small instance of the problem Datapace exists for. A null ratio computed over every row and a null ratio computed over a dynamic sample are two different claims wearing one number, and after this upgrade a catalog will serve both without distinguishing them. An agent consuming that metric cannot weigh what it cannot see: how the value was measured, on what fraction, and when. Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. In that model, measurement provenance travels with the metric, and agent access to metadata is an explicit, governed decision. If your catalog is about to start talking to agents and you want that to be a policy rather than an accident, book a call.
Sources
- OpenMetadata, Release 2.0.0, August 24, 2026 (data-quality revamp, dynamic sampling default, cardinality distribution removed from defaults, Context Center, MCP server enabled by default, breaking changes and migration notes).
- OpenMetadata, releases index (1.13.4, August 21, 2026; 2.0.0-rc1, July 30; 2.0.0-rc2, August 13).
- Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale, arXiv:2608.00150, August 2026 (21,000+ internet-facing MCP server instances; 91.8 percent of dynamically audited production servers without OAuth).