Skip to main content

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​

A small team still needs clear boundaries between development and production data. Without them, an experimental query can corrupt a table that feeds executive dashboards. The model below gives you environment isolation, a consistent schema structure, and least-privilege access — without the overhead of business-unit prefixes.

Mental model​

Three catalogs map 1:1 to your three workspaces. Inside each catalog, schemas follow the medallion architecture (bronze, silver, gold) per project. Groups control who can read, write, or own each schema.

How it works​

Catalogs​

Three catalogs: development, staging, production
tip

Add a sandbox catalog for ad-hoc exploration and demos that should not interfere with any project schema.

Development — the playground where teams build and experiment. All data teams have access. Mistakes here are expected and do not affect production. Bound to the development workspace.

Staging — the final checkpoint before production. Developers push finished work here for integration testing. DevOps or QA teams validate the output. Bound to the staging workspace.

Production — the official, high-quality data. Business users consume dashboards and reports from this catalog. Modifications happen exclusively through automation and service principals — no manual writes. Bound to the production workspace.

Schemas — the medallion architecture​

Each project gets three schemas that reflect the data refinement stages: bronze, silver, and gold.

Medallion schemas: bronze, silver, gold per project

For a detailed explanation of this pattern, see Modeling a Medallion Architecture on Unity Catalog.

Bronze​

Raw data from external sources, ingested as-is. Nothing is edited, filtered, or deduplicated at this layer.

  • Naming: [project]_bronze
  • Purpose: Historical record of source data. If a downstream transformation breaks, you reprocess from bronze instead of re-extracting from the source.
  • Typical objects: Streaming tables reading from cloud object storage, tables created by Lakeflow ingestion pipelines.

Silver​

Cleaned and conformed data. Bronze records are deduplicated, data types are standardized, and related tables are joined into a coherent model.

  • Naming: [project]_silver
  • Purpose: Single source of truth for analysts running ad-hoc queries. Data here is reliable and consistently formatted.
  • Typical objects: Streaming tables with transformations from bronze, standard tables with batch transformations.

Gold​

Business-level aggregates and metrics built on top of silver. Structured to answer specific questions — total sales by region, monthly active users, churn rates.

  • Naming: [project]_gold
  • Purpose: Powers dashboards, executive reports, and BI tools. Optimized for query speed and clarity, not raw detail.
  • Typical objects: Materialized views, metric views, summary tables.

Permissions and grants​

Group permissions across medallion schemas

Example: Customer 360 project with group-based grants at the schema level.

The rules are straightforward:

Ownership — the group responsible for a project owns that project's schemas. If marketing-data-engineers builds the C360 pipeline, they own c360_bronze, c360_silver, and c360_gold.

Sharing — when another team needs access, the owners grant it at the schema level:

  • Data Reader — read-only access to all tables in the schema.
  • Data Editor — read and write access.

Grant at the schema level, not per table. Per-table grants do not scale and are easy to forget when new tables are added.

Least privilege — only grant the access a team actually needs. Read-only for analysts, read-write for engineers working on the project, view-only for business users consuming dashboards.

When to use / when not to​

Use this model when:

  • You have one or two data teams.
  • All teams work within a single business unit or share the same data boundaries.
  • You want the simplest governance model that still enforces environment isolation and least-privilege access.

Consider 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-level or catalog-level prefixes for organizational clarity.

Common pitfalls​

Granting permissions on individual tables​

Per-table grants are tedious and brittle. New tables do not inherit them. Always grant at the schema level so new objects automatically pick up the correct permissions.

Manual writes to production​

Production data should only be modified by automated pipelines running as service principals. If a human can write directly to production, a fat-finger query can break a dashboard the CEO checks every morning.

Next​