Databricks SQL Warehouse: Sizing- und Cost-Optimization-Guide

TL;DR: Für 2026: Serverless als Default, Auto-Stop aggressiv (5–30 min), Workloads in getrennte Warehouses (Dev/BI/dbt/Sandbox) trennen, system.billing.usage wöchentlich monitoren. Teams, die das richtig machen, sparen 40–70 % auf SQL-Compute gegenüber "sicherheitshalber größer".

Databricks SQL Warehouses sind die Compute-Schicht hinter Databricks SQL — sie powern BI-Dashboards, Ad-hoc-Queries und dbt-Transformationen. Aber DBU-Kosten summieren sich schnell, und falsches Sizing ist einer der häufigsten Wege, die Datenplattform zu über- oder unterzubauen.

Dieser Guide deckt alles ab, was du für fundierte SQL-Warehouse-Entscheidungen brauchst: Typen, Sizing, Auto-Stop-Tuning und konkrete Cost-Taktiken.

SQL-Warehouse-Typen

Databricks bietet drei SQL-Warehouse-Typen:

Serverless SQL Warehouses sind die Default-Empfehlung für neue Deployments in 2026. Sie starten in Sekunden (kein Cluster-Bootstrap), skalieren bei Idle sofort auf null und werden nur für Query-Execution-Zeit berechnet — nicht für Idle-Zeit.

# Create a serverless SQL warehouse via CLI
databricks warehouses create   --name "analytics-serverless"   --warehouse-type STARTER   --cluster-size "Small"   --auto-stop-mins 5   --enable-serverless-compute true

T-Shirt-Sizing-Referenz

SQL-Warehouses nutzen T-Shirt-Größen, die auf DBU-Verbrauch mappen:

Hinweis: Bei Serverless ist die DBU-Rate typisch 1,4–1,6× Classic, aber du eliminierst Idle-Kosten — oft niedrigerer Total-Spend.

Cluster (Scaling innerhalb eines Warehouses)

Jedes SQL-Warehouse kann mehrere Cluster für parallele Queries fahren. Ein Cluster handelt rund 10 parallele Queries effizient.

# Configure via Python SDK
from databricks.sdk import WorkspaceClient
from databricks.sdk.service.sql import CreateWarehouseRequest, WarehouseTypePair

w = WorkspaceClient()

warehouse = w.warehouses.create(
    name="production-bi",
    cluster_size="Medium",
    min_num_clusters=1,
    max_num_clusters=5,       # Auto-scales up to 5 clusters
    auto_stop_mins=30,
    enable_serverless_compute=True,
    warehouse_type=WarehouseTypePair(warehouse_type="PRO"),
)
print(f"Created warehouse: {warehouse.id}")

Skalierungs-Regeln:

• min_num_clusters=1: hält einen Cluster immer warm (kein Cold-Start für die erste Query)
• max_num_clusters=N: Concurrency-Decke
• Auto-Scale ergänzt Cluster, wenn Queue-Tiefe einen Threshold überschreitet (~2 Queries warten)

Auto-Stop-Konfiguration: Der größte Cost-Hebel

Auto-Stop ist die einflussreichste Cost-Kontrolle für SQL-Warehouses. Ein idle Warehouse, das die ganze Nacht läuft, kostet gleich viel wie ein busy.

# Set auto-stop to 5 minutes for development warehouses
databricks warehouses update   --id <warehouse-id>   --auto-stop-mins 5

# 30 minutes for production BI (balance cost vs cold start for morning rush)
databricks warehouses update   --id <warehouse-id>   --auto-stop-mins 30

# Query current warehouse settings
databricks warehouses get --id <warehouse-id>

Auto-Stop-Strategie nach Use-Case:

Query-Routing und Warehouse-Zuweisung

Verschiedene Workload-Typen auf passend dimensionierte Warehouses mappen:

-- Query profiles to understand your workload mix
SELECT
  warehouse_id,
  COUNT(*) AS query_count,
  AVG(duration) / 1000 AS avg_duration_sec,
  PERCENTILE(duration, 0.95) / 1000 AS p95_duration_sec,
  SUM(metrics.total_time_ms) / 1000 / 3600 AS total_compute_hours
FROM system.query.history
WHERE start_time >= NOW() - INTERVAL 30 DAYS
GROUP BY warehouse_id
ORDER BY total_compute_hours DESC;

Empfohlene Warehouse-Architektur:

Produktive BI-Dashboard-Warehouse
  Größe: Medium, Min: 1, Max: 4, Stop: 30 min
  User: Tableau, Power BI, Metabase

Analytics-/Ad-hoc-Warehouse
  Größe: Small (Serverless), Max: 3, Stop: 10 min
  User: Data-Analysten, SQL-Notebooks

dbt-Produktions-Warehouse
  Größe: Large, Min: 0, Max: 1, Stop: 10 min
  User: dbt Cloud / dbt Core CI/CD

Developer-/Sandbox-Warehouse
  Größe: 2X-Small, Min: 0, Max: 1, Stop: 5 min
  User: Engineers beim Query-Testing

Cost-Monitoring via system.billing

Databricks legt Billing-Daten in der system.billing.usage-Tabelle offen:

-- SQL Warehouse cost breakdown by warehouse (last 30 days)
SELECT
  u.usage_metadata.warehouse_id AS warehouse_id,
  w.name AS warehouse_name,
  SUM(u.usage_quantity) AS total_dbus,
  SUM(u.usage_quantity) * 0.22 AS estimated_cost_usd  -- adjust for your DBU rate
FROM system.billing.usage u
LEFT JOIN system.compute.warehouses w
  ON u.usage_metadata.warehouse_id = w.warehouse_id
WHERE u.usage_date >= CURRENT_DATE - INTERVAL 30 DAYS
  AND u.sku_name LIKE '%SQL%'
GROUP BY 1, 2
ORDER BY total_dbus DESC;

-- Identify wasteful idle compute (warehouses running with zero queries)
SELECT
  date_trunc('hour', period_start) AS hour,
  warehouse_id,
  SUM(dbus) AS idle_dbus
FROM system.billing.warehouse_events
WHERE event_type = 'IDLE'
  AND period_start >= CURRENT_DATE - INTERVAL 7 DAYS
GROUP BY 1, 2
HAVING idle_dbus > 1
ORDER BY idle_dbus DESC;

Query-Level-Cost-Attribution

Für Chargeback-Modelle Kosten auf User oder Teams zurückverfolgen:

-- Cost per user for the last 30 days
SELECT
  user_name,
  COUNT(*) AS query_count,
  SUM(metrics.total_time_ms) / 1000 / 3600 AS compute_hours,
  ROUND(SUM(metrics.total_time_ms) / 1000 / 3600 * 0.22, 2) AS est_cost_usd
FROM system.query.history
WHERE start_time >= NOW() - INTERVAL 30 DAYS
  AND status = 'FINISHED'
GROUP BY user_name
ORDER BY est_cost_usd DESC
LIMIT 20;

Performance-Optimierung für SQL-Warehouses

1. Result-Caching

SQL-Warehouses cachen identische Query-Resultate für bis zu 24 Stunden. Nutze das:

-- This query hits cache on second execution (same SQL, same data)
SELECT country, SUM(revenue) FROM prod.gold.sales GROUP BY country;

-- Force cache bypass (for testing)
SELECT /*+ NO_CACHE */ country, SUM(revenue) FROM prod.gold.sales GROUP BY country;

2. Query-Optimierung

-- Use EXPLAIN COST to understand query plans
EXPLAIN COST
SELECT
  c.customer_name,
  SUM(o.amount) AS total_spend
FROM prod.gold.orders o
JOIN prod.gold.customers c ON o.customer_id = c.customer_id
WHERE o.order_date >= '2024-01-01'
GROUP BY c.customer_name
ORDER BY total_spend DESC
LIMIT 100;

3. Materialized Views und Dashboards

Für Dashboards, die dieselben teuren Aggregationen wiederholt fahren:

-- Create a materialized summary (refresh daily)
CREATE OR REPLACE TABLE prod.gold.daily_revenue_summary AS
SELECT
  date_trunc('day', order_date) AS day,
  product_category,
  region,
  SUM(amount) AS revenue,
  COUNT(*) AS order_count
FROM prod.gold.orders
GROUP BY 1, 2, 3;

-- Dashboard queries hit the summary instead of raw table
-- 1M row aggregation -> 365 row lookup

Serverless vs Pro: Total-Cost-Vergleich

Realistisches Szenario: 4 Analysten, 50 Queries/Tag, je 30 s im Schnitt, 8 Geschäftsstunden:

Serverless spart ~93 % in diesem Szenario. Break-Even, wo Classic/Pro gewinnt: Warehouses mit > 60 % Tagesauslastung unter Load.

Databricks SQL + Harbinger Explorer

Teams, die Harbinger Explorer nutzen, können direkt an ihre SQL-Warehouses anbinden, um Exploration-Queries gegen externe API-Datasets zu fahren — ohne separate ETL-Pipeline. Harbingers API-Crawler kann strukturierte Resultate direkt in Delta-Tabellen pushen, abfragbar von deinem SQL-Warehouse.

-- After Harbinger ingests external data to your Delta table:
SELECT
  h.event_country,
  h.event_type,
  COUNT(*) AS event_count,
  SUM(s.revenue_impact) AS revenue_impact
FROM harbinger.geopolitical.events h
JOIN prod.gold.sales s ON h.event_country = s.ship_to_country
  AND h.event_date = s.sale_date
WHERE h.event_date >= '2024-01-01'
GROUP BY 1, 2
ORDER BY revenue_impact DESC;

Checkliste: Cost-optimiertes SQL-Warehouse-Setup

• Serverless für bursty/unvorhersehbare Workloads
• Auto-Stop ≤ 10 min für Dev-Warehouses
• Auto-Stop ≤ 30 min für produktive BI
• Dev/Analytics/Produktion in getrennten Warehouses
• Result-Caching aktiviert (Default, nicht deaktivieren)
• system.billing.usage wöchentlich monitoren
• Auf die kleinste Warehouse-Größe right-sizen, die deine P95-Query-Latenz-SLA erfüllt
• Materialisierte Tabellen für teure wiederkehrende Aggregate
• Warehouses für Cost-Attribution taggen (team, environment, owner)

FAQ

Sollte ich für jedes Team ein eigenes Warehouse haben?

Pro Workload-Typ ja (BI, dbt, Sandbox), pro Team meist nein. Workload-Separation verhindert Noisy-Neighbor; Team-Separation lohnt nur bei strikten Chargeback-Modellen.

Wie sieht das DSGVO-Setup aus?

Warehouses in EU-Region (Frankfurt, West Europe), Unity Catalog für Audit-Logs, Query-History via System-Tables 1+ Jahr aufbewahren.

Was, wenn ich Cold-Start gar nicht aushalte?

min_num_clusters=1 setzen — ein Cluster bleibt warm. Kostet die Idle-Zeit, eliminiert aber Cold-Start. Für SLA-kritische Dashboards der richtige Hebel.

Ist Serverless wirklich immer billiger?

Nein. Break-Even bei > 60 % täglicher Auslastung mit hoher Concurrency. Für Always-on-API-Backends ist Pro oft günstiger.

Wie messe ich den richtigen Warehouse-Größenwert?

P95-Query-Latenz als SLA setzen, dann downsizen, bis SLA verletzt wird. Die kleinste Größe, die SLA erfüllt, ist optimal.

Schluss

SQL-Warehouse-Cost-Optimization geht primär darum, Supply an Demand anzupassen: richtig dimensionierte Compute, aggressiver Auto-Stop für Dev, Serverless für alles mit unvorhersehbarer Last. Mit Serverless starten, außer du hast einen spezifischen Grund für Pro. system.billing.usage und system.query.history wöchentlich monitoren, um Runaway-Kosten früh zu fangen.

Teams, die das richtig machen, sparen 40–70 % auf SQL-Compute gegenüber denen, die "sicherheitshalber größer" sizen und Auto-Stop vergessen.

Stand: 14. Mai 2026.