Databricks Legacy Sunset: DBFS, Hive Metastore & ihre Nachfolger

TL;DR: Seit 18. Dezember 2025 fehlen neuen Databricks-Accounts: DBFS-Root, Mounts, Hive Metastore und No-Isolation-Shared-Cluster. Existierende Accounts können die Features per "Disable Legacy Features"-Toggle entfernen. Migration: Volumes statt DBFS, Unity Catalog statt Hive, External Locations statt Mounts, Shared-Access-Mode statt No-Isolation.

Wenn du nach dem 18. Dezember 2025 einen neuen Databricks-Account angelegt hast, kennst du das schon: DBFS-Root, Mounts, Legacy-Hive-Metastore und No-Isolation-Shared-Cluster sind weg. Für alle anderen mit existierenden Workspaces tickt die Uhr — Databricks hat die "Disable legacy features"-Account-Einstellung ausgerollt und die Richtung ist klar. Dieser Guide deckt jedes deprecate Feature, seinen Nachfolger und die genauen Code-Änderungen ab.

Was sich am 18. Dezember 2025 änderte

Databricks hat in den Dezember-2025-Release-Notes angekündigt: alle neuen Accounts ab 18. Dezember 2025 haben keinen Zugriff mehr auf:

Für existierende Accounts können Workspace-Admins den "Disable Legacy Features"-Toggle in Account Settings → Feature Enablement umlegen und diese Features proaktiv entfernen. Empfohlener Weg — nicht warten, bis Databricks das für dich kippt.

Warum das jetzt zählt: Jede Pipeline, die noch /mnt/, dbfs:/ oder hive_metastore. referenziert, ist auf geliehener Zeit. Wenn Databricks das irgendwann account-übergreifend erzwingt, bricht alles, was nicht migriert ist.

DBFS-Root → Unity-Catalog-Volumes

DBFS-Root war der geteilte, ungemanagte Blob-Storage, in den jeder Workspace unter dbfs:/ schreiben konnte. Keine Access-Control jenseits von Workspace-Permissions, keine Lineage, keine Governance. Unity-Catalog-Volumes ersetzen ihn durch governed, namespace-aware File-Storage.

Deprecated: DBFS-Root-Access

# Writing files to DBFS root — NO LONGER WORKS on new accounts
dbutils.fs.put("/FileStore/config/pipeline_params.json", json.dumps(params))
df.write.format("parquet").save("dbfs:/output/daily_report/")

# Reading from DBFS root
raw = spark.read.parquet("dbfs:/raw_data/events/")

Neuer Standard: Unity-Catalog-Volumes

# Unity Catalog Volumes — governed, namespace-aware file storage
# Path pattern: /Volumes/<catalog>/<schema>/<volume>/<path>

# Writing files to a managed volume
dbutils.fs.put(
    "/Volumes/prod_catalog/analytics/config/pipeline_params.json",
    json.dumps(params)
)
df.write.format("parquet").save(
    "/Volumes/prod_catalog/analytics/output/daily_report/"
)

# Reading from a volume
raw = spark.read.parquet("/Volumes/prod_catalog/raw/events/")

-- Spark SQL: Create a managed volume
CREATE VOLUME IF NOT EXISTS prod_catalog.analytics.config
COMMENT 'Pipeline configuration files';

-- Create an external volume pointing to cloud storage
CREATE EXTERNAL VOLUME prod_catalog.raw.landing
LOCATION 's3://my-bucket/landing/'
COMMENT 'Raw landing zone from upstream systems';

Kernunterschiede: Volumes leben im Three-Level-Namespace (catalog.schema.volume), unterstützen feingranulare ACLs via Unity Catalog und werden in Lineage getrackt. External Volumes zeigen auf existierenden Cloud-Storage; Managed Volumes werden voll von Databricks gemanagt.

Hive Metastore → Unity Catalog

Der workspace-lokale Hive Metastore hatte keine Cross-Workspace-Sichtbarkeit, kein Row-/Column-Level-Security und keine Data-Lineage. Unity Catalog ist der Nachfolger — und seit 2023 GA. Es gibt keine Ausrede mehr.

Deprecated: Hive-Metastore-Tabellen

-- Spark SQL dialect
-- Tables registered in the legacy Hive Metastore
CREATE TABLE hive_metastore.default.events (
    event_id STRING,
    event_type STRING,
    event_ts TIMESTAMP,
    payload STRING
)
USING DELTA
LOCATION 's3://my-bucket/hive-tables/events/';

-- Querying without catalog prefix defaults to hive_metastore
SELECT * FROM default.events WHERE event_ts > '2025-01-01';

Neuer Standard: Unity-Catalog-Tabellen

-- Spark SQL dialect
-- Tables registered in Unity Catalog — three-level namespace
CREATE TABLE IF NOT EXISTS prod_catalog.events.raw_events (
    event_id STRING,
    event_type STRING,
    event_ts TIMESTAMP,
    payload STRING
)
USING DELTA
COMMENT 'Raw events from upstream ingestion'
TBLPROPERTIES ('quality' = 'bronze');

-- Always use the full three-level name
SELECT * FROM prod_catalog.events.raw_events
WHERE event_ts > '2025-01-01';

# PySpark: Migrating an existing Hive table to Unity Catalog
# Step 1: Read from old location
old_df = spark.table("hive_metastore.default.events")

# Step 2: Write to Unity Catalog as a managed table
old_df.write.mode("overwrite").saveAsTable("prod_catalog.events.raw_events")

# Step 3: Verify row counts match
old_count = spark.table("hive_metastore.default.events").count()
new_count = spark.table("prod_catalog.events.raw_events").count()
assert old_count == new_count, f"Row count mismatch: {old_count} vs {new_count}"

Für große Tabellen DEEP CLONE statt Full-Rewrite nutzen:

-- Spark SQL dialect
-- DEEP CLONE preserves Delta history and is more efficient for large tables
CREATE TABLE prod_catalog.events.raw_events
DEEP CLONE hive_metastore.default.events;

Schau auch in den Unity-Catalog-Best-Practices-Guide für Namespace-Design — ein häufiger Fehler ist, zu viele Catalogs anzulegen, statt Schemas für logische Trennung zu nutzen.

Mounts → External Locations + Storage Credentials

dbutils.fs.mount() war die Standardlösung, um Cloud-Storage an Databricks anzubinden. Credentials wurden auf Workspace-Ebene gespeichert, ohne Auditability. External Locations und Storage Credentials ersetzen das mit zentralisiertem, auditbarem Cloud-Access.

Deprecated: DBFS-Mounts

# Mounting an S3 bucket — credentials stored in workspace scope
dbutils.fs.mount(
    source="s3a://my-data-lake/raw/",
    mount_point="/mnt/raw_data",
    extra_configs={
        "fs.s3a.access.key": dbutils.secrets.get("aws", "access_key"),
        "fs.s3a.secret.key": dbutils.secrets.get("aws", "secret_key")
    }
)

# Reading from mount
df = spark.read.parquet("/mnt/raw_data/events/2025/")

Neuer Standard: External Locations

-- Spark SQL dialect
-- Step 1: Create a storage credential (done once by admin)
CREATE STORAGE CREDENTIAL IF NOT EXISTS aws_prod_cred
WITH (
    AWS_IAM_ROLE = 'arn:aws:iam::123456789:role/databricks-external-access'
)
COMMENT 'Production S3 access via IAM role';

-- Step 2: Create an external location using that credential
CREATE EXTERNAL LOCATION IF NOT EXISTS raw_landing
URL 's3://my-data-lake/raw/'
WITH (STORAGE CREDENTIAL aws_prod_cred)
COMMENT 'Raw data landing zone';

# Reading from external location — no mount needed
df = spark.read.parquet("s3://my-data-lake/raw/events/2025/")

# Or use an external volume for file-level access
df = spark.read.parquet("/Volumes/prod_catalog/raw/landing/events/2025/")

Vorteil: Storage Credentials nutzen IAM-Rollen (AWS) oder Managed Identities (Azure) statt rohe Keys. Zugriff ist über Unity-Catalog-Audit-Logs auditbar, und Permissions können auf Catalog-/Schema-/Tabellen-Ebene gegeben werden.

No-Isolation-Shared → Shared-Access-Mode mit Unity Catalog

No-Isolation-Shared-Cluster ließen den Code aller User im selben Prozess laufen, ohne Credential-Isolation. Ein Notebook von einem User konnte die Secrets eines anderen User lesen. Shared-Access-Mode-Cluster mit Unity Catalog fixen das mit Per-User-Credential-Isolation.

Migrations-Hinweis: Wenn deine Workflows von Custom-JARs oder unrestricted init-Scripts abhängen, musst du sie auf Single-User-Cluster verlegen. Shared-Access-Mode beschränkt das absichtlich für Security — das ist Zweck, kein Bug.

Time-Travel- und VACUUM-Änderungen in Runtime 18.0

Runtime 18.0 brachte eine subtile, aber wichtige Verhaltensänderung: die Default-Retention-Periode für VACUUM wird strikter erzwungen, und Time-Travel-Queries auf Tabellen mit aggressivem Vacuum-Schedule können failen, wo sie vorher klappten.

-- Spark SQL dialect
-- Check your current table retention settings
DESCRIBE DETAIL prod_catalog.events.raw_events;

-- Set explicit retention to avoid surprises
ALTER TABLE prod_catalog.events.raw_events
SET TBLPROPERTIES (
    'delta.logRetentionDuration' = 'interval 30 days',
    'delta.deletedFileRetentionDuration' = 'interval 7 days'
);

-- VACUUM with explicit retention — don't rely on defaults
VACUUM prod_catalog.events.raw_events RETAIN 168 HOURS;

Diese Änderung erstreckt sich auf Serverless-Compute ab Januar 2026. Wenn du VACUUM auf Serverless-SQL-Warehouses laufen lässt, teste deine Time-Travel-Queries nach dem Upgrade — alles, was sich auf das vorherige Default-Verhalten verließ, kann still brechen.

Migrations-Checkliste

Schritt-für-Schritt für Teams, die von Legacy-Features wegmigrieren. In dieser Reihenfolge arbeiten — spätere Schritte hängen von früheren ab.

Phase 1: Audit (Woche 1)

• dbutils.fs.ls("dbfs:/") laufen lassen und alles auf DBFS-Root katalogisieren
• Alle Notebooks und Repos nach /mnt/, dbfs:/, hive_metastore. durchsuchen
• Alle existierenden Mounts listen: dbutils.fs.mounts()
• Alle Hive-Metastore-Databases inventarisieren: SHOW DATABASES IN hive_metastore
• Cluster identifizieren, die im No-Isolation-Shared-Modus laufen
• Alle init-Scripts und Custom-JARs auf Shared-Cluster dokumentieren

Phase 2: Unity Catalog aufsetzen (Woche 2)

• Sicherstellen, dass Unity Catalog auf Account-Ebene aktiviert ist
• Catalog/Schema-Namespace designen (siehe UC-Best-Practices)
• Storage Credentials für jeden Cloud-Storage-Account anlegen
• External Locations für alle Mount-Targets anlegen
• Volumes für File-basierte Workflows (Configs, Uploads, Exports) anlegen

Phase 3: Daten migrieren (Woche 3–4)

• DEEP CLONE aller Hive-Metastore-Tabellen nach Unity Catalog
• Row-Counts und Schema-Parität für jede migrierte Tabelle prüfen
• DBFS-Root-Files in Volumes verschieben
• Alle Notebook-Pfade von /mnt/ und dbfs:/ auf Volume-Pfade oder direkte Cloud-URLs aktualisieren
• Alle SQL-Referenzen von hive_metastore.db.table auf catalog.schema.table umstellen

Phase 4: Cutover (Woche 5)

• Shared-Cluster von No-Isolation auf Shared-Access-Mode umstellen
• ML-Workloads mit Custom-JARs auf Single-User-Cluster verlegen
• Integrations-Tests auf allen migrierten Pipelines laufen lassen
• "Disable Legacy Features"-Toggle in Account-Settings umlegen
• 1 Woche monitoren, dann alte Mounts unmounten und DBFS-Root-Daten archivieren

Was 2026 kommt

Die Databricks-Roadmap signalisiert mehrere kommende Änderungen, die zu tracken sind:

• Governed Tags GA — Tag-basierte Policies für Column-Level-Security über Catalogs hinweg, von Public Preview zu General Availability
• Sample Data Explorer GA — Eingebaute Sample-Datasets für Unity Catalog, ersetzt den alten databricks-datasets-DBFS-Pfad
• Delta-Sharing-URL-Änderungen — Share-URLs bekommen ein neues Format; existierende Integrationen brauchen Updates
• Serverless-VACUUM-Enforcement — Die Runtime-18.0-VACUUM-Verhaltensänderungen wirken voll auf Serverless-Compute ab Januar 2026
• Anhaltender Deprecation-Druck — Erwarte, dass Databricks Legacy-Features irgendwann auf allen Accounts zwangs-deaktiviert, ähnlich wie beim DBR-13.x-End-of-Support

Das Muster ist klar: Unity Catalog ist der einzige Weg nach vorne. Jedes Quartal wächst die Lücke zwischen Legacy und UC-native, und die Migrations-Kosten steigen. Wer noch Hive-Metastore-Tabellen in Produktion fährt: der beste Zeitpunkt zur Migration war vor sechs Monaten. Der zweitbeste ist jetzt.

Wer migrierte Datasets schnell explorieren und validieren will, kann Harbinger Explorer nutzen — Klartext-Queries gegen CSV-Exports und hochgeladene Files direkt im Browser. Nützlich für Spot-Checks auf Row-Counts und Schema-Änderungen während der Migration, ohne Cluster hochzufahren.

FAQ

Bis wann muss ich migriert haben?

Für neue Accounts: schon passiert. Für existierende Accounts: keine harte Deadline, aber Databricks signalisiert klar, dass die Features verschwinden. Realistisch: 2026 für die Migration einplanen, spätestens Q1 2027.

Was passiert mit existierenden /mnt/-Pfaden in produktiven Pipelines?

Solange "Disable Legacy Features" nicht aktiviert ist, läufts. Sobald aktiv: /mnt/-Pfade werfen Errors. Daher: vorher alle Pfade umstellen, dann erst Toggle umlegen.

Wie behandle ich DSGVO-relevante Daten in der Migration?

DEEP CLONE behält Delta-Historie, aber wenn DSGVO-Lösch-Anfragen vor der Migration verarbeitet wurden, sicherstellen, dass die History nicht versehentlich rekonstruiert wird. Im Zweifel: nach Migration VACUUM mit kurzer Retention auf migrierten Tabellen.

Was kostet die Migration realistisch?

Für ein Team mit 50–100 produktiven Tabellen: 4–6 Wochen Engineering-Aufwand, plus Test-Zyklus. Größere Setups (1000+ Tabellen): 3–6 Monate.

Gibt es ein Migrations-Tool von Databricks?

Ja: Databricks hat UCX (Unity Catalog Migration Assistant) als OSS-Tool veröffentlicht. Es automatisiert Audit, Inventory und Teil der Daten-Migration.

Starte mit dem Audit. SHOW DATABASES IN hive_metastore laufen lassen, Mounts zählen und Repos nach dbfs:/ greppen. Das ist dein Migrations-Scope — und von da an ist es Execution.

Stand: 14. Mai 2026.