DBFS vs Volumes: Differences and Migration Guide — 5-Axis Comparison, SQL, and Deprecation Timeline

When you handle non-table files (CSV, JSON, images, config files, and so on) in Databricks, DBFS (Databricks File System) was the traditional choice. Since Unity Catalog arrived, however, Volumes are the new recommended standard. This article compares DBFS and Volumes across 5 axes and walks through the concrete steps to migrate from existing DBFS usage to Volumes.

DBFS (Databricks File System) Overview

DBFS is a filesystem abstraction layer built into the Databricks workspace. It mounts cloud storage (S3 / ADLS / GCS) under dbfs:/ paths and lets you access it as if it were a local filesystem.

• DBFS Root: the default storage automatically provisioned when a workspace is created
• DBFS Mount: mount external cloud storage under dbfs:/mnt/...
• Path format: dbfs:/mnt/data/sales.csv or /dbfs/mnt/data/sales.csv

DBFS's biggest problem is the lack of governance. Because DBFS is managed by workspace ACLs, Unity Catalog permissions (GRANT/REVOKE) do not apply, and detailed auditing of who accessed which file is difficult.

Volumes Overview

Volumes are file storage that lives in the Unity Catalog namespace. Files are addressed under /Volumes/<catalog>/<schema>/<volume>/, and Unity Catalog's permission control, auditing, and lineage all apply to those files.

• Managed Volume: UC manages the storage lifecycle (data is deleted on DROP)
• External Volume: references an existing cloud storage path (only metadata is removed on DROP)
• Path format: /Volumes/prod/raw/landing/sales.csv

5-Axis Comparison Table

Specific DBFS Limitations

• Cannot share files across workspaces
• Mount credentials are tied to the workspace, so every mount must be reconfigured when credentials are rotated
• Data written to DBFS Root is hard to manage with user-controlled encryption keys
• File operations are not reflected in Unity Catalog lineage
• All users accessing the same mount get the same permissions, making least-privilege hard to enforce

Migration Steps

Step 1: Inventory current DBFS usage

# List all DBFS mounts
mounts = dbutils.fs.mounts()
for m in mounts:
    print(f"Mount: {m.mountPoint} → {m.source}")

# List files in DBFS Root
files = dbutils.fs.ls("dbfs:/")
for f in files:
    print(f.name, f.size, f.isDir())

Step 2: Create the destination Volume

-- Register an existing S3 path as an External Volume (no data copy needed)
CREATE EXTERNAL VOLUME prod.raw.legacy_mount
LOCATION 's3://my-legacy-bucket/data/'
COMMENT 'External Volume migrated from a DBFS mount';

-- Create a Managed Volume for new files
CREATE VOLUME prod.raw.new_landing
COMMENT 'Managed Volume for the new pipeline';

Step 3: Copy files (for a Managed Volume)

# Copy files from DBFS to Volumes
dbutils.fs.cp(
    "dbfs:/mnt/old-landing/sales/",
    "/Volumes/prod/raw/new_landing/sales/",
    recurse=True
)

# Verify the copy
files = dbutils.fs.ls("/Volumes/prod/raw/new_landing/sales/")
print(f"Copied {len(files)} files")

Step 4: Rewrite the pipeline paths

# Before: DBFS path
df = spark.read.csv("dbfs:/mnt/old-landing/sales/2026/*.csv")

# After: Volumes path
df = spark.read.csv("/Volumes/prod/raw/new_landing/sales/2026/*.csv")

Step 5: Set permissions

-- Read permission
GRANT READ VOLUME ON VOLUME prod.raw.new_landing TO `data-analysts`;

-- Write permission
GRANT WRITE VOLUME ON VOLUME prod.raw.new_landing TO `data-engineers`;

Step 6: Unmount the DBFS mount

# Unmount once migration is complete
dbutils.fs.unmount("/mnt/old-landing")

Phased Deprecation of Legacy DBFS

Since 2024, Databricks has been moving toward restricting default access to DBFS Root. In a growing number of new workspaces, DBFS Root writes are disabled by default.

• DBFS Root write restriction: disabled by default in new workspaces (admins can enable it)
• Mounts are being deprecated: migration to External Volume or External Location is recommended
• Future removal of dbutils.fs.mount(): no exact retirement date is set, but planning the migration is recommended

What the Exam Asks About

• The difference between DBFS and Volumes path formats
• Why Volumes is recommended over DBFS (governance, auditing, cross-workspace access)
• That External Volume can replace a DBFS mount
• That UC permissions do not apply to DBFS Root
• The dbutils.fs.cp procedure for copying files during migration

Sample Question

Frequently Asked Questions