Analytische Datenbanken

Im Frühjahr 2024 baute ein Berliner Mobilitätsanbieter ein Echtzeit-Dashboard für seine Flottenleitstelle. Drei Tausend E-Scooter und Fahrräder, alle paar Sekunden ein neuer Standortdatensatz, dazu Buchungs- und Wartungssignale aus dem Backend. Die erste Implementierung lief auf PostgreSQL mit ein paar gut gesetzten Indizes. Solange das Volumen klein blieb, ging das gut. Im Sommer wuchs die Flotte, und die Dashboard-Aktualisierungen begannen, mehrere Sekunden zu brauchen. Im Herbst hingen einzelne Abfragen für die Auswertung der letzten 30 Tage bei 90 Sekunden, weil PostgreSQL für jede Aggregation Millionen Zeilen lesen musste. Die Migration auf ClickHouse dauerte vier Wochen. Danach lieferten dieselben Abfragen Antwortzeiten unter 200 Millisekunden, ohne dass an der Hardware etwas verändert wurde.

Diese Geschichte ist nicht erfunden, sondern eine echte Variante aus dem Berliner Mobilitätsmarkt der vergangenen Jahre. Sie beschreibt, was passiert, wenn man die Architekturschichten verwechselt. PostgreSQL ist ein hervorragendes operatives System, aber kein analytisches. Sobald Antwortzeiten unter einer Sekunde gefordert sind, weil ein Dashboard, eine API-Antwort oder eine eingebettete Auswertung darauf wartet, reicht ein Lakehouse mit Spark oder DuckDB nicht aus. Hier kommen analytische Datenbanken ins Spiel, die intern spaltenorientiert speichern, aggressiv parallelisieren und genau für dieses Antwortzeit-Profil optimiert sind. Dieser Teil sortiert die wichtigsten Vertreter, von der selbstbetriebenen ClickHouse-Instanz bis zu den Hyperscaler-Angeboten BigQuery, Snowflake, Redshift und Databricks SQL.

Wo liegt die Trennung zwischen OLTP und OLAP wirklich?

Klassische relationale Datenbanken wie PostgreSQL, MySQL oder Microsoft SQL Server sind als OLTP-Systeme entworfen, also für Online Transaction Processing. Sie sind exzellent darin, einzelne Zeilen zuverlässig zu schreiben und kleine Lesezugriffe in Millisekunden zu beantworten. Genau das brauchen Bestellsysteme, Buchhaltungen und Anwendungen, in denen viele Nutzer gleichzeitig kleine Änderungen vornehmen.

Analytische Workloads haben einen ganz anderen Charakter. Sie lesen wenige Spalten über sehr viele Zeilen, aggregieren und gruppieren. Genau für dieses Profil sind OLAP-Systeme entworfen, also Online Analytical Processing. Sie speichern intern spaltenorientiert, parallelisieren Aggregationen aggressiv und sind dafür weniger geeignet, einzelne Datensätze schnell zu aktualisieren. Wer beide Welten in einem System abbilden will, kommt schnell an die Grenzen einer der beiden Anforderungen.

In einer modernen Datenarchitektur leben beide Welten parallel. Operative Systeme nutzen weiterhin PostgreSQL oder MySQL, weil dort viele kleine Schreibvorgänge anfallen. Die analytische Schicht setzt entweder auf ein Lakehouse mit Spark oder DuckDB als Engine oder auf eine spezialisierte OLAP-Datenbank. Welche der beiden Optionen besser passt, hängt von der geforderten Antwortzeit ab. Lakehouse-Engines sind hervorragend für Batch-Aufgaben und mittlere Latenzen (Sekunden bis Minuten). Wer Antwortzeiten unter einer Sekunde braucht, kommt um eine echte OLAP-Datenbank nicht herum.

Eine kurze Geschichte hilft beim Verständnis. Bis Mitte der 2010er Jahre versuchten viele Teams, mit reinen Erweiterungen klassischer Datenbanken (Materialized Views in PostgreSQL, Columnstore-Indizes in MS SQL Server, BRIN-Indizes für Bereichsabfragen) analytische Workloads zu bedienen. Das funktionierte bis zu einem gewissen Punkt, scheiterte dann aber an der grundlegenden Architektur. Eine zeilenorientierte Datenbank kann mit Spaltenstatistiken und Indizes nur einen Teil dessen erreichen, was eine spaltenorientierte Engine von Haus aus liefert. Mit dem Aufstieg von ClickHouse, BigQuery und Snowflake hat sich daher in den letzten zehn Jahren eine klare Trennung etabliert. Operativ schreiben, analytisch lesen, in zwei getrennten Systemen.

Was macht ClickHouse zur ersten Wahl im Eigenbetrieb?

ClickHouse hat sich in den vergangenen Jahren als das wichtigste Open-Source-System im OLAP-Segment etabliert. Es ist in C++ geschrieben, läuft auf einer einzelnen Maschine ebenso wie auf einem mehrknotigen Cluster und liefert für viele Abfragen Antwortzeiten, die kommerzielle Systeme erreichen oder übertreffen. Aktuelle Version ist 25.12.10.7 vom 24. April 2026 ^[8]. Seine spaltenorientierte Speicher-Engine, intern MergeTree genannt, schreibt eingehende Daten zunächst in kleine, sortierte Datenblöcke und führt diese im Hintergrund zu größeren zusammen. Dadurch lassen sich auch sehr hohe Schreibraten verkraften, ohne dass die Abfrageleistung leidet.

Die 25er-Linie hat 2025 und Anfang 2026 einen wichtigen Sprung in der Iceberg-Integration gemacht. Mit Version 25.8 unterstützt ClickHouse INSERT in bestehende Iceberg-Tabellen samt positional und equality deletes, mit 25.10 sind ALTER UPDATE und verteiltes Schreiben dazugekommen. Damit ist ClickHouse für Iceberg-Tabellen lese- und schreibseitig auf Augenhöhe mit Spark oder Databricks. ClickHouse Cloud bindet zudem den Iceberg-REST-Katalog und Microsoft OneLake als Datenquellen direkt in der Oberfläche ein, sodass externe Lakehouse-Tabellen ohne Duplizierung abgefragt werden können.

Aus betrieblicher Sicht ist ClickHouse besonders dann interessant, wenn Antwortzeiten unter einer Sekunde gefordert sind, etwa für Web-Analytics, Telemetrie, Echtzeit-Beobachtbarkeit oder eingebettete Dashboards. Es ergänzt einen Data Lake gut, weil es Parquet-Dateien sowohl direkt aus S3 lesen als auch in eigene MergeTree-Tabellen importieren kann. Diese Doppelfähigkeit erlaubt eine Architektur, in der Rohdaten im Lakehouse liegen und nur die abfrageintensive Top-Schicht in ClickHouse repliziert wird.

Eine technische Eigenheit verdient einen Moment Aufmerksamkeit. ClickHouse erlaubt sogenannte Materialized Views, die bei jedem Insert in eine Quelltabelle automatisch eine vorberechnete Aggregation in einer anderen Tabelle aktualisieren ^[6]. Damit lassen sich Dashboards, die zum Beispiel täglich aggregierte Werte über Millionen Ereignisse hinweg zeigen, mit Antwortzeiten weit unter 100 Millisekunden bedienen, weil die Aggregation bereits im Hintergrund passiert ist. Diese Mechanik ist mächtig, verlangt aber eine bewusste Datenmodellierung. Wer wahllos Materialized Views anlegt, vergrößert seinen Speicherbedarf und seine Schreiblast schnell um den Faktor zwei oder drei.

Die Hardware-Anforderungen sind dabei erstaunlich moderat. Eine ClickHouse-Instanz mit 16 Kernen und 64 GB RAM bedient problemlos mehrere Milliarden Zeilen, vorausgesetzt die Sortierschlüssel und Indizes sind sauber gewählt ^[7]. Auf einer Hetzner-Maschine in Falkenstein lässt sich so ein Setup für unter 200 EUR im Monat betreiben, im Eigenbetrieb mit voller Kontrolle über Updates, Backups und Sicherheit. Wer keine Lust auf den Eigenbetrieb hat, findet mit ClickHouse Cloud ein Managed-Angebot des ursprünglichen Anbieters. Daneben hat sich ein eigenes Ökosystem an verwalteten Diensten gebildet, etwa Tinybird, Altinity oder die ClickHouse-Hosting-Variante mehrerer europäischer Provider, die teilweise auf Hetzner-Hardware aufsetzen. Für Hochverfügbarkeits-Setups bietet sich der Verbund aus drei oder fünf ClickHouse-Knoten mit Replikation über ClickHouse Keeper an. ClickHouse Keeper hat ZooKeeper inzwischen als Standard abgelöst, weil es Raft statt ZAB verwendet, ohne JVM auskommt und für die ClickHouse-typischen Coordination-Patterns rund 46-mal weniger Speicher verbraucht ^[9]. Solche Konstellationen vertragen den Ausfall einzelner Knoten, ohne dass laufende Abfragen abbrechen müssen.

ClickHouse Cloud rechnet zwischen 0,2181 und 0,3903 USD pro Compute-Unit-Stunde, gestaffelt über die drei Tarifstufen Basic, Scale und Enterprise, dazu kommen 25,30 USD pro TB-Monat für Storage ^[1]. Mit der April-2026-Aktualisierung steht der Dienst in 18 AWS-Regionen zur Verfügung, vorher waren es sechs. Die vertikale Auto-Skalierung wurde im selben Schritt deutlich verbessert. Das System nutzt jetzt zwei Lookback-Fenster (3 Stunden für schnelle Anpassung, 30 Stunden für stabilere Entscheidungen), was die Skalierungs-Zeit auf wenige Stunden reduziert.

Eine ehrliche Wertung gehört dazu. ClickHouse hat steile Lernkurven dort, wo die meisten OLTP-Datenbanken einfach machen lassen. Sortierschlüssel, Partitionierung, Skip-Indizes, Materialized Views und das Aggregating-MergeTree-Konzept sind mächtig, aber lernintensiv. Wer schnelle Antwortzeiten ohne gründliche Modellierung erwartet, wird enttäuscht. Mit einer halbwegs durchdachten Modellierung dagegen liefert ClickHouse Antwortzeiten, die mit jedem kommerziellen System auf Augenhöhe konkurrieren, oft zu einem Bruchteil der Kosten.

Die Liste der produktiven Anwender wirkt fast prahlerisch. Cloudflare verarbeitet auf ClickHouse pro Tag mehr als 1,6 Quadrillionen Ereignisse aus über 300 Datacentern, Uber, Lyft, Instacart, GitLab, Microsoft und Contentsquare zählen ebenfalls zu den großen Nutzern ^[10]. Auch im deutschsprachigen Raum ist ClickHouse fest verankert. Adtech-Plattformen setzen es für Impression-Tracking ein, Mobilitätsanbieter für Telemetrie, einzelne Telekommunikations- und Versicherungsunternehmen nutzen es für Reporting-Workloads. Die Open-Source-Lizenz, die Möglichkeit zum Betrieb in deutschen Rechenzentren und die spürbar bessere Kostenstruktur gegenüber kommerziellen Alternativen sind die wichtigsten Treiber. Wer eine ähnliche Architektur plant, findet in der Berliner und Münchner Daten-Community zahlreiche Anlaufpunkte für Erfahrungswerte.

Wie sich die Hyperscaler-Angebote unterscheiden

Wer auf Managed Services setzt, hat zwischen den großen Anbietern eine reiche Auswahl. Google BigQuery, Amazon Redshift, Snowflake und Databricks SQL sind die bekanntesten Vertreter. Sie alle teilen die Idee einer trennscharfen Aufteilung zwischen Speicher und Rechenleistung. Daten liegen in einem lake-ähnlichen Speicher, Abfragen werden auf elastisch hinzu- und abschaltbaren Rechenknoten ausgeführt. Das macht die Kostenmodelle plan- und steuerbar, sofern man mit den Mechanismen der jeweiligen Plattform vertraut ist.

BigQuery ist vor allem für Teams interessant, die einen stark schwankenden Abfrage-Workload haben. Das Slot-Modell skaliert mit der Last, ohne dass Cluster-Knoten manuell hinzugefügt werden müssen. Wer einen Monat lang viele Abfragen schickt und im nächsten kaum welche, profitiert vom On-Demand-Modell mit dem ersten kostenfreien Terabyte pro Monat. Bei vorhersehbaren Workloads kommt ein Slot-Reserved-Modell günstiger. Auf Google Cloud Next 2026 wurde das Fluid-Scaling-Modell vorgestellt, das laut Google die Kosten für Autoscaling-Workloads um durchschnittlich bis zu 34 Prozent senkt, ohne dass Konfigurationen angefasst werden müssen.

Snowflake ist das archetypische Cloud Data Warehouse mit klarer Multi-Cloud-Strategie. AWS, Azure und GCP werden gleichberechtigt unterstützt, was Snowflake zu einem natürlichen Kandidaten macht, wenn eine Organisation strategisch keine reine Cloud-Anbieter-Bindung will. Die Nachteile sind die Credit-basierte Abrechnung, die ohne sorgfältige Workload-Steuerung schnell teuer wird, und die historisch proprietäre Datenformat-Schicht. Beides hat Snowflake 2025 und 2026 deutlich entschärft. Iceberg-Tabellen sind seit Juni 2024 GA, am 14. April 2026 ist zusätzlich Snowflake Storage für Apache Iceberg in Preview gegangen. Die Plattform kann damit Iceberg-Tabellen direkt auf eigener Infrastruktur hosten, ohne dass Daten in einem proprietären Format umkopiert werden müssen ^[12]. Mit Snowflake Openflow BYOC (seit November 2025 GA) lässt sich zudem die Datenintegration in der eigenen Cloud-Umgebung deployen. Cortex AI als KI-Schicht in der Datenbank rechnet seit Anfang 2026 nicht mehr nur in Credits, sondern in Tokens, mit dediziertem Cost Management seit März 2026.

Databricks SQL ist die natürliche Wahl für Organisationen, die ohnehin auf Databricks für Spark-Pipelines setzen. Die Integration zwischen Lakehouse und SQL-Warehouse ist eng verzahnt, Delta- und Iceberg-Tabellen lassen sich gleichermaßen ansprechen. Der Preis: tiefe Plattform-Bindung. Eine Migration weg von Databricks ist nicht trivial, weil sich Notebooks, Job-Definitionen und Berechtigungen über die Plattform-API verzahnen.

Amazon Redshift verdient eine kurze Erwähnung, auch wenn es in der Wahrnehmung der letzten Jahre etwas hinter Snowflake und BigQuery zurückgefallen ist. Mit Redshift Serverless hat AWS ein flexibles Preismodell etabliert, bei dem Compute und Storage getrennt abgerechnet werden. Die kleinste Konfiguration ist 4 RPUs (Redshift Processing Units, je 16 GB Memory), maximal lassen sich 1.024 RPUs zuschalten. Im Februar 2026 hat AWS das Modell um Drei-Jahres-Reservierungen erweitert, die bis zu 45 Prozent Compute-Rabatt bringen. Für Organisationen, die ohnehin tief im AWS-Universum verankert sind, bleibt Redshift damit eine vernünftige Wahl. Der Wechsel zu Snowflake oder BigQuery lohnt sich nur dann, wenn die Multi-Cloud-Karte wirklich gespielt werden soll oder wenn spezifische Features benötigt werden, die Redshift bisher nicht bietet (etwa Geo-Funktionen oder erweiterte Window-Operationen).

Für ein typisches Mittelstands-Setup in Deutschland (50 Personen, gemischte Workloads, Buchhaltung und Reporting) liegen die monatlichen Kosten der Hyperscaler-Optionen erfahrungsgemäß zwischen 2.000 und 12.000 EUR, mit ClickHouse Cloud meist im unteren Drittel und Databricks im oberen ^[5]. Selbstbetrieb auf einer Hetzner-Maschine kostet eine Größenordnung weniger, verlangt aber mindestens eine erfahrene Person für Wartung, Monitoring und Upgrades.

Welche Argumente für Selbstbetrieb sprechen und welche dagegen

Die Wahl zwischen Eigenbetrieb und Managed Service ist die wahrscheinlich wichtigste Architekturentscheidung in dieser Schicht. Sie hängt von vier Faktoren ab.

Erstens, der Datenmenge. Bei Datenvolumen unter zehn Terabyte und überschaubarer Schreibrate ist Eigenbetrieb mit ClickHouse auf einer einzigen leistungsstarken Maschine fast immer wirtschaftlich. Bei mehreren Petabyte und tausenden parallelen Konsumenten verschiebt sich das Bild.

Zweitens, der verfügbaren Skill-Basis. Wer keine Person mit ClickHouse-Erfahrung im Team hat, sollte die Lernkurve einkalkulieren. Drei bis sechs Monate, bis ein Team eine ClickHouse-Instanz produktionsreif betreibt, sind realistisch.

Drittens, der regulatorischen Anforderungen. Wer in einer Branche arbeitet, in der Daten zwingend in Deutschland oder zumindest in der EU bleiben müssen (Banken, Versicherungen, öffentliche Verwaltung, Krankenhäuser), findet mit Hetzner oder einem deutschen Hosting-Partner einen klaren Pfad. Bei Snowflake oder Databricks gibt es zwar EU-Regionen, aber die Abrechnungsdaten und Metadaten fließen oft trotzdem über US-Knoten.

Viertens, der erwarteten Wachstumsdynamik. Wer die nächsten 18 Monate stark schwankende Workloads erwartet, profitiert von der Elastizität der Hyperscaler. Wer einen stabilen, planbaren Workload betreibt, fährt mit einer dedizierten Maschine günstiger.

Meine Empfehlung für 2026: Bei neuen Projekten unter 50 Terabyte mit ClickHouse im Eigenbetrieb auf einer Hetzner-Maschine starten. Bei sehr unregelmäßigen Workloads BigQuery oder ClickHouse Cloud. Bei Lakehouse-Verankerung Databricks SQL oder ein direkt aus Polaris angesprochenes Iceberg-Setup. Snowflake bleibt der politische Kompromiss, wenn Multi-Cloud zur Vorgabe wird.

Eine Zwischenoption, die in der Praxis oft übersehen wird, lohnt sich für Anwendungen mit moderater Latenzanforderung. DuckDB als analytische Schicht direkt im Anwendungsprozess kann viele Aufgaben bedienen, die früher eine eigene OLAP-Datenbank verlangt hätten. Wer ein internes Reporting-Tool baut, das einmal pro Stunde frische Daten zieht und mit Antwortzeiten von wenigen Sekunden auskommt, kann sich die ClickHouse- oder Snowflake-Schicht sparen. Erst wenn echte Sub-Sekunden-Latenz oder gleichzeitige Bedienung vieler Endnutzer gefordert sind, wird der Sprung zur dedizierten OLAP-Datenbank zwingend. Diese Differenzierung ist 2026 wichtiger geworden, weil DuckDB so schnell ist, dass die alten Faustregeln nicht mehr stimmen.

Neben ClickHouse und den Hyperscaler-Diensten existieren noch eine Handvoll spezialisierter OLAP-Engines, die für bestimmte Workloads gut passen. Apache Pinot eignet sich für Sub-Sekunden-Dashboards mit sehr hoher Concurrency, etwa als User-facing Analytics. Apache Druid ist stark in zeitreihenlastiger Operationsanalyse. StarRocks und Apache Doris sind aufstrebende MPP-Engines mit vektorisiertem Query-Pfad. Firebolt positioniert sich als Cloud-Native-Alternative mit Fokus auf Indexierung. Für die meisten DACH-Mittelständler bleibt ClickHouse trotzdem die naheliegende Wahl, weil das Ökosystem reifer ist und sich Erfahrungswerte leichter teilen lassen ^[13].

Fazit und Ausblick

Die analytische Datenbank hat in einem Lakehouse-Stack eine klare Aufgabe: Sie beschleunigt diejenigen Abfragen, die direkt mit Endnutzern oder Anwendungen interagieren. Dashboards, eingebettete Analytics, API-Endpunkte mit aggregierten Daten, Real-Time-Reporting. Alles, was nicht warten kann.

In einer sauber gebauten Architektur sieht das Zusammenspiel ungefähr so aus. Rohdaten landen in S3-Buckets, werden als Parquet-Dateien abgelegt und in Iceberg-Tabellen organisiert. Spark oder Polars bauen daraus aufbereitete Datenprodukte (die Gold-Schicht aus Teil 2). Aus dieser Gold-Schicht werden ausgewählte Tabellen in eine ClickHouse-Instanz repliziert oder als Materialized View in Snowflake angelegt. Dashboards und Anwendungen sprechen ausschließlich die analytische Datenbank an, nicht das Lakehouse direkt.

Diese Trennung mag aufwändig wirken, hat aber zwei Vorteile. Erstens entkoppelt sie die Antwortzeiten der Endanwendungen von den Verarbeitungsläufen im Lakehouse. Eine fehlgeschlagene ETL-Pipeline reißt das Dashboard nicht mit. Zweitens schafft sie Spielraum für unterschiedliche Optimierungen. Im Lakehouse zählt Kosteneffizienz, in der OLAP-Datenbank zählt Antwortzeit. Beide Ziele lassen sich nur in getrennten Schichten ohne Kompromisse verfolgen.

Eine letzte Bemerkung gehört dazu. Aus Stakeholder-Sicht ist die wesentliche Frage immer dieselbe. Wie viel Betriebsaufwand kann und will eine Organisation übernehmen, und wie wichtig ist die Unabhängigkeit von einem einzelnen Cloud-Anbieter? Wer beide Fragen ernsthaft beantwortet, hat die meisten Architekturentscheidungen in dieser Schicht bereits getroffen.

Ein praktischer Hinweis zum Replikationsmuster. Die Übertragung von Daten aus dem Lakehouse in eine OLAP-Datenbank lässt sich heute mit relativ wenig Aufwand automatisieren. Werkzeuge wie dbt, Airbyte oder spezialisierte Konnektoren von ClickHouse selbst lesen direkt aus Iceberg-Tabellen oder S3-Buckets und bauen die Zieltabelle inkrementell auf. Eine kurze Marktnote dazu: Im Oktober 2025 haben dbt Labs und Fivetran ihre Fusion angekündigt, was die Konsolidierung im Tooling sichtbar beschleunigt und gleichzeitig Fragen zur Pricing-Stabilität aufwirft ^[14]. Airbyte bleibt unter Apache-Lizenz die offene Alternative für die EL-Schicht, in Kombination mit dbt für Transformationen. Wer einen Berliner Telemetrie-Workload betreibt, schreibt seine Rohdaten zum Beispiel als Parquet in einen S3-Bucket, lässt einen täglichen Spark-Job die Aggregations-Tabellen für die letzten 30 Tage materialisieren und kopiert das Ergebnis in eine ClickHouse-Tabelle. Das Dashboard antwortet damit aus ClickHouse, hat aber den vollen Kontext der Lake-Schicht im Hintergrund.

Wichtig ist, das Replikat als bewusst flüchtige Schicht zu behandeln. Wer Daten in der OLAP-Datenbank verändert oder anreichert, ohne dass die Originale im Lakehouse das mitbekommen, baut sich technische Schulden auf. Die analytische Datenbank ist Cache, nicht Wahrheit. Diese Trennung im Kopf zu behalten, erspart über Jahre eine Menge Schmerz.

Ein zweiter operativer Hinweis. Materialized Views, Aggregationstabellen und Replikate verlangen ein Monitoring, das weit über klassische Datenbank-Metriken hinausgeht. Aktualität ist hier wichtiger als reine Verfügbarkeit. Eine ClickHouse-Tabelle, die zwar antwortet, aber drei Tage alte Daten zurückgibt, ist im Zweifel schlimmer als eine, die kurz nicht erreichbar ist. Ein Berliner Mittelständler nutzt dafür eine kleine Eigenentwicklung, die nach jeder Replikationslauf ein Tabellen-Manifest mit dem Stichtag der zuletzt verarbeiteten Daten in einen S3-Bucket schreibt. Das Dashboard liest dieses Manifest mit und zeigt deutlich an, wenn die Daten älter als zwei Stunden sind. Solche Mechanismen wirken trivial, retten aber regelmäßig die Glaubwürdigkeit einer Plattform.

Im nächsten und letzten Teil geht es um den Bereich, in dem der Stack bisher die wenigsten klaren Antworten hat. Maschinelles Lernen auf großen Datenmengen, von Zeitreihenprognosen bis zu Skalierungsstrategien, und wie sich diese Aufgaben sauber in die übrige Architektur einfügen. Auch dort gilt das Leitprinzip dieser Serie: Trennung der Schichten und offene Standards als Klammer.

Bevor wir die analytische Datenbank verlassen, lohnt ein letzter Gedanke zur Datenmodellierung. ClickHouse, BigQuery und ihre Verwandten belohnen klare Sortierschlüssel und Partitionierungsstrategien. Wer eine Tabelle anlegt, ohne über den dominierenden Filter nachgedacht zu haben, verschenkt einen Großteil der Performance. In der Praxis sind das oft Datums- und Mandantenspalten, die als erste Sortierdimension stehen sollten. Eine bewusste Wahl an dieser Stelle wirkt sich messbar in jeder einzelnen Abfrage aus, die später gegen die Tabelle läuft.

Quellen

^[1] ClickHouse Pricing und Cloud-Changelog 2026 (https://clickhouse.com/pricing, https://clickhouse.com/docs/whats-new/changelog/cloud)

^[2] BigQuery Pricing, Gemini-Integration und Fluid Scaling (Google Cloud Next 2026) (https://cloud.google.com/bigquery/pricing, https://docs.cloud.google.com/bigquery/docs/gemini-overview)

^[3] Snowflake Cortex AI Functions Cost Management GA, März 2026 (https://docs.snowflake.com/en/release-notes/2026/other/2026-02-25-ai-functions-cost-management)

^[4] Databricks Serverless SQL Pricing 2026 (https://www.revefi.com/blog/databricks-pricing-guide, https://www.flexera.com/blog/finops/databricks-pricing-guide/)

^[5] Vergleich Snowflake vs. Databricks vs. BigQuery 2026, Technologymatch (https://technologymatch.com/blog/snowflake-vs-databricks-vs-bigquery-a-guide-for-it-leaders-in-2026)

^[6] ClickHouse MergeTree-Engine, offizielle Dokumentation (https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree)

^[7] Tinybird Self-Hosted ClickHouse Cost Analysis 2026 (https://www.tinybird.co/blog/self-hosted-clickhouse-cost)

^[8] ClickHouse Release 25.x und Iceberg-Integration (https://clickhouse.com/blog/clickhouse-release-25-08, https://clickhouse.com/blog/climbing-the-iceberg-with-clickhouse, https://github.com/ClickHouse/ClickHouse/releases)

^[9] ClickHouse Keeper als ZooKeeper-Alternative, Stand April 2026 (https://clickhouse.com/blog/clickhouse-keeper-a-zookeeper-alternative-written-in-cpp, https://clickhouse.com/docs/guides/sre/keeper/clickhouse-keeper)

^[10] Cloudflare ClickHouse Quadrillion-Event-Analytics (https://itbrief.com.au/story/cloudflare-uses-clickhouse-for-quadrillion-event-analytics, https://clickhouse.com/docs/about-us/adopters)

^[11] Amazon Redshift Serverless Pricing und 3-Jahres-Reservierungen (https://aws.amazon.com/redshift/pricing/, https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-redshift-serverless-three-year-reservations/)

^[12] Snowflake Storage für Apache Iceberg in Preview, 14. April 2026 (https://docs.snowflake.com/en/release-notes/2026/other/2026-04-14-iceberg-snowflake-storage)

^[13] OLAP Database Vergleich 2026 (Pinot, Druid, StarRocks, Doris, Firebolt), Tinybird Blog (https://www.tinybird.co/blog/best-database-for-olap)

^[14] dbt Labs und Fivetran Merger Oktober 2025, Integrate.io 2026 Review (https://www.integrate.io/blog/dbt-review/)