Ein Data Warehouse in der Cloud kostet nach einem von zwei Modellen: nach der Datenmenge, die jede Abfrage liest, oder nach der Rechenkapazität, die über die Zeit bereitsteht; der Speicher läuft in beiden Fällen als eigener Posten. Für die Rechnung heißt das: Im ersten Modell kann eine einzige Abfrage den Betrag eines Tages bestimmen, im zweiten kostet die Kapazität auch dann, wenn niemand abfragt.

So funktioniert es

DienstModellAbgerechnete EinheitSpeicher
BigQuery on-demandgelesene DatenTiB verarbeitete Daten, erstes TiB je Monat freiaktiv oder langfristig, logisch oder physisch, je GiB-Monat
BigQuery editionsKapazitätSlot-Stunde in Standard, Enterprise, Enterprise Pluswie on-demand
Amazon Athenagelesene Daten oder KapazitätTB gescannt oder DPU-Stunde (Capacity Reservations)Amazon S3 zu S3-Preisen
Amazon Redshift ProvisionedKapazitätKnotenstunde je Knotentyp (RG, RA3, DC2)Redshift Managed Storage je GB-Monat bei RG und RA3
Amazon Redshift ServerlessKapazitätRPU-StundeRedshift Managed Storage je GB-Monat
Microsoft FabricKapazitätF-SKU in Kapazitätseinheiten (CU)OneLake je GB-Monat
Azure Synapse AnalyticsKapazität oder gelesene DatenDWU-Stunde (dedizierter SQL-Pool) oder TB verarbeitet (serverloser SQL-Pool)je TB-Monat, inklusive sieben Tage Snapshots

Nach gelesenen Daten

BigQuery on-demand berechnet die Bytes der ausgewählten Spalten, aufgerundet auf das nächste MB, mindestens 10 MB je referenzierter Tabelle und je Abfrage; ein LIMIT verringert die Menge nicht, und ein abgebrochener Job kann bis zu den vollen Kosten der Abfrage berechnet werden. Athena berechnet je TB gescannter Daten, aufgerundet auf das nächste MB, mindestens 10 MB je Abfrage; DDL-Befehle und fehlgeschlagene Abfragen sind kostenlos, abgebrochene werden nach der bis dahin gescannten Menge berechnet. Amazon S3 berechnet Lesen und Ergebnisablage zusätzlich, auch für fehlgeschlagene Abfragen. Redshift Spectrum rechnet bei RA3- und DC2-Clustern ebenso je TB ab; RG-Knoten haben eine eigene Abfrage-Engine für den Data Lake und brauchen Spectrum nicht, in Redshift Serverless ist es enthalten. Der serverlose SQL-Pool von Synapse berechnet je TB verarbeiteter Daten mit 10 MB Minimum.

Nach Kapazität

BigQuery editions berechnen Slots, also virtuelle CPUs, je Slot-Stunde, standardmäßig sekundengenau mit einer Minute Minimum; mit dem wählbaren Fluid Scaling entfällt das Minimum. Redshift Provisioned berechnet Knotenstunden, angebrochene Stunden sekundengenau; ein pausierter Cluster kostet keine On-Demand-Stunden, und Concurrency Scaling ist je Cluster bis zu einer Stunde Guthaben am Tag kostenlos. Redshift Serverless berechnet RPU-Stunden sekundengenau mit 60 Sekunden Minimum, bei einer Basiskapazität von 4 bis 1.024 RPU zu je 16 GB Arbeitsspeicher und einem einstellbaren Höchstwert in RPU-Stunden. Athena Capacity Reservations kosten je DPU-Stunde ab 4 DPU, ohne Gebühr für gescannte Daten. Microsoft Fabric berechnet F-SKUs sekundengenau mit einer Minute Minimum, als Pay-as-you-go oder mit Reservierung; alle Workloads einer Kapazität teilen sich ihre CU, und Überschreitungen lassen sich als Fabric capacity overage zum Pay-as-you-go-Preis bezahlen. Der dedizierte SQL-Pool von Synapse kostet für jede Stunde, in der er existiert, die höchste DWU-Stufe dieser Stunde; nur eine volle Stunde Pause spart Rechenleistung.

Speicher getrennt von Rechenleistung

BigQuery unterscheidet aktiven Speicher von langfristigem, für Tabellen oder Partitionen, die 90 Tage nicht geändert wurden, zu einem niedrigeren Preis: in europe-west3 bei physischer Abrechnung zum halben Preis, bei logischer zu 0,016 statt 0,023 USD je GiB-Monat. Das Abrechnungsmodell, logisch (unkomprimiert) oder physisch (komprimiert, inklusive Time Travel und Fail-safe), wird je Dataset festgelegt. Redshift Managed Storage kostet denselben Preis, ob die Daten auf lokalen SSDs oder in Amazon S3 liegen; manuelle Snapshots kosten zusätzlich. Fabric berechnet OneLake in den Stufen hot, cool und cold; für Mirroring-Replikate ist Speicher bis zur Größe der SKU in TB frei, etwa 64 TB bei F64, und wird berechnet, wenn er darüber liegt oder die Kapazität pausiert. Azure Synapse Analytics hat am Lesetag weiter eine eigene Preisseite; sie sagt nichts über das Verhältnis zu Fabric.

Was es für Ihre Kosten bedeutet

Abfragekosten landen dort, wo der Job läuft, nicht beim Dataset, das er liest: BigQuery berechnet Jobs dem Abrechnungskonto des Projekts, in dem sie laufen, Athena trennt Teams und Grenzen über Workgroups, Redshift Serverless misst RPU-Stunden je Workgroup, und Fabric erscheint auf der Azure-Rechnung als Kapazität, nicht als die Workspaces, die sie teilen. Für die Kostenzuordnung braucht es deshalb Projekt-, Workgroup- oder Kapazitätsgrenzen entlang der Teams, und Kennzahlen wie Kosten je Bericht für Unit Economics setzen dieselben Grenzen voraus. Der Google-Abrechnungsexport liegt selbst in BigQuery (Google-Cloud-Abrechnungsexport), und Abfragen darauf kosten wie jede andere.

Im Modell nach gelesenen Daten zeigt sich eine teure Abfrage als Tagesspitze, die eine Anomalie auslöst (Erkennung von Kostenanomalien). Im Kapazitätsmodell ist der Posten gleichmäßig, und die Frage lautet, wie viel der bezahlten Kapazität genutzt wird. Für gleichmäßige Last senken Commitments den Preis, etwa BigQuery-Slot-Commitments, Redshift Serverless Reservations oder die Fabric-Reservierung (reservierte Kapazität für verwaltete Dienste). Plattformen von Drittanbietern, über einen Marketplace gekauft, erscheinen als Marketplace-Käufe; transaktionale Datenbanken behandelt Verwaltete Datenbanken, Objektspeicher für Athena Block-, Objekt- und Dateispeicher.

Wo es schiefgeht

  • LIMIT als Kostenbremse. Symptom: Ein kleines Ergebnis kostet viel. Ursache: BigQuery berechnet die gelesenen Spalten unabhängig von LIMIT, und Athena liest unkomprimierten Text immer ganz.
  • Abgebrochen heißt nicht kostenlos. Symptom: Posten für Abfragen, die niemand zu Ende laufen ließ. Ursache: BigQuery kann bis zu den vollen Kosten berechnen, Athena die bis zum Abbruch gescannten Daten.
  • Kapazität im Leerlauf. Symptom: Gleiche Kosten nachts und am Wochenende. Ursache: Ein Redshift-Cluster, eine Fabric-Kapazität oder ein dedizierter SQL-Pool kostet, solange er läuft, und wird nicht pausiert.
  • Kosten im falschen Projekt. Symptom: Das Projekt mit den Daten wirkt günstig, das zentrale BI-Projekt teuer. Ursache: Abfragen werden dem Projekt berechnet, in dem der Job läuft.
  • Vergessener Speicher. Symptom: Der Speicher sinkt nach dem Löschen nicht wie erwartet. Ursache: Physische Abrechnung in BigQuery schließt Time Travel und Fail-safe ein, gelöschte Fabric-Workspaces kosten während ihrer Aufbewahrungszeit OneLake-Speicher, und manuelle Redshift-Snapshots bleiben.

Beispiel

Listenpreise in USD, gelesen am 2026-10-16, für Frankfurt: BigQuery in europe-west3, AWS in Europe (Frankfurt), Fabric in Germany West Central.

DienstRechnenSpeicher
BigQuery on-demand8,125 je TiB nach dem freien ersten TiBaktiv logisch 0,023, langfristig logisch 0,016 je GiB-Monat
BigQuery Standard Edition0,052 je Slot-Stunde, Enterprise 0,078wie on-demand
Amazon Athena5,00 je TB gescannt; 0,33 je DPU-StundeS3-Preise
Redshift Serverless0,451 je RPU-Stunde0,0256 je GB-Monat
Microsoft FabricF2 0,44 je Stunde, F64 14,08 je StundeOneLake hot 0,024 je GB-Monat

Quellen

Gelesen am 2026-10-16. AWS: Amazon Redshift Preise, Amazon Athena Preise. Google: BigQuery Preise, Überblick über BigQuery-Speicher. Microsoft: Microsoft Fabric Preise, Lizenzen und Kapazität von Microsoft Fabric, Azure Synapse Analytics Preise.