Snowflake Postgres und pg_lake: Echtzeit-Datenmirroring ohne ETL-Pipelines
trending_up Trend: snowflake

Snowflake Postgres und pg_lake: Echtzeit-Datenmirroring ohne ETL-Pipelines

calendar_month 23. Juni 2026 update Aktualisiert: 25. Juni 2026

🔄 Update — 25. Juni 2026: pg_lake wird Open Source und ermöglicht Postgres-Lakehouses

Die Postgres-Erweiterung pg_lake, die das Zero-ETL-Mirroring ermöglicht, wurde als Open-Source-Projekt veröffentlicht. Entwickler können nun PostgreSQL-Datenbanken direkt an Apache Iceberg und Data Lakehouses anbinden, um Iceberg-Tabellen nativ mit Standard-SQL zu verwalten und abzufragen.

Was ist neu?

  • Open-Source-Freigabe: pg_lake ist nun als Open-Source-Erweiterung frei verfügbar und lässt sich in beliebige selbstgehostete oder Cloud-basierte PostgreSQL-Umgebungen integrieren.
  • Nativer Lakehouse-Anschluss: PostgreSQL kann nun ohne externe Replikations-Tools oder ETL-Pipelines direkt auf Apache Iceberg-Tabellen in Cloud-Objektspeichern wie AWS S3 schreiben und lesen.
  • DuckDB-Sidecar-Integration: Die Erweiterung nutzt im Hintergrund eine DuckDB-Engine, um komplexe analytische Abfragen auf Objektspeichern hocheffizient auszuführen.

Warum es den Artikel ergänzt

Diese Freigabe erweitert das zuvor exklusive Snowflake-Postgres-Mirroring auf das gesamte PostgreSQL-Ökosystem und ermöglicht es jedem Entwickler, Zero-ETL-Architekturen eigenständig aufzubauen.


Zusammenfassung

Snowflake hat einen neuen managed PostgreSQL-Datenbankdienst namens “Snowflake Postgres” angekündigt. Ein zentrales Highlight dieser Version ist das pipeline-freie Echtzeit-Datenmirroring, das durch die Open-Source-Erweiterung pg_lake ermöglicht wird. Diese Architektur erlaubt es Unternehmen, die Lücke zwischen transaktionalen OLTP-Datenbanken und analytischen Data Lakehouses zu schließen, indem PostgreSQL-Daten direkt im Apache Iceberg-Format auf Cloud-Objektspeichern abgelegt werden.

Was ist passiert?

  • Produktankündigung: Snowflake Postgres wurde als vollständig verwalteter Dienst mit 99,95 % Uptime-SLAs, Connection Pooling und integrierten Erweiterungen wie pg_vector und PostGIS gestartet.
  • pg_lake-Integration: Die ursprünglich von Crunchy Data entwickelte Erweiterung pg_lake ist nun nativ integriert. Sie ermöglicht es PostgreSQL, Daten direkt im offenen Apache Iceberg-Format zu schreiben und zu verwalten.
  • Zero-ETL-Mirroring: Operative Datenbanktabellen werden in Iceberg-Tabellen gespiegelt. Da Snowflake Iceberg-Tabellen nativ lesen kann, entfällt der Bedarf für separate ETL-Pipelines oder Replikations-Gateways vollständig.
  • Sicherstellung der Transaktionssicherheit: Datenübertragungen in das Data Lakehouse folgen den ACID-Semantiken von PostgreSQL. Scheitert das Schreiben in den Data Lake, wird auch die Postgres-Transaktion zurückgerollt.

Warum es wichtig ist

Das Verwalten von Datenpipelines zwischen operativen Datenbanken (OLTP) und analytischen Warehouses (OLAP) ist eine der größten Fehlerquellen in modernen Datenarchitekturen. Snowflake Postgres bricht diese Barriere auf, indem es ein gemeinsam genutztes Speicher-Repository etabliert. Entwickler können Standard-SQL verwenden (z. B. CREATE TABLE ... USING iceberg), während Dateningenieure und KI-Modelle in Snowflake sofortigen Zugriff auf frische Daten für Cortex AI und Machine Learning erhalten.

Beweise

  • Blogbeitrag: Snowflake beschreibt das Postgres-Mirroring detailliert im offiziellen Blog unter dem Titel Snowflake Postgres Unifies Your Apps, Analytics and AI.
  • Produktankündigung: Weitere Details zur Engine und den dazugehörigen compute-optimierten Ankünftigungen wurden im Snowflake AI Pulse – June 2026 Product Announcements veröffentlicht.
  • Architektonische Details: pg_lake nutzt im Hintergrund hocheffiziente Abfrage-Engines (wie DuckDB), um Lese- und Schreibvorgänge auf Objektspeichern ohne Leistungseinbußen durchzuführen.

Analyse

Die Einführung von pg_lake markiert eine strategische Wende hin zu “Zero-ETL”-Architekturen, bei denen das offene Tabellenformat Apache Iceberg als Brücke dient. Durch das Schreiben von Parquet-Dateien direkt aus der Datenbank-Engine heraus entfällt die Latenz und Komplexität von CDC-Tools (Change Data Capture). Die größte Herausforderung bleibt jedoch die Leistung: Das Schreiben in Objektspeicher ist inhärent langsamer als lokale SSD-Schreibvorgänge. Obwohl pg_lake DuckDB für Pufferung und Optimierung nutzt, muss sich das System unter extrem hohen Transaktionsraten erst noch im Live-Betrieb bewähren.

Praktische Erkenntnisse

  1. Pipeline-Reduktion: Evaluieren Sie Snowflake Postgres für neue Projekte, um den Wartungsaufwand für externe CDC-Tools wie Debezium zu minimieren.
  2. Iceberg als Standard: Nutzen Sie offene Tabellenformate (Apache Iceberg) für die Datenablage, um Vendor-Lock-ins zu vermeiden und Multicloud-Kompatibilität zu sichern.
  3. KI-Bereitschaft: Nutzen Sie die direkt gespiegelten Daten in Snowflake für Cortex AI, ohne auf nächtliche Batch-Läufe warten zu müssen.

Offene Fragen

  • Wie stark beeinträchtigt das parallele Schreiben in den Objektspeicher via pg_lake die OLTP-Schreiblatenz bei massiven Transaktionsvolumina?
  • Welche Lizenz- und Hosting-Kosten entstehen für den Betrieb von Snowflake Postgres im Vergleich zu Standard-RDS?

Quellen

  1. Snowflake Postgres Unifies Your Apps, Analytics and AI
  2. Snowflake AI Pulse – June 2026 Product Announcements