Pg_lake – Erweiterung für den Zugriff auf Iceberg und Data Lakes aus Postgres

 (github.com/Snowflake-Labs)
3 Punkte von GN⁺ 2025-11-05 | 1 Kommentare | Auf WhatsApp teilen
  • pg_lake ist eine Erweiterung, die auf Postgres basiert und Iceberg-Tabellen sowie Data-Lake-Dateien direkt integriert, um Transaktionen und schnelle Abfragen zu unterstützen
  • Parquet-, CSV-, JSON- und Iceberg-Dateien in Objektspeichern wie S3 können direkt abgefragt, importiert und exportiert werden
  • Nutzt intern die DuckDB Query Engine, um in der Postgres-Umgebung eine hohe Ausführungsgeschwindigkeit zu erreichen
  • Bietet Lakehouse-Funktionen wie das Erstellen von Iceberg-Tabellen, automatische Schema-Inferenz für externe Dateien und S3-Ein-/Ausgabe über den COPY-Befehl über eine einzige SQL-Schnittstelle
  • Nach der Übernahme von Crunchy Data durch Snowflake im Jahr 2025 als Open Source veröffentlicht und dient als Grundlage für die Erweiterung der Data-Lake-Integration im Postgres-Ökosystem

Überblick über pg_lake

  • pg_lake ist eine Erweiterung zur Integration von Iceberg- und Data-Lake-Dateien in Postgres, wodurch sich Postgres als eigenständiges Lakehouse-System nutzen lässt
    • Gewährleistet Transaktionen für Iceberg-Tabellen und unterstützt schnelle Abfragen
    • Ermöglicht direkten Zugriff auf Rohdatendateien in Objektspeichern wie S3
  • Hauptfunktionen
    • Iceberg-Tabellen erstellen und ändern sowie von anderen Engines aus abfragen
    • Datendateien in den Formaten Parquet, CSV, JSON und Iceberg abfragen und importieren
    • Abfrageergebnisse per COPY-Befehl in den Formaten Parquet, CSV und JSON in Objektspeicher exportieren
    • Geodatenformate wie GeoJSON und Shapefile lesen, die von GDAL unterstützt werden
    • Stellt einen integrierten map-Typ für semistrukturierte Daten bereit
    • Kann heap, Iceberg und externe Dateien in einer einzigen SQL-Abfrage kombinieren
    • Automatische Inferenz von Spalten und Typen aus externen Datenquellen
    • Hohe Ausführungsgeschwindigkeit durch die DuckDB-Engine

Installation und Konfiguration

  • Installationsmethoden
    • Einfacher Start mit Docker
    • Manuelle Installation oder Aufbau einer Entwicklungsumgebung über Source Build
  • Beispiel zum Erstellen der Erweiterung 
    CREATE EXTENSION pg_lake CASCADE;
    • Zugehörige Erweiterungen: pg_lake_table, pg_lake_engine, pg_extension_base, pg_lake_iceberg, pg_lake_copy
  • pgduck_server
    • Ein eigenständiger Prozess, der das Postgres-Wire-Protokoll implementiert und intern DuckDB verwendet
    • Läuft standardmäßig auf Port 5332 und kann direkt mit psql angesprochen werden
    • Wichtige Einstellungen
      • --memory_limit: Speicherlimit (standardmäßig 80 % des Systemspeichers)
      • --init_file_path: gibt die SQL-Datei an, die beim Start ausgeführt werden soll
      • --cache_dir: gibt das Verzeichnis für den Remote-Datei-Cache an
  • S3-Verbindung konfigurieren
    • Verwendet den Secrets Manager von DuckDB zur automatischen Erkennung von AWS-/GCP-Anmeldedaten
    • Beispiel zum Festlegen des Speicherorts für Iceberg-Tabellen 
      SET pg_lake_iceberg.default_location_prefix TO 's3://testbucketpglake';

Anwendungsbeispiele

  • Iceberg-Tabelle erstellen 
    CREATE TABLE iceberg_test USING iceberg AS   
SELECT i as key, 'val_'|| i as val FROM generate_series(0,99)i;
    • Nach dem Erstellen liefert SELECT count(*) FROM iceberg_test; den Wert 100
    • Der Speicherort der Iceberg-Metadaten kann überprüft werden
  • COPY-Ein-/Ausgabe nach S3 
    COPY (SELECT * FROM iceberg_test) TO 's3://.../iceberg_test.parquet';  
COPY iceberg_test FROM 's3://.../iceberg_test.parquet';
    • Unterstützt die Formate Parquet, CSV und JSON
  • S3-Dateien als externe Tabelle erstellen 
    CREATE FOREIGN TABLE parquet_table()   
SERVER pg_lake   
OPTIONS (path 's3://.../*.parquet');
    • Automatische Spalteninferenz und abfragbar (SELECT count(*) FROM parquet_table; → 100)

Architektur

  • Komponenten
    • PostgreSQL + pg_lake-Erweiterung
    • pgduck_server (führt DuckDB aus und implementiert das Postgres-Protokoll)
  • Funktionsweise
    • Nutzer verbinden sich mit Postgres und führen SQL aus
    • Teile der Abfragen werden über DuckDB parallel und spaltenorientiert ausgeführt
    • DuckDB wird nicht in den Postgres-Prozess eingebettet, wodurch Probleme mit Thread- und Speichersicherheit vermieden werden
    • Direkter Zugriff auf die DuckDB-Engine über Standard-Postgres-Clients möglich

Detaillierte Komponentenliste

  • pg_lake_iceberg: Implementierung der Iceberg-Spezifikation
  • pg_lake_table: Implementierung eines FDW für Dateien in Objektspeichern
  • pg_lake_copy: Unterstützt COPY-Ein-/Ausgabe für Data Lakes
  • pg_lake_engine: Gemeinsames Modul
  • pg_extension_base: Basiskomponente für andere Erweiterungen
  • pg_extension_updater: Funktion zur automatischen Aktualisierung von Erweiterungen
  • pg_lake_benchmark: Führt Benchmarks für Lake-Tabellen aus
  • pg_map: Generator für einen generalisierten map-Typ
  • pgduck_server: Server, der DuckDB lädt und über das Postgres-Protokoll bereitstellt
  • duckdb_pglake: Fügt DuckDB Postgres-kompatible Funktionen hinzu

Entwicklungs- und Veröffentlichungshistorie

  • Anfang 2024 begann Crunchy Data mit der Entwicklung, um Iceberg in Postgres einzuführen
  • Anfangs lag der Fokus auf der DuckDB-Integration und der Bereitstellung von Funktionen für Crunchy-Bridge-Kunden
  • Später wurden das Iceberg-v2-Protokoll und Transaktionsunterstützung implementiert
  • Im November 2024 als Crunchy Data Warehouse neu veröffentlicht
  • Im Juni 2025 übernahm Snowflake Crunchy Data, im November 2025 wurde pg_lake als Open Source veröffentlicht
    • Die erste Version ist 3.0 (einschließlich der beiden vorherigen Generationen)
    • Für bestehende Nutzer von Crunchy Data Warehouse wird ein automatischer Upgrade-Pfad bereitgestellt

Lizenz und Abhängigkeiten

  • Apache-2.0-Lizenz
  • Abhängig von den Projekten Apache Avro und DuckDB
    • Beim Build werden Patches auf Avro und DuckDB-Erweiterungen angewendet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-11-05
Hacker-News-Kommentare
  • Ich frage mich, ob es einen Grund gibt, nicht einfach DuckLake zu verwenden
    Damit ließe sich die Komplexität reduzieren. Man braucht nur DuckDB und PostgreSQL (pg_duckdb)
    Zur Referenz gibt es auch den Vortrag von Prof. Hannes Mühleisen: DuckLake - The SQL-Powered Lakehouse Format for the Rest of Us
    • DuckLake ist ein ziemlich cooles Projekt. Unser Team mag DuckDB ebenfalls. Tatsächlich ist pg_lake überhaupt erst dank DuckDB möglich geworden
      DuckLake kann Dinge, die das Iceberg-basierte pg_lake nicht kann, und umgekehrt kann Postgres Dinge, die DuckDB nicht kann. Zum Beispiel mehr als 100.000 Single-Row-Inserts pro Sekunde verarbeiten
      Transaktionsverarbeitung ist nicht gratis. Wenn man statt der Engine im Katalog den Katalog in die Engine packt, werden Transaktionen zwischen analytischen und operativen Tabellen möglich
      Postgres fühlt sich auch in Bezug auf Persistenz und kontinuierliche Verarbeitung natürlicher an. Mit pg_cron und PL/pgSQL kann man Orchestrierung aufbauen
      Außerdem ist Iceberg stark bei der Interoperabilität mit mehreren Query-Engines
    • Am Ende ist es eine Frage der Designentscheidung. Die zugehörige Diskussion findet sich in diesem Thread
    • Ich wollte DuckLake wirklich mögen, aber in der Praxis gab es Wartungsprobleme. Vor allem beim pg catalog warf DuckLake bei selbst erzeugten Dateien manchmal HTTP-400-Fehler
      Ich bin nicht sicher, ob das an meinem Schreibmuster lag (Einfügen aus einem Polars-DataFrame in eine DuckLake-Tabelle) oder an der Struktur partitionierter Tabellen
      In Entwicklungs-/Testumgebungen war es okay, aber teamweit war es schwierig. Deshalb bin ich am Ende wieder bei einer Kombination aus Hive-partitionierten Parquet-Dateien und DuckDB-Views gelandet
      Ich plane später ein Beispiel als Issue zu posten, aber im Moment fehlt mir wegen anderer Dinge die Zeit
  • Das ist wirklich eine große Veränderung
    Früher sagte man im Postgres-Markt oft, es gebe kein „Open-Source-Snowflake“
    Die Postgres-Erweiterung von Crunchy ist derzeit die fortschrittlichste Lösung auf dem Markt. Glückwunsch an Snowflake und das Crunchy-Team zur Open-Source-Veröffentlichung
    • Ehrlich gesagt denke ich, dass es besser ist, einfach für Snowflake zu bezahlen und diese großartige DB samt Ökosystem zu nutzen. Wenn Infrastruktur nicht der Kern des Kundennutzens ist, sollte man das auslagern und sich darauf konzentrieren, etwas Großartiges zu bauen
  • Ich mag Data Lakes und SQL-ähnliche Query-Sprachen. Es fühlt sich wie eine weiterentwickelte Form der Philosophie „Alles ist eine Datei“ an
    Unter Linux kann man Systemeinstellungen über das Dateisystem lesen und schreiben (cat /sys/..., echo ... > /sys/...)
    Mit FUSE kann man Dateisystemtreiber direkt im User Space implementieren. Man kann zum Beispiel SSH oder Google Drive mounten und dann mit dem cp-Befehl kopieren
    Allerdings eignen sich Dateisysteme nur für hierarchische Daten. Die meisten Daten der realen Welt haben eine relationale Struktur
    Data Lakes erlauben es, über die elegante Abstraktion von SQL unterschiedliche Datenquellen wie eine einzige relationale Datenbank zu behandeln
    Da viele Anwendungen letztlich CRUD-zentriert sind, ist so ein Ansatz deutlich effizienter
  • Wie nutzt ihr einen Data Lake? Für mich ist er nicht bloß ein Speicher, sondern ein Ort für unvorhersehbare Analyseaufgaben
    In solchen Fällen hat Postgres Grenzen. Man braucht mehr CPU und RAM und am Ende eine verteilte Engine
    • Der Kern eines Data Lake ist die Trennung von Compute und Storage. Postgres ist nicht die Compute-Schicht, sondern die Zugriffsschicht
      Compute fragt Postgres: „Was sind die aktuellen Daten zu diesen Schlüsseln?“ oder „Wie sahen die Daten vor zwei Wochen aus?“, und die eigentlichen Analyseabfragen laufen direkt auf den Parquet-Dateien
  • Als Snowflake Crunchy Data übernommen hat, hatte ich gehofft, dass sie so eine Managed-Version anbieten würden
    Es ist schön, dass man das lokal mit Docker ausführen kann, aber es wäre gut, wenn man es auf AWS betreiben könnte, mit integrierter Abrechnung über ein Snowflake-Konto
  • Es fühlt sich gerade wirklich wie das goldene Zeitalter von PostgreSQL an
  • Ich bin kein Data Engineer, arbeite aber in einem angrenzenden Bereich. Ich frage mich, ob jemand einfach erklären kann, welches Problem das löst
    • Angenommen, ein Dienst legt Logdaten als Parquet-Dateien in S3 ab. Wenn man diese Daten direkt aus Postgres heraus abfragen möchte, ist pg_lake nützlich
      Man kann Parquet-Daten in Postgres einlesen und abfragen und sie auch mit bestehenden Tabellen joinen
  • Ich habe zwei Fragen
    (1) Gibt es Pläne für Kompatibilität mit der DuckLake-Spezifikation statt Iceberg? DuckLake verwaltet den Katalog über SQL-Tabellen statt über Dateien, was gleichzeitige Schreibvorgänge und Snapshot-Verwaltung vereinfacht
    (2) Könnte pg_duckdb mit der Zeit auf dieselbe Funktionalität hinauslaufen?
    • (1) Wir haben darüber nachgedacht, aber aktuell gibt es keine Pläne. Statt DuckLake unverändert zu verwenden, möchten wir es direkt in Postgres implementieren, um die Transaktionsgrenzen beizubehalten
      Es gibt allerdings Komplexität, etwa bei der Verarbeitung von Inlinedaten. Wenn wir das lösen, können wir hohe Transaktionsleistung erreichen
      (2) Für pg_duckdb ist es leichter, die DuckLake-Implementierung wiederzuverwenden, aber in Bezug auf Ressourcenverwaltung und Stabilität halte ich diese Struktur für weniger geeignet
  • Wenn man sich S3 Table Buckets, den Cloudflare R2 Data Catalog und dieses Projekt ansieht, wirkt es, als würde Iceberg gewinnen
  • Wenn du Daten einfach in eine Postgres-Wire-kompatible DB laden willst, empfehle ich sling-cli
    Man kann ETL-Jobs per CLI, YAML und Python ausführen