Catalog-Centric Control Plane
The pattern where the table catalog — not any single engine — becomes the lakehouse control surface, owning credential vending, authorization/policy, federation, scan planning, and agent access via MCP.
Summary
The pattern where the table catalog — not any single engine — becomes the lakehouse control surface, owning credential vending, authorization/policy, federation, scan planning, and agent access via MCP.
The 2026 convergence point for Apache Polaris, Unity Catalog, and Apache Gravitino. When many engines and AI agents share the same Iceberg tables, governance moves out of the engine and into the catalog so one boundary scopes both human and agent access.
- "Control plane" is not a product — it's the role the catalog grows into. Different catalogs implement different slices (Polaris: pluggable authz + Ranger; Gravitino: scan-planning offload; UC: managed MCP servers).
- Agent access through MCP is governed by the catalog boundary only if you wire agents through the managed MCP server, not around it.
implementsIceberg REST Catalog Spec — the substrate the control plane is built onaugmentsModel Context Protocol (MCP) — the agent-facing access pathsolvesVendor Lock-In, Tool Discovery Governance Gap — neutral governance for engines and agents
Definition
An architectural pattern in which the table catalog — not any single query engine — becomes the control surface of the lakehouse. The catalog absorbs responsibilities that used to live in engines or side systems: short-lived credential vending, authorization and policy enforcement, cross-vendor federation, scan/query planning, and — increasingly — agent access via the Model Context Protocol.
When Spark, Trino, DuckDB, Snowflake, ClickHouse, and a fleet of AI agents all read and write the same Iceberg tables on object storage, governance cannot live inside any one engine. Centralizing it in the catalog gives a single, vendor-neutral place to mint credentials, enforce row/column policy, and grant or deny access — to both humans and agents — regardless of which engine or model is asking.
Multi-engine lakehouse governance, short-lived credential vending in place of long-lived keys, cross-catalog / cross-cloud federation, engine-side scan-planning offload, scoping AI-agent access to governed data through MCP.
Recent developments
- The major catalogs converged on the control-plane role within one quarter. Apache Polaris 1.5.0 (May 18, 2026) added pluggable authorization + Apache Ranger (Beta), BigQuery Metastore federation, and Generic-Table credential vending; Unity Catalog moved Managed/Foreign Iceberg + v3 to GA over the open Iceberg REST API; Apache Gravitino 1.2.0 added scan-planning offload so DuckDB/Spark delegate planning to its IRC server. Per Snowflake — Apache Polaris 1.5 Release, Databricks — Unity Catalog and the next era of Apache Iceberg, and Gravitino 1.2.0 release notes.
- The control plane is now agent-facing, not just engine-facing. Gravitino ships an MCP server + Model Catalog exposing governed metadata to AI tools; Databricks' managed MCP servers expose Unity Catalog tables, functions, and Vector Search indexes to agents natively — so the catalog's authorization boundary scopes agent access the same way it scopes human access. Per Gravitino 1.1.0 — AI-native metadata platform and Databricks — Expanded interoperability with Unity Catalog Open APIs.
Connections 9
Outbound 6
scoped_to2implements1augments1Inbound 3
implements3Resources 4
Polaris 1.5 — pluggable Authorizer SPI, Apache Ranger (Beta), BigQuery Metastore federation, Generic-Table credential vending: the catalog absorbing control-plane duties.
Unity Catalog's Managed/Foreign Iceberg + v3 GA over the Iceberg REST API, plus agent access via managed MCP servers.
Gravitino 1.2.0 scan-planning offload — engines delegate Iceberg planning to the catalog's IRC server, the engine-side half of the control-plane shift.
Comparative framing of Polaris vs Unity Catalog vs cloud REST catalogs explicitly as "Iceberg control plane" choices.