SaaS Workspace Models

View full diagram →

When building a Partner Hosted SaaS product on Databricks, the workspace topology decision—dedicated workspace per customer versus shared multi-tenant workspace—affects security isolation, scale characteristics, cost attribution, and operational complexity.

This page outlines the key factors to consider when selecting a workspace tenancy model, including product complexity, scale requirements, governance patterns, and operational trade-offs.

Reference implementation: See how Firefly manages hybrid workspace tenancy.

What is a Databricks Workspace?

A workspace is a Databricks deployment in a cloud service account. It provides a unified environment for working with Databricks assets—notebooks, clusters, jobs, data, and Unity Catalog objects—for a specified set of users.

Databricks offers two workspace types:

• Serverless workspaces — Pre-configured with serverless compute and default storage. See best practices for serverless workspaces.
• Classic workspaces — Provisions storage and compute resources in your cloud account, with optional serverless compute. See create a classic workspace.

Workspaces serve as the primary boundary for access control, resource management, and operational isolation in Databricks. For Partner Hosted SaaS architectures, the workspace model determines whether customers share infrastructure (multi-tenant workspace) or receive dedicated isolation (workspace per tenant).

Workspace Tenancy Models

There are two primary approaches to structuring workspace tenancy for SaaS products:

Workspace per Tenant

Each customer receives their own dedicated Databricks workspace. This model provides strong isolation boundaries at the workspace level.

Characteristics:

• One workspace provisioned per customer
• Customer-specific catalogs and schemas within each workspace
• Common catalog for shared assets (reference tables, models, functions, volumes, connections) accessible across all customer workspaces
• Dedicated compute resources by default (can be shared if needed)
• Workspace-level tagging for cost attribution
• Supports Customer Managed Keys (CMK) for data encryption
• Natural isolation for compliance and security requirements

Best for: Enterprise customers, BYOD scenarios, customers requiring dedicated infrastructure, compliance-heavy industries

Multi-Tenant Workspace

Multiple customers share a single Databricks workspace, with isolation enforced through Unity Catalog governance (schema per tenant or row-level security).

Characteristics:

• Single workspace serves many customers
• Catalog with multiple schemas (one per customer) OR single schema with row-level filters
• Common catalog for shared assets (reference tables, models, functions, volumes, connections) accessible to all tenants
• Shared or dedicated compute resources
• Compute-level tagging required for granular cost attribution
• More efficient resource utilization
• Lower operational overhead for high-volume, low-complexity customers

Best for: High-volume SaaS products, subscription-based pricing models, customers with simpler data requirements

Tenancy Consideration Factors

Application Functionality

The complexity and functionality of your SaaS offering is often the primary driver in workspace model selection:

Dimension	Multi-Tenant Workspace	Workspace per Tenant
Data access patterns	Read-only use cases are simpler	Authoring capabilities may benefit from dedicated workspaces
Data ownership	Serving partner data is straightforward	Bring-Your-Own-Data (BYOD) scenarios typically require per-customer
Analytical sophistication	SQL access or dashboards work well	Notebook authoring or ML may warrant dedicated workspaces
Customization	Standard configurations	Customer-specific pipelines or permissions easier with dedicated workspaces

Scale

Both models can scale effectively, but they have different upper bounds:

Model	Scale
Workspace per Tenant	Hundreds of customers
Multi-Tenant Workspace	Thousands of customers

Choose your model based on your expected customer count and growth trajectory. See Scale & Limits for detailed information on workspace-level, account-level, and cloud provider limits that may affect your architecture.

Bring Your Own Data (BYOD)

If your SaaS product requires customers to bring their own data, we recommend a workspace per customer:

• Customer Managed Keys are configured at the workspace level
• Data governance and access controls are simpler to implement with dedicated workspaces

Governance and Isolation

Governance is achievable in both models, but takes different approaches:

Approach	Description
Workspace-as-boundary	Provides low-risk governance by default. Each workspace has its own catalog mappings and workspace-level identities, making it easier to enforce per-customer permissions, lineage separation, and catalog visibility.
Governance-as-boundary	Requires fine-grained access control, column/row masking, and careful data isolation across catalogs and schemas.

Unity Catalog makes multi-workspace governance possible without duplication, allowing you to centralize governance while maintaining workspace-level boundaries.

Workspace-catalog binding provides a mechanism for controlling which catalogs are accessible from which workspaces.

Cost

Databricks does not charge for workspace deployment. Depending on your cloud provider and workspace type (classic versus serverless), there may be some cloud costs associated with networking, but these are typically nominal.

You can leverage economies of scale by placing multiple customers on shared compute resources, which can reduce overall infrastructure costs. However, this approach involves trade-offs in attribution complexity and isolation guarantees.

Attribution & Telemetry

Cost attribution and usage tracking differ at the level of granularity and simplicity:

Workspace per Tenant:

• Segregated compute by default
• Tag at the workspace level (simpler)
• Straightforward chargeback calculations
• All usage automatically attributed to the correct customer
• Ideal for partners with per-customer pricing models

Multi-Tenant Workspace:

• Can share compute across tenants (cost efficient)
• Requires compute-level tagging (more complex)
• Must tag clusters, warehouses, and jobs with customer identifiers
• Better for subscription models where granular attribution isn't needed
• Use System Tables for detailed usage tracking

For partners relying on chargeback or pay-per-use models, we recommend:

• Dedicated compute per customer (even in multi-tenant workspaces), OR
• Workspace per tenant for automatic attribution

Shared compute aligns well with subscription-based pricing where exact per-customer usage tracking is not required.

Note: Customer-level attribution is required to maximize GTM incentives in the Databricks Partner Program. Review the tagging guidance in the Partner Portal to understand specific requirements and eligible incentives.

Operational Overhead

Operational overhead is largely the same across both models when best practices are followed. The key principle is automation:

• All operational tasks should be automated regardless of workspace model
• Manual workspace maintenance is strongly discouraged in either approach
• Databricks provides full support for infrastructure-as-code tools including Terraform and Databricks Asset Bundles
• For programmatic workspace management, use the Databricks SDK or Account API

With proper automation in place, managing many per-customer workspaces should not be significantly more complex than managing a single multi-tenant workspace. In either case, automation should be incorporated as part of the design process.

Reliability

Workspaces act as natural failure and resource boundaries. In per-customer workspaces, one customer's workload cannot exhaust job service capacity or impact the performance of others. In shared workspaces, consider implementing cluster policies and resource quotas to manage contention and ensure consistent performance across customers.

Limits

Be aware that different limits apply at different levels of the Databricks architecture:

• Metastore level — Some limits, such as Unity Catalog limits, are enforced at the metastore level and apply across all workspaces.
• Workspace level — Other limits are enforced per workspace.

Review the resource limits for your expected usage patterns when selecting a workspace model.

Hybrid Tenancy Model

Many SaaS providers adopt a hybrid approach, where different customer tiers receive different workspace models based on their requirements. This allows you to optimize for both scale and isolation:

• Standard customers → Multi-tenant workspace with schema-per-tenant
• Enterprise customers → Dedicated workspaces for compliance, performance, or BYOD requirements

This hybrid approach allows you to:

• Start small with schema-per-tenant for most customers
• Scale selectively by moving high-value customers to dedicated workspaces
• Maintain data continuity during migration
• Optimize costs by only provisioning dedicated workspaces when needed

Summary

Factor	Multi-Tenant Workspace	Workspace per Tenant
Best for scale	Thousands of customers	Hundreds of customers
BYOD support	No	Yes
Customer Managed Keys	Not supported	Supported
Complexity	Lower for simple use cases	Better for complex requirements
Cost attribution	Compute level	Workspace level

Choose the model that best aligns with your product requirements, customer expectations, and operational capabilities. In many cases, a hybrid approach may be appropriate, where different customer tiers receive different workspace models based on their needs.

What's Next

• Governance — Unity Catalog patterns for multi-tenant and single-tenant deployments
• Cost Management — Tagging strategies for cost attribution
• Automation — Infrastructure as code for workspace provisioning