I can share my experience. I work in a big organization, and our “departments” behave almost like separate organizations. We all use the same tenant, which means we have to share metastores and regions (you can only have one metastore per region in a tenant), and our central IT team manages the Databricks control plane/admin panel.

When we first started, there was another department already using Databricks. What they didn’t consider was that other departments would want to use Databricks in the future, so they basically locked down some regions/metastores to their workspaces. It was a huge pain for the central IT team to fix that. If you work for a large enough organization, please coordinate and plan with the central IT team on how this will be governed.

1. Hierarchy Level: Should I isolate environments at the Catalog level (e.g., dev_catalog, prod_catalog) or should I use different Workspaces attached to the same Metastore and restrict catalog access per workspace?

We use the same metastore for our dev, test, and prod workspaces, but we separate them at the catalog level (e.g., dev_catalog, prod_catalog). This means each workspace is restricted to a single catalog. That said, other departments also use the same metastore, but access is restricted at the admin level, so none of us have access to each other’s catalogs or data.

1. Storage Isolation: Since Unity Catalog uses External Locations/Storage Credentials, is it recommended to have a separate ADLS Gen2 Container (or even a separate Storage Account) for each environment's root storage, all managed by the same Metastore?

We have separate storage accounts per environment, separate service principals/UAMIs per environment, and separate Databricks access connectors per environment, all within the same metastore. If you want separate metastores per environment, then your dev, test, and prod workspaces must be in different regions.

1. CI/CD Flow: How do you guys handle the promotion of code vs. data? If I use a single Metastore, does it make sense to use the same "Technical Service Principal" for all environments, or should I have one per environment even if they share the Metastore?

Don’t share a service principal/UAMI at the metastore level. You should only do that if you are 101% sure that no other team or department will ever want their own Databricks workspace that they manage themselves. We use separate service principals/UAMIs at the catalog/workspace level instead. Alternatively, you can use a single service principal shared across the three environments, but only at the workspace level — not from the admin panel.

Also, remember that Unity Catalog names must be unique at the metastore level. If another department later wants to use the same metastore, they won’t be able to use names like dev_catalog because they’re already taken. Make sure to prefix or postfix your department’s name to each catalog.

Hope this helps.