Unity Catalog - How to read prod data in dev with appropriate read-only access?

[ChristianRRL]

Hi there,

Our team is currently migrating to using Unity Catalog. We have two databricks workspaces for dev & prod, and one thing that I'm wondering is if there is a simple/appropriate way to have only two catalogs dev & prod, where the prod databricks workspace has read-write access to the prod catalog, and in the dev workspace we have read-write access to the dev catalog AND read-only access to the prod catalog.

One approach that our team is considering is having 3 catalogs: dev, prod, and prod_readonly, where the prod_readonly would be available in the dev environment. But I'm wondering, can we accomplish this same functionality with only having two catalogs and ensuring the prod catalog cannot be edited if in the dev workspace.

[szymon_dybczak · Accepted solution]

Hi  @ChristianRRL ,

Yes, you can absolutely do this with just two catalogs.  The prod_readonly catalog idea is unnecessary in this case. Unity Catalog has a first-class feature called workspace-catalog binding that handles this exact scenario.

By default, all catalogs in Unity Catalog are accessible from any workspace attached to the same metastore. Workspace-catalog binding lets you override this default to restrict a catalog to one or more specific workspaces, and when binding a catalog to a workspace, you can optionally restrict that workspace to read-only access - all write operations from that workspace to the catalog are blocked.

Critically, these bindings override user-level permissions. If a user has privileges on an object but tries to access it from an unbound workspace, access is denied. This means you don't need to fiddle with fine-grained GRANTs to achieve the isolation - the binding itself enforces it at the platform level.

You can read more at below link:

Workspace-catalog binding | Databricks on AWS

[nayan_wylde · Accepted solution]

Yes — you can accomplish exactly what you described with only two catalogs (dev + prod). You do not need a third prod_readonly catalog.
There are two complementary control planes in Unity Catalog:

Workspace-level restriction (workspace-catalog binding) = controls where a catalog can be accessed from, and can enforce read-only from a specific workspace.
UC privileges (GRANT/REVOKE) = controls who can read/write/manage objects within the catalog.

The cleanest pattern for Dev RW + Prod RO is:

• Bind prod catalog to both workspaces, but mark the Dev workspace binding as read-only.
• Grant read-only privileges to dev principals on prod catalog/schemas/tables.
• Keep prod workspace binding as read-write and grant write privileges only to prod principals / service principals.

[mukul1409]

A useful pattern is to keep the dev and prod catalogs separate without creating a third prod_readonly catalog.

Use Unity Catalog workspace-catalog binding to expose the prod catalog to the Dev workspace as read-only, while keeping it read-write in the Prod workspace.

You can then use normal Unity Catalog privileges such as USE CATALOG, USE SCHEMA, and SELECT to control what Dev users can access.

The resulting model is:

Dev workspace -> dev catalog -> Read/Write
Dev workspace -> prod catalog -> Read Only
Prod workspace -> prod catalog -> Read/Write

This allows Dev engineers to validate against production data while preventing them from modifying production objects.

I would also verify that the Dev workspace binding is explicitly configured as read-only rather than relying only on SELECT privileges.

[Nagendra_B]

Yes, we can share prod data into a dev workspace in Unity Catalog with read-only access. Databricks has built this to be remarkably simple without lengthy processes.

The only prerequisites are that both workspaces must be in the same region and attached to the same Unity Catalog metastore. Unity Catalog provides a built-in feature called Workspace-Catalog Binding that handles this.

To set it up, go to Catalog Explorer, select your prod catalog, click the Workspaces tab, set the isolation mode to Isolated, then add your dev workspace with the binding type set to Read Only. You can do this at the catalog, schema, or table level for granular control. Once shared, you grant only USE CATALOG, USE SCHEMA, and SELECT privileges to your dev team through Unity Catalog grants. This gives two layers of protection — the read-only binding blocks all writes from dev at the infrastructure level, even if someone is accidentally over-privileged. No complex networking, no data duplication, no ETL — just a few clicks and your dev team has safe read-only access to production data.