Data Warehouse

PostgreSQL als Warehouse: nah, souverän, right-sized.

Ein einziges PostgreSQL trägt das ganze Warehouse – sauber getrennt in die Layer raw, int und mart. Warum wir kein Cloud Data Warehouse wie Snowflake nehmen, wie das Schema und die Governance aussehen und wie die drei Kernprozesse durch die Layer materialisieren.

Warum kein Cloud Data Warehouse

Postgres vs. Snowflake

Ein Cloud Data Warehouse wie Snowflake ist gebaut für Petabyte-Skalen, elastische Compute und tausende gleichzeitige Nutzer. Die meisten Mittelstands-Workloads im DACH-Raum sind aber Gigabyte, nicht Petabyte. Für diese Realität ist eine self-hosted PostgreSQL das right-sized Warehouse – vorhersehbar in den Kosten, souverän in der Kontrolle und pro Kunde klonbar.

Cloud DWH (Snowflake)

Getrennte Storage/Compute, quasi unbegrenzte Skalierung – aber consumption-based abgerechnet, US-managed und proprietär. Kosten schwer vorhersehbar.

PostgreSQL (self-hosted)

Fixe Serverkosten, Daten im eigenen Perimeter, Open-Source. Der ganze Stack wird pro Engagement geklont – right-sized statt over-provisioned.

Kosten

Fixpreis statt per-Query

Ein monatlicher Serverpreis (Hetzner) statt Compute-Credits pro Sekunde. Kein teurer Scan überrascht die Rechnung. Bei GB–niedrigen TB dramatisch günstiger.

Souveränität

Daten im eigenen Perimeter

Self-hosted auf EU-Infrastruktur – Daten verlassen nie den Perimeter. DSGVO-freundlich und kompatibel mit „Client bringt eigenes VPN“ (Profil B).

Portabilität

Kein Vendor-Lock-in

Kein proprietärer SQL-Dialekt, keine Account-Bindung. Ein Postgres-Stack lässt sich klonen – ein Snowflake-Account nicht.

Right-sized

Weniger bewegliche Teile

Elastische Compute ist mächtig, aber Overkill, wenn die Daten auf eine Maschine passen. Weniger Betriebskomplexität, weniger Angriffsfläche.

Ehrlich · wann ein Cloud DWH gewinnt

Bei echten Petabyte-Volumen, hoher paralleler BI-Last über hunderte Nutzer oder wenn Storage und Compute stark unabhängig skalieren müssen, spielt Snowflake seine Stärken aus. Für unsere Profile ist das selten – und Postgres wächst mit: Partitionierung, Read-Replicas und columnar Extensions wie pg_duckdb tragen weit hinein.

Schema & Governance

Layer · Rollen · Contracts

Das Warehouse ist eine Datenbank, aber sauber in Layer getrennt. Schemas sind gleichzeitig Namensräume und Sicherheitsgrenzen: Drei Layer, drei Rollen. Wer schreiben darf, wer transformieren darf und wer nur lesen darf, ist im Schema selbst verankert – nicht in der Anwendung.

Die Layer

Schema-Architektur

rawLanding-Zone – roh & append-only, exakt wie von dlt geliefert. Keine Business-Logik.stgStaging – 1:1 pro Quelle: umbenannt, typisiert, leicht bereinigt. Meist Views.intIntermediate – Joins & wiederverwendbare Zwischenlogik, konformiert.martBusiness-Layer – Fakten & Dimensionen, benannte KPIs. Das, was BI liest.

Governance

Wer darf was

Roles & grantsloader → INSERT raw · transformer → SELECT/CREATE · bi_read → SELECT mart.Contracts & testsdbt: not_null, unique, relationships und Model-Contracts zwischen Layern.NamingKonvention trägt Bedeutung: stg_ · int_ · fct_ · dim_.LineageDer dbt-Graph plus Constraints machen Abhängigkeiten nachvollziehbar.

Die Trennung ist keine Kosmetik: bi_read hat schlicht kein Recht, raw zu sehen. Governance liegt im Schema, nicht im Vertrauen.

Die drei Prozesse

läuft · Endlosschleife

Drei getrennte Prozesse bewegen Daten durch die Layer – jeder mit eigener Rolle und eigenem Recht. Jeder Prozess ist unten als eigenes Element animiert.

rawloader · INSERTstgtransformer · CREATEinttransformer · CREATEmartbi_read · SELECT

Prozess 01dlt schreibt in rawEL · append

QuelleFinnhub · CSVAPI / Files

extract

Pipelinedltnormalize + load

load

raw.orders0

+ _dlt_load_id · _dlt_id

GOVERNANCERolle loader · GRANT INSERT ON SCHEMA raw · append-only, kein UPDATE

Prozess 02dbt: SELECT über alle Layertransform · materialize

raw.orderssrc

dbt SELECT

stg.stg_orders–

view · umbenannt & typisiert

dbt SELECT

int.int_orders–

view · Joins & Logik

dbt SELECT

mart.fct_otif–

incremental · OTIF, fill rate

GOVERNANCERolle transformer · SELECT raw/int · CREATE int/mart · Tests & Contracts zwischen Layern

Prozess 03Metabase fragt mart abBI · read-only

BI-ToolMetabaseDashboard-Query

SELECT

mart.fct_otifread

aggregate

OTIF

GOVERNANCERolle bi_read · GRANT SELECT ON SCHEMA mart · kein Zugriff auf raw/int

“Ein Schema ist eine Grenze, keine Konvention.”

— Governance by Design