Both vendors make the same architectural claim — that governance executes at the query engine rather than in the application — and that claim is the right axis on which to compare them. What differs is the enforcement mechanism and, more importantly, what happens when data leaves the engine.

Unity Catalog uses a three-level namespace — catalog, schema, object — covering tables, views, volumes, functions, models and services. The detail that catches people: storage credentials, external locations, connections and shares sit directly under the metastore, not inside the three-level namespace. They are metastore-level securables, which is why grants on them behave differently from grants on a table.

The distinction between managed and external tables is about who owns the storage lifecycle, not about who governs. Both are governed identically; only one gets its files deleted when you drop it.

Lineage is captured automatically from query execution, at both table and column level, and it spans tables, views, model versions, jobs, notebooks, pipelines and dashboards. It is genuinely useful. It is also incomplete in specific documented ways, and knowing them is what separates treating it as observability from treating it as an audit control.

Snowflake's masking and row-access policies are schema-level objects applied at query runtime. The implementation details are the interesting part:

• A masking policy is applied at every location where the column appears — not just in the select list, but in predicates and joins too.
• A row-access policy causes the engine to construct a dynamic secure inline view of the object, and — this is the important bit — the policy expression evaluates using the policy owner's role, not the querying role. That is what lets a policy read a mapping table the querying user cannot see.
• Ordering is fixed: the row-access policy evaluates before the masking policy, and a column cannot appear in both a row-policy signature and a masking-policy signature.
• Policies with simple SQL expressions perform better than ones that join a mapping table, and the documentation says so explicitly.
• And the consequence people meet in production: aggregate queries degrade because statistics become inaccessible under a row-access policy. The metadata-only path that answers a count or a maximum without touching data no longer applies, because the engine cannot know which rows you are entitled to see without reading them. Row-level security defeats metadata-only aggregation, and that is a real and permanent cost.

Delta Sharing is an open REST protocol (a plain web interface over HTTP). A recipient presents a bearer token; the sharing server checks the share and returns either pre-signed URLs for individual data files or temporary cloud credentials; and the client then reads directly from object storage.

The key insight, and the thing to say in an interview: the sharing server never proxies bytes. It is an authorisation service that hands out a short-lived capability to read the provider's files. That is why any client can consume it without deploying a platform, and why the storage and egress costs sit with the provider.

Snowflake Secure Data Sharing takes the opposite approach: no data is copied or transferred. A share is a named metadata object in the provider's account; the consumer mounts it, uses no storage of their own, and pays only for the compute to query it.