How to structure catalogs, schemas, and permissions for a large org

Summary

• Three-tier namespace mirrors org structure. Use catalogs for business units or departments, schemas for logical data domains within each unit, and tables for specific data products. This hierarchy lets teams own their data without stepping on each other's toes.
• Permissions flow from role. Assign users to roles (Analyst, Data Engineer, Admin), then grant each role permission at the catalog or schema level. This role-based approach is auditable and scalable as teams grow.
• Isolate by sensitivity and ownership. Put raw, sensitive data in restricted catalogs; derived, aggregated data in open catalogs. Each business unit owns its catalog and controls access to its schemas.
• Audit and lineage are built in. Every access is logged by user and role. Track which users queried what data and which tables feed into which reports, so your compliance team can answer auditors in minutes.

How to structure catalogs, schemas, and permissions for a large org

In a large organization, data lives everywhere: marketing analytics in one tool, finance in another, operations in a third. When you consolidate everything into Unity Catalog on the lakehouse, the question becomes: how do you organize it so teams can self-serve without chaos?
The answer is to mirror your org structure in the three-tier namespace: catalogs for business units, schemas for data domains or use cases within each unit, and tables for specific data sets. Then layer permissions on top: grant roles (not individual users) permission to catalogs and schemas. This approach scales from 50 users to 50,000 because teams work in isolation, the permission model is simple to audit, and new users can be onboarded by adding them to a role.

Why structure matters

• Autonomy without anarchy. Each team owns its catalogs and controls who can access them. A finance team can lock down sensitive data while an analytics team can open their catalog to read-only queries. No permission creep, no accidental data leaks.
• Discoverability. New team members can navigate finance.accounting.general_ledger or marketing.campaigns.lead_scores and immediately understand what data exists and where.
• Audit and compliance. Every table is owned by a team, every access is logged by user and role, and every table carries lineage back to its sources. Auditors can trace data flow in seconds.
• Simplicity at scale. Instead of managing hundreds of individual table-level permissions, you manage a handful of roles and grant them at the catalog or schema level. When a new analyst joins, add them to the analyst role in Unity Catalog and they inherit all relevant permissions.

Architecture: Catalogs, schemas, and roles

A typical structure for a large organization looks like this:

Tier	Example	Purpose	Who Owns
Catalog	finance, marketing, operations, data_platform	Business unit or function. Highest-level isolation.	VP or Director of each unit
Schema	finance.accounting, finance.treasury, marketing.campaigns, operations.supply_chain	Data domain or use case within a unit. Logical grouping.	Domain lead or data steward
Table	finance.accounting.general_ledger, marketing.campaigns.performance	Specific data set. Owned by a team.	Data owner or engineer
Role	finance_analyst, marketing_engineer, data_platform_admin	Permission set granted to users.	HR/HRIS or identity provider

Getting started: Build your structure

1. Map your organization. List your business units (Finance, Sales, Marketing, Operations, Data Platform, etc.) and data domains within each. For Finance, that might be Accounting, Treasury, Tax, and FP&A. For Marketing, it might be Campaigns, Attribution, Performance, and Insights. This becomes your catalog and schema names.
2. Create catalogs for each business unit. In Unity Catalog, create one catalog per unit:
   

   CREATE CATALOG finance;
   CREATE CATALOG marketing;
   CREATE CATALOG operations;
   

3. Create schemas within each catalog. For Finance, create schemas for each domain:
   

   CREATE SCHEMA finance.accounting;
   CREATE SCHEMA finance.treasury;
   CREATE SCHEMA finance.tax;
   

4. Define roles at your identity provider (SSO). In your company's directory, create role-based groups:
   • finance_analyst - users who read financial data
   • finance_data_engineer - users who build and maintain financial pipelines
   • finance_admin - users who manage the Finance catalog
   • Similarly for Marketing, Operations, etc.
5. Grant role-based permissions in Unity Catalog. Use GRANT statements to assign permissions by role:
   

   GRANT SELECT ON CATALOG finance TO finance_analyst;
   GRANT MODIFY ON SCHEMA finance.accounting TO finance_data_engineer;
   GRANT OWNER ON CATALOG finance TO finance_admin;
   

6. Separate sensitive and open data. Within a catalog, use schemas to isolate sensitive data. For example:
   • finance.accounting - restricted to Finance only
   • finance.reporting - open to the whole company for read access
   • A user gets broader access to reporting and narrow access to accounting.
7. Add column-level access control for PII. Mark columns that contain sensitive data (social security number, salary, credit card) with a tag. Use dynamic view masks or column-level permissions to hide them from non-admins.
8. Audit and monitor. Query the audit logs to see who accessed what data and when.

Permission model: Keep it simple

• Avoid individual user grants. Always grant to roles, not users. When someone leaves, remove them from the role; when someone joins, add them to the role. Permissions flow automatically.
• Use catalogs for hard boundaries. Catalogs are the firewall. If a team should never see another team's data (e.g., HR data is only for HR), put it in a separate catalog and grant only the HR role access.
• Use schemas for soft boundaries. Within a catalog, schemas are for organization and search. A user might have broad SELECT on a catalog but EXECUTE only on specific stored procedures in a schema.
• Use tables for fine-grained control. Table-level grants are rare in large orgs (they don't scale), but when needed, use them sparingly.

FAQs

How many catalogs and schemas should I create?

One catalog per business unit or major function. For a 500-person company, you might have 5-10 catalogs. One to three schemas per catalog depending on your data domains. Err on the side of fewer, larger schemas rather than many small ones; they're easier to manage.

How do I handle cross-functional projects that need data from multiple catalogs?

Create a dedicated catalog for the project and grant roles from both teams permission to read from it. Or use a shared schema and grant cross-functional read access.

What happens if I grant permission too broadly by mistake?

Unity Catalog makes it easy to audit permissions. Query system tables to see who has access to what. If you grant SELECT on a catalog to everyone and want to narrow it, revoke the catalog grant and grant at the schema level instead. There is no undo but you can always revoke and re-grant more narrowly.

Can I use identity groups from my SSO provider directly in Unity Catalog?

Yes. If your identity provider already has group definitions, sync them to Unity Catalog using SCIM or the Databricks provisioning API. Then grant permissions to those groups directly.