Snowflake vs Databricks vs BigQuery: Die Kostenrealität 2026

Jeder Plattformverantwortliche, der einen siebenstelligen Data-Warehouse-Vertrag unterzeichnet hat, kennt die Überraschung im zweiten Jahr: Das Abfragevolumen hat sich verdreifacht, die Rechnung vervierfacht, und niemand im Team kann erklären warum. Der 2026er Überblick über Snowflake, Databricks und BigQuery trifft genau diese Unsicherheit. Drei Plattformen, drei Preismodelle und eine Fortune-500-Kundenbasis, die den Zähler im Blick behält.

Was passiert ist

Ein aktueller direkter Vergleich, der diese Woche veröffentlicht wurde, zeigt den Stand der analytischen Großen Drei Mitte 2026. Wie https berichtete, bilden die drei Plattformen mittlerweile das analytische Rückgrat der meisten Fortune-500-Unternehmen – und die Wachstumszahlen sind alles andere als unauffällig.

Snowflake verzeichnete im zuletzt gemeldeten Quartal einen Produktumsatz von 1,33 Milliarden US-Dollar, ein Anstieg von 34 % im Jahresvergleich. Credits kosten je nach Edition und Region etwa 2 bis 4 US-Dollar pro Stück. Databricks schloss laut TechCrunch im Dezember 2025 eine Series-L-Finanzierung über 4 Milliarden US-Dollar bei einer Bewertung von 134 Milliarden US-Dollar ab und meldete Mitte 2026 einen annualisierten Umsatz von rund 6,9 Milliarden US-Dollar. BigQuery ist Teil von Google Clouds jährlichem Umsatz von über 50 Milliarden US-Dollar, wird nicht separat ausgewiesen und berechnet im On-Demand-Modell 6,25 US-Dollar pro verarbeitetem TiB.

Die strukturellen Schritte im Jahr 2025 sind genauso bedeutsam wie die Umsatzzahlen. Snowflake übernahm Crunchy Data. Databricks übernahm Neon. Beide Anbieter kauften sich im selben Jahr in transaktionales Postgres ein – ein Signal, dass die reinen Warehouse- und Lakehouse-Geschichten vorbei sind. Alle drei Plattformen unterstützen jetzt Apache Iceberg, das offene Tabellenformat, das es theoretisch ermöglicht, Daten zu verschieben, ohne sie neu zu schreiben.

Jeder Anbieter hat außerdem das Territorium des anderen betreten. Snowflake ergänzte Snowpark und Container-Services für Engineering- und ML-Workloads. Databricks fügte Databricks SQL und serverlose Warehouses für BI-Teams hinzu. BigQuery ergänzte BigLake und Iceberg-Unterstützung für Lakehouse-Muster. Die Konvergenz ist real, aber die zugrundeliegenden Architekturen verhalten sich bei der Abrechnung nach wie vor sehr unterschiedlich.

Technische Anatomie

Snowflakes Design ist am einfachsten zu betreiben. Daten liegen im Cloud-Objektspeicher in Snowflakes proprietärem komprimierten Spaltenformat. Die Berechnung erfolgt in virtuellen Warehouses der Größen X-Small bis 6X-Large, die bei Inaktivität automatisch pausieren und bei Bedarf automatisch wieder starten. Es gibt keine Indizes zu optimieren und keine Cluster zu überwachen. Größe auswählen, SQL darauf ausrichten, fertig. Die Snowflake-Dokumentation beschreibt das Warehouse-Größenmodell ausführlich – und genau das ermöglicht es BI-Teams ohne Plattform-Engineer, einen soliden Analytics-Stack zu betreiben.

Databricks verfolgt die entgegengesetzte Philosophie. Daten liegen in offenen Formaten im eigenen Cloud-Storage-Bucket, verwaltet durch Delta Lake, das ACID-Transaktionen, Schema-Validierung und Time Travel auf Parquet-Dateien aufsetzt. Die Berechnung läuft auf Apache-Spark-Clustern, beschleunigt durch Photon, eine in C++ geschriebene vektorisierte Engine. Die Plattform umfasst Notebooks, Streaming, SQL-Warehouses und den vollständigen ML-Lebenszyklus über MLflow und Mosaic AI. Die Databricks-Dokumentation ist aus gutem Grund umfangreich: Dies ist eine echte Plattform, keine verwaltete Query-Engine, und sie belohnt Teams mit echten Data Engineers.

BigQuery ist als einziges der drei Systeme wirklich serverlos. Es gibt kein Warehouse, das dimensioniert werden muss. Man sendet eine Abfrage, Googles Dremel-Engine weist Slots aus einem gemeinsamen Pool zu und gibt sie anschließend wieder frei. Der Speicher liegt auf Colossus, Googles verteiltem Dateisystem. Omni kann Daten auf AWS und Azure abfragen, aber die Control Plane verbleibt auf GCP – Multi-Cloud bleibt damit ein halbes Versprechen.

Meine Einschätzung: Die Konvergenzgeschichte wird übertrieben. Ein Spark-Cluster, der vorgibt, ein Warehouse zu sein, ist um 2 Uhr nachts, wenn etwas kaputt geht, immer noch ein Spark-Cluster. Ein Snowflake-Warehouse, das Python in einem Container ausführt, verbucht Credits auf dieselbe Weise. Die Laufzeitumgebungen vergessen ihre Herkunft nicht – und die operativen Fehlermuster, die ich bei Produktionsvorfällen erlebt habe, auch nicht.

Wer Probleme bekommt

Die am stärksten gefährdeten Teams in den nächsten 90 Tagen sind jene, die eine Plattform für einen Workload gekauft haben und nun aufgefordert werden, einen anderen darauf zu betreiben. Ein BI-Shop, der sich vor drei Jahren auf Snowflake festgelegt hat und nun einen VP hat, der „KI-Features bis Q4" fordert, steht vor Snowpark, Container-Services und einer Lernkurve, die nicht zum Skillset des Teams passt. Die Fähigkeit ist vorhanden. Das Muskelgedächtnis nicht.

Das Spiegelbild trifft Databricks-Teams. Teams, die das Lakehouse für Data Engineering und ML gekauft haben, werden nun gebeten, Self-Service-BI für Finance und Marketing bereitzustellen. Databricks SQL und serverlose Warehouses sind glaubwürdig, aber das Betriebsmodell setzt immer noch voraus, dass jemand Cluster, Delta-Optimierung und Photons Eigenheiten versteht. Der unbequeme Befund: Viele Organisationen haben Databricks wegen des ML-Versprechens gekauft und nutzen stillschweigend vielleicht 20 % der Plattform, zahlen aber den vollen Preis.

BigQuery-Kunden stehen vor einem anderen Problem. Die 6,25 US-Dollar pro verarbeitetem TiB sehen auf einer Präsentation wunderbar aus – bis ein Analyst an einem Montagmorgen ein SELECT * gegen eine 40-TiB-Tabelle ausführt. Das sind 250 US-Dollar für eine einzige Abfrage, und Teams, mit denen ich gearbeitet habe, haben monatliche Rechnungen erlebt, die sich durch ein einziges schlechtes Dashboard verdreifacht haben. Bei einem 10-köpfigen Data-Team entspricht ein unerwarteter Monat von 50.000 US-Dollar dem Budget von zwei Engineers, das durch einen unachtsamen Join verloren geht.

Die Postgres-Übernahmen – Crunchy Data durch Snowflake und Neon durch Databricks – verändern auch, wer Probleme bekommt. Operative Datenspeicher, die früher außerhalb der Reichweite des Warehouse-Anbieters lagen, sind nun Teil des nächsten Verkaufszyklus. Erwarten Sie, dass Verlängerungsgespräche 2026 transaktionales Postgres in die Rabattrechnung einbeziehen, was den Ausstieg schwerer und nicht leichter macht.

Playbook für Data Teams

Erstens: Kosten instrumentieren, bevor Sie irgendetwas anderes instrumentieren. Bei Snowflake: Warehouses nach Team taggen und Auto-Suspend aggressiv einstellen. Bei Databricks: Cluster-Richtlinien durchsetzen und inaktive Notebooks beenden. Bei BigQuery: noch diese Woche Query-Byte-Limits pro Nutzer und Projekt setzen, nicht nächstes Quartal. Eine einzige Absicherung verhindert mehr Überschreitungen als jede quartalsweise Überprüfung.

Zweitens: Die Iceberg-Geschichte ernst nehmen, aber dem Marketing nicht blind vertrauen. Alle drei Plattformen unterstützen Iceberg ab 2026, was bedeutet, dass Ihre Daten prinzipiell von allen gelesen werden können. In der Praxis binden Sie Write-Pfad, Katalog und Governance-Schicht nach wie vor an einen Anbieter. Führen Sie einen Proof of Concept durch, bei dem Sie von einer Engine schreiben und von einer anderen lesen, bevor Sie der Portabilitätsbehauptung in einem Board-Deck vertrauen.

Drittens: Transformation vom Warehouse-Anbieter entkoppeln. Tools wie dbt ermöglichen es, die Modellierungsschicht portabel zu halten, auch wenn die zugrundeliegende Engine es nicht ist. Wenn Sie 2027 vor einer Migration stehen, wird das Team, das dbt bereits gegen das Warehouse einsetzt, die Migration in Monaten abschließen. Das Team mit Tausenden von Stored Procedures wird Jahre brauchen.

Viertens: Die Plattform an das Team anpassen, das Sie tatsächlich haben, nicht das Team, das Sie sich wünschen. Snowflake für SQL-lastiges BI ohne Plattform-Engineer. Databricks, wenn Sie echte Data Engineers und eine ML-Roadmap haben. BigQuery, wenn Sie bereits GCP-nativ sind. Die falsche Plattform für Ihre Personalstruktur zu wählen ist der teuerste Fehler in dieser Kategorie.

Wichtigste Erkenntnisse

• Snowflakes Quartal mit 1,33 Mrd. US-Dollar bei 34 % Wachstum und Databricks' Series-L-Bewertung von 134 Mrd. US-Dollar belegen: Die Analytics-Kategorie konsolidiert sich nicht – sie expandiert in Postgres und KI.
• BigQuerys 6,25 US-Dollar pro verarbeitetem TiB belohnt diszipliniertes SQL und bestraft nachlässige Abfragen; Byte-Limits setzen, bevor der erste schlechte Montag kommt.
• Iceberg-Unterstützung auf allen drei Plattformen ist real, aber unvollständig; Write-then-Read über Engines hinweg testen, bevor dem Portabilitätsversprechen geglaubt wird.
• Die Postgres-Übernahmen von 2025 (Crunchy Data, Neon) bedeuten, dass operative Daten nun im Scope des Warehouse-Vendor-Lock-ins liegen; Verlängerungen entsprechend planen.
• Die Plattform wählen, die zum tatsächlichen Personalmodell passt, nicht die mit der besten KI-Demo. Operative Eignung schlägt Feature-Parität jedes Mal.