Jedes Angebot für eine managed Datenplattform landete an derselben Stelle: über tausend Euro im Monat, bevor auch nur ein Dashboard existierte, auf US-eigener Infrastruktur, mit meinen Daten an einem Ort, den ich nicht kontrolliere. Ich brauchte eine Analytics-Plattform — eine Handvoll Quellen einlesen, modellieren, Zahlen vor Nicht-Techniker bringen — und der Modern Data Stack hat für jede Schicht davon sehr gute Open-Source-Antworten. Also habe ich das Ganze self-hosted auf Hetzner betrieben. Es läuft für unter 200 € im Monat. Hier ist der Stack, die echten Trade-offs und die zwei Entscheidungen, die ich zuerst falsch getroffen habe.
Was "managed" wirklich kostet
Das Versprechen managed Plattformen ist, dass sie Betriebsarbeit sparen — und das tun sie. Was das Versprechen auslässt, ist die Form der Rechnung. Microsoft Fabric lag bei über 1.000 €/Monat für meine Last. Snowflake und Databricks sind nutzungsbasiert, was billiger klingt, bis ein Backfill oder ein unbedachtes Dashboard mehr scannt als eingeplant — die Zahl ist per Design unvorhersehbar. Und alle drei legen meine Daten auf Infrastruktur, die mir nicht gehört, unter einer Jurisdiktion, die ich einem Datenschutzbeauftragten erklären müsste.
Nichts davon ist für jeden ein Ausschlusskriterium. Wer keine Betriebs-Kapazität und ein großzügiges Budget hat, für den ist managed die richtige Antwort. Ich hatte das Gegenteil: ein enges Budget, eine harte Anforderung an EU-Datensouveränität und genug Kubernetes und SQL, um Infrastruktur selbst zu betreiben. Diese Kombination zeigt direkt auf Self-Hosting.
Der Stack, Schicht für Schicht
Der "Modern Data Stack" ist eigentlich nur eine Menge von Rollen — Storage, Ingestion, Query-Engine, Transformation, Orchestrierung und eine BI-Schicht — für die es jeweils inzwischen eine solide Open-Source-Option gibt. Hier ist, was ich gewählt habe und, nützlicher, warum.
Storage: Object Storage + Apache Iceberg
Der Lake liegt in Hetzner Object Storage (S3-kompatibel) als Apache-Iceberg-Tabellen. Iceberg gibt dir Tabellen-Semantik — Schema-Evolution, Time Travel, atomare Writes — auf simplen Parquet-Dateien, die dir vollständig gehören. Das Format ist offen, also bindet mich diese Schicht an keinen Anbieter und nicht einmal an die Query-Engine. Genau diese eine Entscheidung macht den Rest des Stacks austauschbar.
Query-Engine: ClickHouse auf dedizierter Hardware
ClickHouse ist der Kern und läuft auf einer dedizierten Hetzner-Maschine statt in meinem Kubernetes-Cluster. Das war Absicht: ein analytischer Column-Store will direkten Zugriff auf schnelles lokales NVMe und vorhersehbaren Speicher, und ihn in K8s neben laute Nachbarn zu setzen bringt nur Scheduling-Kopfschmerzen. Eine dedizierte Maschine mit viel RAM und gespiegeltem NVMe kostet einen Bruchteil eines managed Warehouse und ist bei den Queries, die ich real fahre, schneller.
Transformation: dbt
Transformation ist dbt mit dem ClickHouse-Adapter. dbt ist die eine Schicht, bei der ich managed oder nicht dieselbe Wahl getroffen hätte — es ist der Standard geworden, um rohe Tabellen in modellierte zu verwandeln, und der dbt-clickhouse-Adapter ist reif genug für echte Arbeit. Modelle sind versioniertes SQL, in CI getestet und direkt in ClickHouse materialisiert. Es ist nischig genug, dass du gelegentlich an eine Adapter-Kante stößt, die die Postgres- oder Snowflake-Welt nie sieht, aber für Standard-Modellierung funktioniert es schlicht.
Orchestrierung: Dagster
Alles zusammengehalten wird von Dagster, als Open-Source in Kubernetes. Ich habe Dagster statt Airflow genommen, weil es die Pipeline als Assets modelliert — "diese Tabelle existiert und hängt von jener Quelle ab" — statt als Sammlung von Tasks. Wenn die Frage "sind die Daten dieses Dashboards frisch und woher kommen sie" lautet, beantwortet ein Asset-Graph sie direkt. Die ganze Kette Ingest → dbt → BI ist ein Lineage-Graph, den ich ansehen kann.
BI: eine self-hosted Dashboard-Schicht
Für die letzte Meile — Zahlen vor Leuten, die nie SQL schreiben werden — nutze ich ein self-hosted BI-Tool mit eigenem Postgres. Es liest direkt aus ClickHouse, also sind Dashboards schnell, und weil es self-hosted ist, verlassen die Daten zum Rendern nie die Plattform. Das ist die Schicht, die das Ganze vor allen rechtfertigt, die keine Ingenieure sind.
Ingestion: der Teil, den ich zuerst falsch hatte
Mein ursprünglicher Entwurf zog Änderungen mit Debezium aus den Quell-Datenbanken, der Standard-Weg für Change Data Capture. Auf dem Papier ist das die richtige Antwort: nahezu Echtzeit, erprobt, genau wofür CDC da ist. In der Praxis war es zu viel bewegliche Mechanik für das, was ich tatsächlich brauchte. Debezium will eine Kafka-förmige Welt um sich herum, und meine Quellen änderten sich nicht schnell genug, um dieses Gewicht zu rechtfertigen.
Also habe ich es umgekehrt. Der Batch-Sync läuft jetzt auf dlt — einer kleinen Python-Library, die eine Quelle liest und nach Zeitplan in den Lake legt — von Dagster getriggert. Auf einem Diagramm weniger beeindruckend und im Betrieb deutlich weniger, und für Daten, die stündlich oder täglich frisch genug sind, schlicht der korrekte Trade. Die Lektion, die ich immer wieder lerne: nimm die Ingestion-Kadenz, die deine Daten wirklich haben, nicht die schnellste verfügbare.
Was es kostet — an Geld und sonst
Die Infrastruktur-Rechnung liegt bei unter 200 €/Monat: die dedizierte ClickHouse-Maschine, das Object Storage und ein kleiner Kubernetes-Cluster für die Orchestrierungs- und BI-Pods. Das ist ein Bruchteil des managed Angebots, auf Hardware in einem EU-Rechenzentrum, mit meinen Daten in offenen Formaten, die ich morgen überallhin verschieben könnte.
Der ehrliche Preis steht auf der anderen Seite der Bilanz. Self-Hosting heißt, dir gehört der Pager. Ein managed Warehouse, das umfällt, ist das 3-Uhr-nachts-Problem von jemand anderem; meins ist meins. Bis ich einen zweiten Knoten hinzufüge, ist die Query-Engine ein Single Point of Failure, und jede Komponente ist ein weiteres Ding zum Patchen, Sichern und Verstehen. Wer Kubernetes und eine Datenbank nicht bequem betreiben kann, dem frisst diese Betriebslast jede gesparte Summe. Diese Zahl ist echt, aber nicht gratis — es ist ein Tausch von Geld gegen Kontrolle und Kompetenz.
Würde ich es wieder tun?
Für diese Situation ohne Zögern. Die Kombination, die es richtig machte — eine echte Budget-Obergrenze, eine harte EU-Souveränitäts-Anforderung und die interne Fähigkeit, es zu betreiben — ist häufig genug, dass viele Teams still in derselben Lage sind und trotzdem zu managed greifen. Wenn das du bist: der Modern Data Stack lässt sich sauber self-hosten, und die Teile sind alle Open Source und inzwischen wirklich gut, auf eine Art, wie sie es vor ein paar Jahren nicht waren.
Häufige Fragen
Ist ein self-hosted Data Stack wirklich günstiger als Snowflake oder Fabric?
Bei reiner Infrastruktur dramatisch — hier unter 200 €/Monat gegen 1.000 €+ angeboten. Aber diese Zahl ignoriert deine eigene Zeit. Wer einen Ingenieur einstellen oder abziehen muss, um es zu betreiben, für den kann der managed Aufpreis die günstigere Option sein. Es ist günstiger an Geld, nicht zwingend an Gesamtkosten.
Warum ClickHouse statt einfach Postgres?
Postgres ist ein Row-Store; Analytics-Queries scannen Spalten über Millionen Zeilen, genau wofür ein Column-Store wie ClickHouse gebaut ist. Für transaktionale Last gewinnt Postgres; für Aggregationen über große Tabellen ist ClickHouse oft um Größenordnungen schneller.
Brauche ich Kubernetes dafür?
Nein. Ich nutze es, weil ich ohnehin einen Cluster betrieb und es die Orchestrierungs- und BI-Pods einfach verwaltbar macht, aber du kannst denselben Stack mit Docker Compose auf ein paar Maschinen fahren. Die Query-Engine sitzt so oder so bewusst auf dedizierter Hardware.
Warum Dagster statt Airflow?
Airflow modelliert Tasks; Dagster modelliert Daten-Assets und ihre Lineage. Für eine Analytics-Pipeline, bei der die eigentliche Frage "ist diese Tabelle frisch und woher kommt sie" lautet, beantwortet das Asset-Modell sie nativ. Airflow ist die sicherere Wahl, wenn dein Team es schon gut kennt.