Small organizations
You'll understand how to structure catalogs, schemas, and permissions for a small data team in ~10 min.
Prereqs: Data Governance Strategy
Why this matters
Small does not mean no boundaries. You still need a wall between the data people are experimenting on and the data feeding executive dashboards, or one stray query takes down a report someone trusts. This model gives you that wall, a consistent schema layout, and least-privilege access, and it skips the business-unit prefixes that a small team does not need yet.
Mental model
Three catalogs, one per workspace. Inside each catalog, schemas follow the medallion architecture (bronze, silver, gold), one set per project. Groups decide who can read, write, or own each schema. That is the whole model.
How it works
Catalogs
Add a sandbox catalog for ad-hoc exploration and demos that should not interfere with any project schema.
Development is the playground. All data teams have access, mistakes are expected, and nothing here touches production. It is bound to the development workspace.
Staging is the last checkpoint before production. Developers push finished work here for integration testing, and DevOps or QA validates the output. It is bound to the staging workspace.
Production is the real, trusted data. Business users read their dashboards and reports from here. The only thing that writes to it is automation running as a service principal. No manual writes, ever. It is bound to the production workspace.
Schemas: the medallion architecture
Each project gets three schemas, one per refinement stage: bronze, silver, and gold.
For a detailed explanation of this pattern, see Modeling a Medallion Architecture on Unity Catalog.
| Layer | Naming | What goes in | Purpose |
|---|---|---|---|
| Bronze | [project]_bronze | Streaming tables from cloud object storage; Lakeflow ingestion pipelines | Raw data landed exactly as it arrived. Nothing edited, filtered, or deduplicated. Reprocess from here when a downstream transformation breaks. |
| Silver | [project]_silver | Streaming tables with bronze transformations; batch transformation tables | Cleaned, deduped, and conformed data. The single source of truth for analysts running ad-hoc queries. |
| Gold | [project]_gold | Materialized views, metric views, summary tables | Business-level aggregates built on silver. What dashboards, executive reports, and BI tools read from. |
Permissions and grants
Example: Customer 360 project with group-based grants at the schema level.
| Rule | What it means |
|---|---|
| Ownership | The group that builds a project owns its schemas. If marketing-data-engineers builds the C360 pipeline, they own c360_bronze, c360_silver, and c360_gold. |
| Sharing | When another team needs access, owners grant at the schema level. Data Reader is read-only on every table in the schema; Data Editor adds write access. Per-table grants do not scale and break the moment someone adds a new table. |
| Least privilege | Grant only what a team actually needs. Read-only for analysts, read-write for engineers on the project, view-only for business users reading dashboards. |
When to use / when not to
Use this model when:
- You have one or two data teams.
- Everyone works in a single business unit or shares the same data boundaries.
- You want the simplest model that still enforces environment isolation and least privilege.
Move to the medium-large model when:
- Multiple business units need separate catalog namespaces.
- Teams from different departments must not see each other's development data.
- You need workspace or catalog prefixes to keep things organized.
Common pitfalls
Granting permissions on individual tables
Per-table grants are tedious and break the first time someone adds a table, because new tables do not inherit them. Grant at the schema level so new objects pick up the right permissions on their own.
Manual writes to production
Only automated pipelines running as service principals should touch production. The day a human can write to it directly is the day one fat-fingered query breaks the dashboard the CEO checks every morning.
Next
- Do next: Medium-large organizations
- Learn why: Unity Catalog foundations
- Reference: Unity Catalog best practices