Snowflake JapanPublicationへの投稿
🐢

はじめての pg_lake 2025/12月版

tsho
に公開
Docker
Snowflake
PostgreSQL
DuckDB
Iceberg
tech

この記事は「Iceberg Advent Calendar 2025」の 25 日目の記事です。

https://qiita.com/advent-calendar/2025/iceberg

1. はじめに

2025/11月に Snowflake BUILD の年次テックカンファレンス　キーノートのアナウンスとともに Github に公開された PostgreSQL に統合できる pg_lake というオープンソースがリリースしました。リリースから数日で 1,200 Starを超え、Hackers news のリリース当日のコメントや投稿数は TOP1 (著者調べ) となりその注目度が伺えます。本記事では 2025/12/24 現在の pg_lake をお試しするまでの流れを実際に試した方法をまとめたいと思います。

本記事の一部は、Snowflake Postgres チームをリードしている Craig より pg_lake 公開時に blog を公開しており、pg_lakeの道のりがありましたので、非公式ですがその一部を翻訳したものをつかいつつ紹介したいと思います。

2. pg_lakeの背景と目的

2.1 pg_lake への道のり

pg_lake の物語は、ある単純な観察から始まりました。開発チーム（当初は Crunchy Data、現在は Snowflake 所属）は、PostGIS、Citus、pg_cron、pg_partman など、多くの基本的な Postgres 拡張機能を構築してきた深い歴史を持っています。この背景により、チームは顧客が繰り返し直面する課題を最前線で目の当たりにしていました。それは、「データが Postgres データベースとオブジェクトストレージに分断されており、そのギャップを埋めることが常に困難である」という課題です。

チームは、ネイティブで直感的なPostgres体験によってこれに対処できると確信していました。

Crunchy Data はこの機能への投資を決定し、18ヶ月以上前に Crunchy Bridge for Analytics を最初に立ち上げたとき、他のソリューションは事実上存在しませんでした。当時は意識していませんでしたが、チームはトランザクション機能と分析機能を組み合わせたデータプラットフォームの一部として Postgres を使用する動きを構築する手助けをしていました。この分野が成熟し、Crunchy Data が Snowflake に買収され Snowflake Postgres が立ち上げられると、Postgresをより相互運用可能にし、分析と統合することの価値は否定できないものとなりました。

2.2 なぜオープンソース化したのか？

Postgres が現代のデータスタックの核心的なコンポーネントであると信じています。それは単なるリレーショナルデータベース以上のものです。JSON、地理空間（PostGIS）、ベクトル検索（pgvector）のための強力な機能を備えた Postgres は、すでにオペレーショナル（運用）データプラットフォームとなっています。一方で、データレイクハウスは、分析データを大規模に管理するための標準として浮上してきました。

また、企業が最新のアプリケーションや顧客体験を提供するために、運用機能と分析機能を組み合わせて使用するケースが増えていることも確認しています。Snowflake はこれを行うための優れたデータプラットフォームを提供しており、Postgres の機能を拡張することで、より多くの人々が現代的なデータ駆動型およびAI駆動型のエージェントやアプリケーションを開発する力を得られるようになると確信しています。

この技術をオープンソース化することで、私たちは以下のことを目指しています：

  • 標準の確立: エコシステム全体に利益をもたらす、より統一された Postgres のための堅牢なオープンスタンダードの作成を支援したいと考えています。

  • 開発者のエンパワーメント: 現代のアプリケーションと AI は、運用機能と分析機能の融合を求めています。pg_lake を使えば、Postgres コミュニティは新しいユースケースを切り開き、イノベーションを加速させることができるでしょう。

  • Postgres へのコミットメント: Snowflake は Postgres の成功に深くコミットしています。このリリースは、世界で最も愛されているオープンソースデータベースで何が可能かという境界を押し広げる、私たちのコミットメントの証です。

3. pg_lakeの特徴

pg_lake を使用すると、標準的な SQL を使って Iceberg テーブルへのクエリ、管理、書き込みが可能になります。Crunchy Dataは、今年初めに Snowflake に参加する前、数年をかけて pg_lake を開発し、エンタープライズ向けウェアハウス製品の基盤としてきました。pg_lake は、Postgres に新たな分析機能をもたらした Crunchy Bridge for Analytics（後に Crunchy Data Warehouse となりました）を支えていた技術です。その同じ機能を Apache ライセンスの下でオープンソース化し、より広い Postgres コミュニティが恩恵を受けられるようにしました。

これにより、Postgres を使って以下のことが可能になります：

  • Iceberg テーブルを Postgres で直接管理： pg_lake は、Postgres 自体がカタログとして機能する新しい Iceberg テーブルタイプを導入します。つまり、完全な Postgres のトランザクションの挙動を維持したまま、簡単かつ安価に、そして耐久性のある形でIceberg テーブルを Postgres から直接作成できます。

  • データレイク内の生データファイルへのクエリ： 多くのデータレイクは、S3 にある CSV/JSON/Parquet ファイルで構成されており、異なるシステム間でやり取りされています。pg_lake を使えば、S3 に既にあるデータファイルやディレクトリを簡単にクエリしたり、それらを Iceberg テーブルに挿入したりできます。また、外部の Iceberg テーブル、さまざまな地理空間ファイル形式へのクエリも可能です。

  • 柔軟なデータのインポート/エクスポート： S3 バケットや http(s) URL からデータを直接 Iceberg や通常の Postgres テーブルにロードできます。また、クエリ結果を S3 に書き戻して、高度なデータパイプラインを作成することも可能です。

4. セットアップ方法 - Docker

セットアップ方法は 2025/12/24 現在、Docker とソースから開発する２つが用意されており、本記事は Docker セットアップの方法を確認します。

4.1 認証情報の連携

AWS S3 などを使う場合、それぞれの認証情報を ~/.aws/ などに格納しておきます。

S3 の場合は、docker-compose.yml の pdduck-server の volumes に - ${HOME}/.aws:/home/postgres/.aws:ro を追加する (今後修正されるかもしれないので暫定対応です)。

  pgduck-server:
    image: pgduck-server:local
    pull_policy: if_not_present
    container_name: pgduck-server
    volumes:
      - ./scripts/entrypoint-pgduck-server.sh:/entrypoint-pgduck-server.sh
      - ./scripts/init-pgduck-server.sql:/init-pgduck-server.sql
      - pgduck-unix-socket-volume:/home/postgres/pgduck_socket_dir
      - pg-shared-tmp-dir-volume:/home/postgres/pgsql-${PG_MAJOR:-18}/data/base/pgsql_tmp
      - ${HOME}/.aws:/home/postgres/.aws:ro

4.2 Docker Image の Build

pg_lake のレポジトリをcloneし、dockerディレクトリへ移動し、Docker.fileの内容をbuildします。build する際にリリース当初は Docker 割当に 4GB 以上のメモリが必要など負担が大きかったのですが、現在は軽量化し、負担は以前より減っております。

go-taskをつかっていますので、もしない場合は brew install go-task （Mac 環境）などで事前にインストールしてください。

cd pg_lake/docker

task compose:up

まだ検討中ですが、docker-hubでのイメージ公開も検討しておりますので続報をおまちいただければと思います。
pg_lake/docker/.volumes の作成権限がたりず一度おちるかもしれませんが、二度目に作成たちがえることができました。

4.3 pg_lakeにログイン

pg_lake dockerにログインし、pg_lakeでデータを iceberg 関連ファイルを保存する場所を選びます。今回は S3 のhogehoge バケットを使う想定で動かします。

docker exec -it pg_lake bash

psql -U postgres

SET pg_lake_iceberg.default_location_prefix TO 's3://hogehoge';

4.4 iceberg テーブルの作成

pg_lake で postgres にログイン後下記コマンドを実施する。

CREATE TABLE iceberg_test_ja USING iceberg AS
  SELECT 
    i as key
    , 'Iceberg アドベントカレンダー 2025 値_'|| i  as val
  FROM 
    generate_series(0,99)i
;

SELECT 
  *
FROM
  iceberg_test_ja
;

SELECT
  table_name
  , metadata_location
FROM
  iceberg_tables;

4.5 既存の iceberg テーブルから Postgres に読み込む

事前に hogehoge バケットにparquetのデータがはいっている場合はそちらを読み込めす。4.5で作成したファイルを読み込んでみましょう。

CREATE FOREIGN TABLE parquet_table_ja() 
SERVER pg_lake 
OPTIONS (path 's3://hogehoge/parquet_data/iceberg_test_ja.parquet');


SELECT 
  *
FROM
  parquet_table_ja
;

4.6 docker の停止

task compose:down

以上で pg_lake で iceberg テーブルを読み書きする方法を記載しました。もっと詳しい内容を確認したい場合は、README.mdなどをご確認ください。

5. 実際の使用例

リリースしたばかりなのでまだこれからユーザは増えると思いますが、先に記載したとおり pg_lake は Crunchy Data Warehouse の発展版であり、Crunchy Data Warehouse は Third Iron に使われていたので、実質 pg_lake の広義のユーザーとしていえるでしょう。下記のブログによると、他のプロダクトより複雑性は減り、クエリ実行時間はは数時間から数10分,数分になったようです。

Third Iron Chooses Crunchy Data Warehouse Over Amazon Athena

6. まとめ

いかがでしたでしょうか？もしすこしでも興味をもっていただけたなら幸いです。リリース直後より使いやすくなりましたのでよかったらお手元でもお試しください。

Reference

Snowflake Japan
Snowflake JapanPublication

Snowflake に関する最新の技術情報をお届けします。 ※この Publication は Snowflake Japan オフィスに所属する個人の見解であり、所属する組織の公式見解ではありません。

Discussion