Databricks Unity Catalog best practices for manufacturing
Design catalogs, workspace isolation, permissions and storage so governance scales across development, production and manufacturing domains without creating a permissions maze.
Regional root
West Europe metastore
dev_factory
Development catalog
prd_factory
Production catalog
reference
Shared governed data
platform
Controlled admin scope
The metastore is regional. Most day-to-day isolation belongs at the catalog and workspace boundary.
Start with region, then use catalogs and workspace bindings.
Are the workspaces in the same Azure region?
Start hereYes
Use the regional metastore
Separate dev, staging and production with catalogs. Bind sensitive catalogs to the intended workspace.
No
Use one metastore per region
Share governed data across regional metastores instead of registering the same table independently in multiple metastores.
Stronger isolation requirement
Use separate accounts or regions only when regulatory, sovereignty or organizational isolation cannot be met with catalogs and workspace bindings.
Architecture
Use one metastore per region, then isolate with catalogs
The metastore is the regional governance root. Catalogs are the normal boundary for environments, domains and ownership inside that region.
Regional metastore
Attach same-region workspaces to the same Unity Catalog metastore.
Catalog boundaries
Use catalogs where environment, domain or access requirements materially change.
Workspace isolation
Bindings add an enforceable workspace boundary on top of object privileges.
Catalog design
Put catalog boundaries where ownership or access changes
A useful catalog structure is predictable enough for users to understand and coarse enough for access policies to remain manageable.
Catalog
environment, domain, sensitivity or ownership
prd_factory
Schema
a cohesive subject area inside one catalog
production · inventory · quality
Table / view
a governed data product or access surface
production_run_fact
Volume
non-tabular governed files
quality_certificates
Managed storage
Prefer catalog-level managed storage for clear isolation
Managed storage can be configured at metastore, catalog or schema level. Databricks recommends catalog-level storage as the primary isolation unit, with schema-level locations used when a narrower boundary is required.
Dedicated managed storage
Keep Unity Catalog managed data in storage that is not accessed directly by other services or users.
Lowest configured location wins
Schema storage overrides catalog storage, which overrides a metastore fallback.
Keep DBFS root separate
Do not reuse DBFS root storage for Unity Catalog managed or external data.
Use the narrowest configured managed location.
Fallback
Metastore storage
Preferred boundary
Catalog storage
Narrow exception
Schema storage
External locations are separate securable objects for governed access to storage paths that must remain externally managed.
Permissions
Grant access to groups at the highest sensible level
Use the privilege hierarchy instead of maintaining large lists of table grants. Keep human consumption, pipeline writes and platform administration separate.
Account groups
Grant to stable groups rather than individual users.
Navigation plus action
Users normally need USE CATALOG and USE SCHEMA in addition to the object privilege they use.
Group ownership
Assign production catalog and schema ownership to groups, not named individuals.
Analysts
USE CATALOG
USE SCHEMA
SELECT
Pipelines
USE CATALOG
USE SCHEMA
CREATE / MODIFY
Platform admins
ownership
MANAGE
metastore controls
GRANT USE CATALOG ON CATALOG prd_factory TO `grp_factory_analysts`;
GRANT USE SCHEMA ON SCHEMA prd_factory.gold TO `grp_factory_analysts`;
GRANT SELECT ON SCHEMA prd_factory.gold TO `grp_factory_analysts`;
GRANT USE CATALOG ON CATALOG prd_factory TO `spn_factory_pipeline`;
GRANT USE SCHEMA ON SCHEMA prd_factory.silver TO `spn_factory_pipeline`;
GRANT CREATE TABLE, MODIFY, SELECT
ON SCHEMA prd_factory.silver TO `spn_factory_pipeline`;Dev workspace
dev_factory
Prod workspace
prd_factory
An explicit catalog grant is not enough from an unbound workspace. The workspace binding must allow access too.
Workspace isolation
Bind production catalogs to the production workspace
Catalogs are accessible from all workspaces attached to the metastore by default. Workspace bindings change that default and can make environment isolation enforceable.
Use ISOLATED mode for production
Restrict a production catalog to the production workspace or approved workspace set.
Privileges still apply
Bindings control where an object can be reached. Grants control who can use it.
Bind sensitive infrastructure too
Workspace bindings can also restrict external locations and storage credentials.
Fine-grained access
Use governed tags and policies when access rules need to scale
For repeated row filters and column masks across many tables, Unity Catalog ABAC centralizes the policy and applies it automatically to assets that match governed tags.
Governed tags
Use a controlled taxonomy for sensitivity, domain or lifecycle attributes.
Central policies
Apply masking or filtering rules at catalog or schema scope instead of repeating table-specific logic.
Separation of duties
Control who can define policies and who can assign the tags that activate them.
Classify once, apply the rule consistently.
1 · Classify
2 · Policy
Mask sensitive columns
Policy attached at catalog or schema scope
3 · Enforce
Use table-level row filters or masks when the rule is genuinely specific to one table. Use ABAC when the same policy should apply consistently across many assets.
Manufacturing governance
Map catalogs to real manufacturing ownership
Manufacturing data crosses ERP, MES, WMS, quality and commercial processes. Catalogs should reflect who owns the governed data products rather than mirroring every source system.
factoryOperations / manufacturing
production · OEE · yield · downtime
supplySupply chain
inventory · batch · shelf life · logistics
commercialSales / finance
orders · customers · margin inputs
referenceData governance
product · site · customer · shared mappings
Avoid creating one catalog per source application or one catalog per table. That creates many security boundaries without creating clearer ownership.
Operating model
Operate governance as a recurring control process
Unity Catalog gives you control points, lineage and audit data. Governance stays reliable only when teams review ownership, access and change impact on a recurring basis.
Discover
lineage · tags · usage
Review
owners · groups · privileged access
Change
impact · bindings · policies
Audit
system tables · evidence
Lineage before change
Check downstream tables, jobs and dashboards before changing shared production assets.
System tables for evidence
Use audit and lineage system tables for account-level operational visibility and recurring reviews.
Certification and deprecation
Mark trusted assets clearly and retire obsolete data products instead of leaving competing versions active.
How Food For Analytics implements it
Titan uses Unity Catalog as the governance layer around manufacturing data products
We keep source connectivity, data-product ownership and access controls explicit. Unity Catalog then provides the common governance model across Databricks workspaces and consumers.
Platform inputs
Manufacturing data products
Production, inventory, quality, delivery and reference data with clear ownership and grain.
Titan on Azure Databricks
Govern the platform
Apply catalogs, storage boundaries, workspace bindings, group permissions and governance metadata where they belong.
Governed access
Reuse data with control
Expose approved manufacturing data to engineering, BI, analytics and Ask Titan without bypassing the platform governance model.
Common mistakes
Keep governance boundaries few enough to understand
Unity Catalog becomes difficult to operate when every workspace, source or exception creates another ownership or permission pattern.
Avoid
A separate metastore for every workspace
Better default
Use one metastore per region and catalogs for normal isolation
Avoid
Production catalog visible from development workspaces
Better default
Bind production catalogs in ISOLATED mode
Avoid
Direct grants to individual users
Better default
Grant to stable account groups
Avoid
One catalog for every source application
Better default
Align catalogs with environment, domain and ownership
Avoid
Managed storage that can be accessed outside Unity Catalog
Better default
Use dedicated storage controlled through Unity Catalog
Avoid
Repeated table-specific masks across the estate
Better default
Use governed tags and ABAC for policies that need to scale
FAQ
Frequently asked questions
Practical answers about Unity Catalog architecture and governance on Azure Databricks.
How many Unity Catalog metastores should I create?
Within an Azure Databricks account, use one metastore per Azure region. Attach same-region workspaces to that metastore and use catalogs and workspace bindings for normal environment and domain isolation.
Should development and production use separate metastores?
Usually not when the workspaces are in the same region. Separate development and production with catalogs, group permissions and workspace bindings. Use separate accounts or regions only when stronger regulatory, sovereignty or organizational isolation requires it.
What is the main isolation boundary in Unity Catalog?
Catalogs are the primary data-isolation unit in the typical Unity Catalog governance model. Schemas organize objects inside a catalog, while workspace bindings can restrict a catalog to specific workspaces.
Where should Unity Catalog managed storage be configured?
Catalog-level managed storage is the preferred primary isolation boundary. Schema-level managed storage can override it where a narrower boundary is required. Metastore-level managed storage is optional and can act as a fallback.
Should users receive direct grants on tables?
Prefer account groups and grant privileges at the highest sensible level in the Unity Catalog hierarchy. Direct user grants and object-specific exceptions should remain deliberate and limited.
When should I use Unity Catalog ABAC?
Use attribute-based access control when the same row-filtering or column-masking policy should apply consistently across many tagged assets. Table-level filters and masks remain useful for rules that are genuinely specific to one table.
Practical next step
Turn Unity Catalog into an operating governance model
Start with the regional metastore, catalog boundaries and production workspace isolation. Then make storage, group access and operational review part of the same design.