Databricks adds relationships between Unity Catalog metric views in Beta

Databricks has added relationships between Unity Catalog metric views, released in Beta and listed in the platform release notes on October 30, 2026. The feature lets a data team record, with an ALTER VIEW statement, how a source metric view joins to a target metric view, including the cardinality and the join condition. Databricks states that the purpose is to let AI assistants and BI tools that read Unity Catalog pick the right join path when a question spans two metric views, instead of guessing which columns connect them.

Metric views are the Unity Catalog object that holds governed business metrics. A team defines a measure once, such as revenue divided by distinct customers, and the query engine computes it correctly for whatever grouping a user chooses. Until now, a metric view could join dimension tables inside its own YAML definition, but there was no catalog-level way to say how one metric view relates to another. Relationships fill that gap as pure metadata, and the documentation is explicit that they do not fix a join, run on every query or change how queries are optimized.

The requirements are short. Relationships need Databricks Runtime 19 or later, or a SQL warehouse, and both the source and the target must be Unity Catalog metric views; temporary metric views are not supported. Because the feature is in Beta, Databricks does not recommend it for production, offers no SLA and warns that the interface may change, which sets the bar for how far a BI team should build on it today.

··········

HOW METRIC VIEW RELATIONSHIPS WORK IN UNITY CATALOG.

A relationship is a named, directed piece of metadata stored with its source metric view. It points to a target metric view, declares one of four cardinalities (MANY TO ONE, ONE TO MANY, ONE TO ONE or MANY TO MANY) and carries either an ON condition or a USING column list. The ON condition is validated like the ON clause of a join, so the statement fails if a column does not resolve or the condition is invalid. The condition must be deterministic and BOOLEAN, and it cannot reference measures or call aggregate, window or generator functions. USING columns must exist under the same name in both views.

The general syntax documented by Databricks is the following:

ALTER VIEW <source> ADD [CONSTRAINT name] {MANY | ONE} TO {MANY | ONE} RELATIONSHIP TO <target> [[AS] alias] {ON condition | USING (columns)}

The constraint name is optional. When it is omitted, Databricks names the relationship source_to_target, so a second unnamed relationship between the same two views fails. Names must be unique within the schema, and the target can live in any catalog or schema of the same metastore. Aliases are optional except for self-relationships, where the alias must differ from the source name, as in an employees view that points back to itself for managers.

The simplest documented case connects orders to customers through a shared key:

ALTER VIEW main.sales.orders_mv ADD CONSTRAINT orders_customer
  MANY TO ONE RELATIONSHIP TO main.sales.customers_mv
  USING (customer_id);

Aliases make it possible to declare more than one path between the same pair of views. The documentation shows a flights metric view that relates to a cities metric view twice, once for the departure city and once for the arrival city, which is exactly the kind of ambiguity an assistant generating SQL tends to get wrong:

ALTER VIEW main.travel.flights_mv ADD CONSTRAINT departure_city
  MANY TO ONE RELATIONSHIP TO main.travel.cities_mv AS c
  ON flights_mv.departure_city_id = c.city_id;

ALTER VIEW main.travel.flights_mv ADD CONSTRAINT arrival_city
  MANY TO ONE RELATIONSHIP TO main.travel.cities_mv AS c
  ON flights_mv.arrival_city_id = c.city_id;

··········

RELATIONSHIPS, METRIC VIEW JOINS AND DASHBOARD RELATIONSHIPS COMPARED.

Databricks now has three ways to express how data connects, and they serve different purposes. A join defined in the joins section of a metric view's YAML is fixed and runs every time that metric view is queried; it is how a fact source picks up dimension attributes in a star or snowflake schema. A dashboard relationship, defined in the Relationships pane of an AI/BI dashboard, encodes the query and filter logic of that one dashboard. A metric view relationship sits between the two: it is declared once in Unity Catalog, and the consumer decides whether and when to use it.

........

Method	Where it is defined	Behavior
Metric view relationship (Beta)	ALTER VIEW on the source metric view	Metadata only; the consumer chooses the join
Metric view join	joins section of the metric view YAML	Fixed join that runs on every query
Dashboard relationship	Relationships pane of an AI/BI dashboard	Encodes that dashboard's query and filter logic

........

The comparison with foreign keys is also useful for teams that already model constraints on tables. Foreign keys apply to tables and materialized views, require a primary or unique key on the target and an equality condition on key columns, and can be used for query optimization when declared with RELY. Relationships apply only to metric views, need no key on the target, accept any deterministic BOOLEAN condition and declare cardinality, but are never used for optimization. Neither kind of constraint is enforced against the data.

........

Property	Metric view relationship	Foreign key
Applies to	Metric views	Tables and materialized views
Key on target required	No	Yes, primary or unique
Join condition	Any deterministic BOOLEAN ON, or USING	Equality on key columns
Declares cardinality	Yes	No
Enforced	No	No
Used for optimization	No	Yes, with RELY

........

··········

PERMISSIONS NEEDED TO ADD OR DROP A METRIC VIEW RELATIONSHIP.

Adding a relationship requires MANAGE on the source metric view or ownership of it, SELECT on the target, and USE CATALOG and USE SCHEMA on the catalogs and schemas of both views. Dropping one requires MANAGE on the source or ownership, plus USE CATALOG and USE SCHEMA on the source's catalog and schema; no privilege on the target is needed. In practice this keeps relationship authoring with whoever owns the source semantic model, while the owner of a shared dimension view, such as customers, does not have to approve every inbound link.

Relationships are visible in two places. DESCRIBE TABLE EXTENDED on the source lists them under the Constraints section, and the AS JSON form returns them in the table_constraints field. For a catalog-wide inventory, the documentation points to the information schema:

SELECT table_schema, table_name, constraint_name
FROM main.information_schema.table_constraints
WHERE constraint_type = 'RELATIONSHIP';

Removing a relationship uses DROP CONSTRAINT on the source. Without IF EXISTS, the statement fails with NO_SUCH_CONSTRAINT_EXCEPTION when the name does not exist:

ALTER VIEW main.travel.flights_mv DROP CONSTRAINT IF EXISTS arrival_city;

Lifecycle rules follow the source. Dropping a source metric view deletes its relationships, and dropping a target removes the inbound relationships from the views that pointed to it.

··········

GENIE CODE AND AI ASSISTANTS READING METRIC VIEW RELATIONSHIPS.

The most concrete documented consumer today is Genie Code when it authors AI/BI dashboards. On import, when a dashboard uses Unity Catalog metric views, the agent reads their relationships and adds the ones it needs as dashboard relationships. On export, when a user asks, the agent can declare a dashboard relationship on the source metric view after the user approves it. Both datasets must be Unity Catalog metric views, the exported relationship always uses an ON condition, and the same privileges apply as for a manual ALTER VIEW.

Beyond Genie, Databricks describes relationships in general terms as metadata that AI assistants and BI tools read from Unity Catalog to choose joins per analysis. The documentation does not list which external BI tools or third-party assistants read relationships at launch, so teams connecting Power BI, Tableau or an external agent should test that behavior rather than assume it. The same question applies to agents that query warehouses through connectors, such as the Data agent OpenAI added to ChatGPT Work, which draws on semantic layers including Databricks sources, and to coding assistants that reach databases through MCP integrations like those in Claude Code.

For analysts, the value is fewer silent join errors. When a question such as revenue by arrival city spans two metric views, an assistant that sees a named arrival_city relationship has a documented path instead of inferring one from column names. The same review discipline that applies to AI-generated analysis in ChatGPT still holds, because the relationship tells a tool which path exists, not whether the resulting numbers are right.

··········

METRIC VIEW RELATIONSHIP LIMITS AND BETA CONDITIONS.

The documented limits are specific. Relationships can be declared only with ALTER VIEW and not inside the metric view YAML, so teams that manage metric views as YAML in source control need a separate SQL step in their deployment. They are not enforced or checked against data, and RELY is not supported. A target metric view does not list its inbound relationships, so auditing who depends on a shared dimension means checking each source or querying the information schema.

........

Limit	Documented value or behavior
Compute	Databricks Runtime 19 or later, or a SQL warehouse
Outbound relationships per source	50
Inbound relationships per target	100
Error when a quota is exceeded	UC_RESOURCE_QUOTA_EXCEEDED
Declaration method	ALTER VIEW only, not the YAML definition
REST API and SDKs	Not supported; SQL only
Renaming a metric view	ON conditions keep the old name; drop and re-add

........

The rename behavior deserves a line in any runbook: renaming a metric view does not update ON conditions that reference the old name, so the relationship has to be dropped and added again. Beta status adds its own conditions. Beta features are on by default for Premium customers and off by default for Enterprise customers, workspace admins can switch them on or off, and support comes from the engineering team rather than the support organization. If the feature does not appear, Databricks directs customers to their account team.

··········

DATABRICKS METRIC VIEW RELATIONSHIPS: WHAT BI TEAMS CAN RELY ON NOW.

Confirmed by Databricks: the ALTER VIEW syntax with four cardinalities and ON or USING conditions, the privileges for adding and dropping, visibility through DESCRIBE TABLE EXTENDED and INFORMATION_SCHEMA.TABLE_CONSTRAINTS, the 50 outbound and 100 inbound quotas, and Genie Code's import and export of relationships when authoring AI/BI dashboards.

Dependent on the account: whether Beta features are enabled in a given workspace, which follows the Premium or Enterprise default and the admin's choice, and whether the compute in use meets the Runtime 19 or SQL warehouse requirement.

Not disclosed: which external BI tools and third-party assistants read relationships today, a date for Public Preview or general availability, and REST API or SDK support. A reasonable first step is to declare relationships for the few ambiguous paths that already cause errors, such as role-playing dimensions like departure and arrival city, and to keep the SQL that creates them in version control alongside the YAML that defines the metric views.

··········

FOLLOW US FOR MORE.

·····

DATA STUDIOS

·····

datastudios.org