Choosing Databricks Compute Access Modes: Single User / Shared / No Isolation

When you create a Databricks cluster (Compute), the very first decision you have to make is the Access Mode. Access Mode determines the cluster's isolation level and Unity Catalog support, and it cannot be changed once the cluster has started. The wrong choice ends up producing "an ML project cluster that can't see Unity Catalog tables" or "a shared cluster that fails security audits", so both administrators and developers need a solid understanding of this topic.

This article lays out the technical differences between the three Access Modes (Single User / Shared / No Isolation Shared) in a comparison table, walks through the recommended configuration for Unity Catalog environments, explains how to choose between job clusters and interactive clusters, and covers the patterns that show up on Databricks certification exams.

The Three Access Modes at a Glance

Databricks clusters come in three Access Modes. Each mode provides a different level of process isolation, with its own set of available features and restrictions.

• Single User Mode: A single user or one Service Principal has exclusive use of the cluster. Has the fewest restrictions and supports every Databricks feature. Unity Catalog-compatible.
• Shared Mode: Multiple users share the same cluster. Process-level isolation keeps each user's code separate from the others. Unity Catalog-compatible, but with some feature restrictions.
• No Isolation Shared Mode: Multiple users run code inside the same process space. No isolation. Not Unity Catalog-compatible. Not recommended for new environments.

Side-by-Side Comparison of the Three Modes

Single User Mode in Detail

When you create a Single User Mode cluster you specify exactly one assigned user, and only that user can use the cluster. Any other user who tries to attach to it will hit an error.

Because the cluster is used exclusively, no process isolation is needed, and every Databricks feature is available without restriction — RDD API, custom JAR libraries, init scripts, and the ML Runtime (including GPU). For Unity Catalog environments, Single User Mode is the most strongly recommended option.

The cost trade-off with Single User Mode is that you can't share a cluster. If a team of 10 works simultaneously and each person spins up their own Single User cluster, you end up with 10 clusters. You can mitigate this by using cluster policies to constrain instance types and auto-termination times, and by leveraging Serverless Compute.

Shared Mode: Details and Restrictions

Shared Mode lets multiple users share a single cluster while process-level isolation keeps things safe. It's Unity Catalog-compatible, making it a good fit for cost-conscious interactive workloads.

However, the cost of that process isolation is the following set of feature restrictions:

• No RDD API: DataFrame API only. Legacy RDD code can't be executed.
• No ML Runtime: ML clusters that need libraries like mlflow.pyfunc or distributed training must run on Single User Mode.
• Init script restrictions: Cluster-scoped init scripts are not available. Only admin-configured global init scripts are allowed.
• Custom library restrictions: Cluster-level library installation is not allowed. Use %pip install inside a notebook instead.
• Spark Config restrictions: Spark configurations that affect security can't be freely changed.

Shared Mode is a good fit for SQL-analyst-centric teams and for cost-first lightweight exploratory analysis. If you need machine learning or RDD-based processing, choose Single User Mode.

No Isolation Shared Mode (Deprecated)

In No Isolation Shared Mode, every user's code runs inside the same JVM process, so there is no data isolation between users. One user's Python code can potentially reach into another user's variable space or read credentials set as environment variables.

Unity Catalog enforces fine-grained access control (per-table GRANT/REVOKE), but No Isolation Mode has no process-level isolation, so Unity Catalog's permission boundaries cannot be preserved. As a result the mode is not Unity Catalog-compatible, and Databricks does not recommend it for new environments.

If you're still running No Isolation Shared Mode clusters, the recommended migration paths are:

• ML workloads → migrate to Single User Mode + ML Runtime
• SQL and lightweight analytics → migrate to Shared Mode
• RDD code → use Single User Mode and consider rewriting to the DataFrame API

Choosing Modes for Job Clusters vs Interactive Clusters

Best Practices for Unity Catalog Environments

Once Unity Catalog is enabled, your Access Mode choices become the foundation of data governance. The following design principles are recommended:

• Default to Single User Mode: Use a Cluster Policy to pin new clusters to Single User Mode so users can't accidentally create a No Isolation cluster.
• Use Shared Mode selectively: Assign a Shared Mode policy only to groups that don't need RDD or ML, such as SQL analyst teams.
• Block new No Isolation Shared Mode clusters: Set access_mode to a fixed value in the Cluster Policy to remove No Isolation from the available options.
• Use Service Principal + Single User for job clusters: Assign a Service Principal — not a human user — to the cluster, and run production jobs with least privilege.

# Cluster PolicyでAccess Modeを制限する定義例
{
  "spark_conf.spark.databricks.cluster.profile": {
    "type": "fixed",
    "value": "singleNode",
    "hidden": true
  },
  "access_mode": {
    "type": "allowlist",
    "values": ["SINGLE_USER", "USER_ISOLATION"],
    "defaultValue": "SINGLE_USER"
  }
}

What the Exam Tests

Access Modes show up in the Data Engineer Associate and Platform Administration domains. Make sure you have these patterns down:

• "Which Access Mode is required to access Unity Catalog tables?" → Single User or Shared (No Isolation is not allowed)
• "Which Access Mode is required to use the ML Runtime?" → Single User Mode only
• "Which Access Modes can use the RDD API?" → Single User or No Isolation Shared (not Shared)
• "Which mode lets multiple users share a cluster safely?" → Shared Mode (with process isolation)
• "Can a cluster's Access Mode be changed after it starts?" → No. You have to create a new cluster.

Check Your Understanding

Frequently Asked Questions