Inhaltsverzeichnis17 Abschnitte
- TL;DR
- Die Pricing-Modelle (kompakt)
- Databricks DBU
- Snowflake Credits
- BigQuery
- Die Beispiel-Workload
- Kostenrechnung Monat (Profil A — BI-Heavy)
- Kostenrechnung Monat (Profil B — Engineering-Heavy)
- Kostenrechnung Monat (Profil C — Sporadic)
- Wo der Vergleich kippt
- "Aber die ETL-Jobs in Databricks sind günstiger"
- "BigQuery skaliert magisch"
- "Snowflake ist teuer, weil Credits teuer sind"
- Operationale Realität
- DACH-/EU-Spezifika
- Faustregeln zum Mitnehmen
- Quellen
Drei große Daten-Plattformen, drei radikal unterschiedliche Pricing-Modelle, und ein gemeinsames Problem: niemand vergleicht sie ehrlich, weil das eigene CFO-relevante Vergleich-Sheet politisch ist. Dieser Post macht das auf einer konkreten 100-TB-Workload mit drei Last-Profilen.
TL;DR
- BigQuery ist günstig bei schubweisen Ad-hoc-Queries; Slot-Reservierung killt den Preis bei konstanter Last.
- Snowflake ist die unkomplizierteste Wahl bei BI-mit-vielen- Concurrent-Users; XS/S-Warehouses sind verblüffend günstig.
- Databricks ist die richtige Wahl, wenn ML / Streaming / Lakehouse nennenswerter Anteil sind; bei reinem SQL-DWH ist Snowflake angenehmer.
- Faustregel: Storage ist überall ähnlich teuer (~20–25 €/TB/Mo). Compute macht den Unterschied — und Compute hängt von Workload- Profil ab, nicht von dem Plattform-Brand.
Die Pricing-Modelle (kompakt)
Databricks DBU
- Workload-Typ-Abhängig: Jobs (DBU 0,15 $) < SQL (0,22 $) < All- Purpose (0,40 $) < ML (0,55 $)
- DBU-Preis × DBU-Verbrauch pro Stunde × Stunden
- Plus Cloud-VM-Kosten der Worker (AWS/Azure/GCP)
- Edition (Standard, Premium, Enterprise) erhöht DBU-Preis
Snowflake Credits
- 1 Credit ≈ 1 Stunde XS-Warehouse-Compute (~3 $ Standard-Edition)
- Größer XS → S → M → L verdoppelt jedes Mal Credit-Verbrauch/h
- Storage extra (~23 $/TB/Mo Standard)
- Auto-suspend / Auto-resume reduziert Idle-Verbrauch deutlich
BigQuery
- On-Demand: 5 $ pro TB gescannte Daten (nicht gespeichert!)
- Editions / Capacity-Reservation: Slots ($0,04–0,06 / Slot-Hour Enterprise) — kontinuierlich oder Autoscale
- Storage 0,02 $/GB/Mo active, 0,01 $/GB/Mo long-term (alles > 90 Tage)
Die Beispiel-Workload
100 TB Datenvolumen im Warehouse/Lake. Daraus:
Profil A — BI-Heavy (Snowflake-Stärke):
- 200 BI-User
- 50.000 SQL-Queries/Tag, durchschnittlich 200 MB scan / Query
- 30 ETL-Jobs/Tag
- Keine ML-Workloads
Profil B — Engineering-Heavy (Databricks-Stärke):
- 5 Data-Scientists / -Engineers
- 100 Ad-hoc-Notebooks/Tag
- 50 ML-Training-Jobs/Woche
- 5 Streaming-Pipelines (24/7)
- 100 ETL-Jobs/Tag
Profil C — Sporadic (BigQuery-Stärke):
- 10 Analysten
- 1.000 Ad-hoc-Queries/Tag
- 20 ETL-Jobs/Tag
- Spitzen: max 5 Queries gleichzeitig
- Keine ML
Kostenrechnung Monat (Profil A — BI-Heavy)
| Plattform | Compute | Storage 100 TB | Total / Mo |
|---|---|---|---|
| Snowflake | ~5.500 € (XS+S-Mix, ~80h/Tag aktiv) | 2.300 € | ~7.800 € |
| Databricks (SQL Warehouse) | ~7.200 € | 2.300 € (S3) | ~9.500 € |
| BigQuery on-demand | ~7.500 € (gescannte Daten 50k×0,2 TB×30 Tage = ~3000 TB scan, optimiert ~50 % = 1.500 TB × 5 $) | ~2.300 € | ~9.800 € |
| BigQuery Editions Reservation (200 slots) | ~4.300 € | ~2.300 € | ~6.600 € |
Bei BI-Heavy + viele Concurrent-Users macht Snowflake mit suspended-when-idle Warehouses und nur dann Credit-Verbrauch eine gute Figur. BigQuery mit Capacity-Reservation kann günstiger sein, braucht aber Tuning + Disziplin.
Kostenrechnung Monat (Profil B — Engineering-Heavy)
| Plattform | Compute | Storage 100 TB | Total / Mo |
|---|---|---|---|
| Databricks (Mix Job + ML + Streaming) | ~12.000 € | 2.300 € (S3 oder ADLS) | ~14.300 € |
| Snowflake (Snowpark-ML + Streams) | ~14.500 € | 2.300 € | ~16.800 € |
| BigQuery + Vertex AI | ~9.500 € | 2.300 € | ~11.800 € |
Bei Streaming + ML + Lakehouse verschiebt sich das Bild: Databricks ist trotz höheren DBU-Preises bei ML-Workloads ergonomischer und schneller produktiv, weil Notebooks + MLflow + Streaming nativ sind. BigQuery mit Vertex AI ist preislich attraktiver, aber Ergonomie für klassische DS-Workflows weniger comfortable. Snowflake ist nur sinnvoll, wenn Snowpark schon im Stack ist.
Kostenrechnung Monat (Profil C — Sporadic)
| Plattform | Compute | Storage | Total / Mo |
|---|---|---|---|
| BigQuery on-demand | ~150 € (1k queries × 0,2 TB × 30 = 6 TB scan × 5 $) | ~700 € | ~850 € |
| Snowflake (XS auf-Demand) | ~600 € | ~2.300 € | ~2.900 € |
| Databricks (SQL Warehouse, serverless on-demand) | ~1.100 € | ~2.300 € | ~3.400 € |
Bei sporadischer Last ist BigQuery-on-Demand mit echtem Pay-per-Query-Modell konkurrenzlos. Bei Snowflake/Databricks zahlst du Warehouse-Min-Idle-Zeit auch ohne Last.
Wo der Vergleich kippt
"Aber die ETL-Jobs in Databricks sind günstiger"
Stimmt nur für Jobs-Compute ($0,15/DBU). Wenn deine Engineers in All-Purpose-Clustern ($0,40/DBU) entwickeln, weil das schneller geht, vervierfacht sich die Bill für die gleiche Arbeit. Das ist die häufigste Databricks-Kostenfalle.
"BigQuery skaliert magisch"
Stimmt für On-Demand, aber Slot-Reservierung will geplant sein. Über-reservierte Slots = bezahlte Idle-Kapazität. Unter-reserviert = Queries warten oder fallen auf On-Demand-Pricing zurück.
"Snowflake ist teuer, weil Credits teuer sind"
Größter Mythos. XS-Warehouse läuft 60 Sekunden = 1/60 Credit = 5 ¢. Wer Auto-Suspend richtig einstellt, zahlt nur was tatsächlich verbraucht ist. Multi-Cluster-Warehouses werden teuer bei Concurrency-Spikes — das ist aber genau der Punkt, an dem die Plattform glänzt.
Operationale Realität
| Aspekt | Databricks | Snowflake | BigQuery |
|---|---|---|---|
| Setup-Zeit (Tag 0) | 2–3 Tage | 1 Tag | 0,5 Tag (instant) |
| SQL-Standard | ANSI + Delta-SQL | ANSI | StandardSQL (proprietär) |
| Notebooks | Native | Snowsight + Snowpark | Vertex / Colab |
| ML/AI eingebaut | MLflow, AutoML | Snowpark + Cortex | Vertex AI |
| Streaming | Delta Live Tables | Streams + Tasks | Pub/Sub + Dataflow |
| Format-Lock-in | Delta (Open) | Proprietär (mit Iceberg-Read-Out) | Proprietär (BigLake) |
| Multi-Cloud | Ja (AWS/Azure/GCP) | Ja | Nein (nur GCP) |
Lock-in-Risiko:
- Databricks Delta = Open-Source-Format, jeder Spark-Cluster liest es
- Snowflake = höchstes Lock-in, aber Iceberg-Tables seit 2024 reduzieren das
- BigQuery = mittleres Lock-in, BigLake macht Iceberg/Hudi möglich
DACH-/EU-Spezifika
| Anbieter | EU-Region | DPA / AVV |
|---|---|---|
| Databricks | AWS eu-central-1, Azure West Europe, GCP europe-west4 | ja |
| Snowflake | AWS eu-central-1, Azure West Europe, GCP europe-west4 | ja |
| BigQuery | europe-west1 (Belgium), -3 (Frankfurt), -4 (Netherlands) | ja |
Alle drei sind für DACH-Setups gangbar. Snowflake hat EU-Sovereign- Cloud seit 2024 (BMW-Use-Case bekannt), wenn Souveränität Hauptkriterium ist.
Faustregeln zum Mitnehmen
- Wenn dein Team primär SQL macht und BI bedient: Snowflake.
- Wenn ML / Streaming / Lakehouse > 30 % der Workload: Databricks.
- Wenn Workload sporadisch und schon auf GCP: BigQuery.
- Wenn du Cross-Cloud-Resilienz brauchst: Databricks oder Snowflake — BigQuery ist GCP-gebunden.
- Wenn Cost-Anomaly-Risiko hoch ist: BigQuery Editions (vorhersehbar) oder Snowflake mit Resource-Monitor-Caps.
Quellen
Stand: 13. Mai 2026. Workload-Profile sind interne Schätzwerte basierend auf typischen Engagements — kalibriere mit deinem echten Verbrauch.
Geschrieben von
Harbinger Team
Cloud-, Data- und AI-Engineer in DACH. Schreibt seit 2018 über infrastrukturkritische Tech-Entscheidungen — keine Marketing- Folien, sondern echte Trade-offs aus Production-Workloads.
Hat dir das geholfen?
Jede Woche ein neuer Artikel über DACH-Cloud, Data und AI — direkt in dein Postfach. Kein Spam, kein Marketing-Sprech.
Kein Spam. 1-Klick-Abmeldung. Datenschutz bei Loops.so.