Skip to main content

Multi-tenant setup

You'll understand the multi-tenant deployment model and when it fits your organization in ~3 min.

Prereqs: Cloud Tenant ready

Why this matters​

When an organization already operates multiple cloud accounts — by environment, by business unit, or by regulation — Databricks must deploy into each one separately. Getting the layout wrong means cross-account networking headaches, duplicated configuration, or audit gaps.

Mental model​

Multiple cloud accounts, each with its own Databricks workspace(s) and backing cloud resources. Each account has an independent IAM boundary, storage, and network. Unity Catalog can still govern data across accounts, but the cloud infrastructure is fully separated.

Multi-tenant architecture: workspaces across separate cloud accounts

How it works​

Organization context​

This model applies when:

  • Your organization has multiple cloud accounts (e.g., separate Azure subscriptions for dev, staging, and prod).
  • You need hard isolation of Databricks and cloud resources between environments.
  • Each environment's data must reside in its own storage location.

Deployment layout​

For each cloud account, create a Databricks workspace and the required cloud resources (IAM roles, storage, networking) independently. A typical setup:

Cloud accountWorkspacePurpose
Dev accountDevelopment workspaceEngineering iteration and testing
Staging accountStaging workspaceIntegration testing and UAT
Prod accountProduction workspaceStable workloads serving the business

Each workspace operates within the IAM and network boundary of its cloud account. Unity Catalog metastores can span accounts within the same Databricks account, so governance remains centralized even when infrastructure is split.

When to use / when not to​

Use multi-tenant when:

  • Your organization already maintains separate cloud accounts per environment or division.
  • Compliance or security policies require account-level IAM and network isolation.
  • You need separate cloud billing per environment.
  • Blast-radius control is a hard requirement — a failure in one account must not affect another.

Stay single-tenant instead when:

  • You have one cloud account and no plans to split.
  • Your isolation requirements are met by workspace boundaries and Unity Catalog grants.

Common pitfalls​

Forgetting centralized governance​

Splitting cloud accounts does not mean splitting Databricks governance. All workspaces should still connect to the same Databricks account and use Unity Catalog for centralized permissions and lineage. Without this, each account becomes a governance silo.

Duplicating configuration without automation​

Manual setup across three or more cloud accounts drifts fast. Use Terraform or another IaC tool from the start. Drift between environments is one of the most common causes of "works in dev, breaks in prod."

Over-splitting by team​

Multi-tenant means splitting by environment or hard compliance boundary — not by team. Creating a separate cloud account per team adds massive overhead for a problem that Unity Catalog grants solve.

Next​