1.6 Feature Tables in Unity Catalog vs. the Workspace Feature Store

1.6 Feature Tables in Unity Catalog vs. the Workspace Feature Store

In enterprise machine learning, feature reusability, consistency, and governance are paramount. Without a centralized feature platform, disparate data science teams frequently rewrite identical feature transformations (e.g., calculating 30-day average transaction volumes), leading to code duplication, computational waste, and severe train/serve skew.

Feature Engineering in Unity Catalog represents the evolution of the Databricks Feature Store. It replaces legacy, workspace-confined feature stores with an account-level architecture governed under Unity Catalog's standard 3-level namespace (catalog.schema.table).

Both tables belong to the metastore rather than to a workspace, which is the entire point: prod_catalog.ml_features.customer_360_features resolves to the same physical data from every workspace attached to that metastore.

---

Workspace Feature Store vs. Feature Engineering in Unity Catalog

Understanding the architectural advantages of Unity Catalog feature tables over legacy workspace feature stores is a primary focus of the Databricks ML certification.

---

Why Account-Level Registration Changes the Economics

The comparison table above lists the mechanical differences. The exam cares about the consequences, which are worth stating explicitly.

One definition, many consumers

A workspace-scoped feature table is invisible outside its workspace. In a typical enterprise with separate workspaces for marketing, risk, and operations, the same customer_30d_spend feature gets rebuilt three times, with three slightly different window definitions. When those teams later compare model results, the discrepancy is untraceable. An account-level table has exactly one definition, and every team reads the same computed values.

Governance uses the tools the platform already has

Because a Unity Catalog feature table is a Delta table with feature metadata, access is granted with ordinary SQL:

GRANT SELECT ON TABLE prod_catalog.ml_features.customer_spending TO `data-scientists`;
GRANT MODIFY ON TABLE prod_catalog.ml_features.customer_spending TO `sp-feature-pipeline`;

Column masks, row filters, tags, and audit logs apply the same way they do to any other governed table. The workspace feature store required a parallel permission model that no data governance team could reconcile with the rest of the estate.

Lineage becomes end-to-end and automatic

Unity Catalog records, without instrumentation, that a bronze table fed a feature computation job, that the job wrote a feature table, that a training run consumed particular feature columns, that the run produced a registered model version, and that the version backs a serving endpoint. Two questions become answerable in seconds:

• If this upstream table is wrong, which production models are affected?
• Which features does this production model actually depend on?

Discoverability prevents duplicated work

Account-level tables are searchable in Catalog Explorer with descriptions, tags, and owners. Feature reuse is only possible when engineers can find what already exists.

What changes in your code

Exam tip: any option that describes copying feature tables between workspaces, or maintaining per-workspace ACL scripts, is describing the legacy architecture and is the wrong answer when Unity Catalog is available.

---

What Actually Makes a Table a Feature Table

The most commonly missed fact in this objective is that Unity Catalog has no separate feature-table storage type. Any Delta table in Unity Catalog that carries a primary key constraint can be used as a feature table. There is no registration call, no proprietary format, and nothing preventing an analyst from querying it with ordinary SQL.

That single design decision produces most of the benefits listed above. A feature table is a governed Delta table, so every capability the platform already has — grants, tags, comments, lineage, Delta history, OPTIMIZE — applies to it with no parallel implementation.

Requirements to satisfy

Promoting an existing Delta table

Because the requirement is only a constraint, an existing Delta table becomes a feature table with two DDL statements — no data movement and no rewrite:

ALTER TABLE prod_catalog.ml_features.customer_spending
  ALTER COLUMN customer_id SET NOT NULL;

ALTER TABLE prod_catalog.ml_features.customer_spending
  ADD CONSTRAINT customer_spending_pk PRIMARY KEY (customer_id);

The order matters: the NOT NULL designation must be in place on every column named in the key before the primary key constraint is added. The legacy workspace feature store offered no equivalent path — a table had to be created through the feature store client and registered in a workspace-local registry, so adopting an existing curated table meant copying it.

Privileges involved

Setting up the namespace uses ordinary Unity Catalog privileges rather than a feature-store-specific permission model:

• CREATE CATALOG on the metastore to create a new catalog, or USE CATALOG on an existing one.
• CREATE SCHEMA on the catalog to create the schema that will hold feature tables.
• SELECT on the table for anyone who trains against it, and MODIFY for the pipeline identity that writes to it.

A scenario describing a data scientist who can see a feature table in Catalog Explorer but cannot build a training set from it is almost always missing SELECT — not some feature-store-specific grant.