Skip to main content

Data Governance Strategy

You'll define your organization's catalog, schema, and permission model on Unity Catalog in ~15 min.

Prereqs: Infra Setup (workspaces, users, groups, and metastore admin configured)

Why this matters​

Workspaces are running and users have access. The next decision — how you structure catalogs, schemas, and grants — determines whether teams can find, trust, and safely share data. A poorly designed governance model leads to permission creep, duplicated tables, and no clear ownership. Fixing it after hundreds of tables exist is painful.

This section covers two patterns. Pick the one that matches your organization size.

Journey checklist​

  • Get started.
  • Before you start.
  • Infra setup.
  • Cost monitoring.
  • Data Governance Strategy.
  • Access your data.
  • Build the first pipeline.
  • Automation and orchestration.
  • Query and explore.
  • Databricks AI/BI.
  • Business semantics.

How it works​

warning

Before choosing a pattern, review Add Groups — How it works to understand the expected group structure that your data governance model will build on.

tip

The two patterns in this section are based on:

Get Started​

Unity Catalog organizes data into a three-level namespace: catalog > schema > object. Your governance strategy defines how you map that hierarchy to your organization's teams, environments, and projects.

Two patterns cover most organizations:

PatternBest for
Small organizationsOne or two data teams, a single business unit, fewer moving parts
Medium-large organizationsMultiple business units, teams with different data boundaries, stricter isolation requirements

Both patterns use the same building blocks (catalogs per environment, medallion schemas, group-based grants). The difference is how many layers of prefixing and isolation you add.

Common pitfalls​

Skipping governance entirely​

Teams that jump straight to building pipelines without defining catalog and schema structure end up with ad-hoc tables scattered across default catalogs. Retroactively organizing them requires rewriting every reference.

Over-engineering for a small team​

A five-person team does not need business-unit prefixed catalogs. Start with the small-organization pattern. You can add prefixes and split catalogs later if the team grows.

Next​