# Pg_lake - Postgres에서 Iceberg 및 데이터 레이크 접근을 지원하는 확장

> Clean Markdown view of GeekNews topic #24162. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24162](https://news.hada.io/topic?id=24162)
- GeekNews Markdown: [https://news.hada.io/topic/24162.md](https://news.hada.io/topic/24162.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-11-05T23:32:46+09:00
- Updated: 2025-11-05T23:32:46+09:00
- Original source: [github.com/Snowflake-Labs](https://github.com/Snowflake-Labs/pg_lake)
- Points: 3
- Comments: 1

## Topic Body

- **pg_lake**은 Postgres를 기반으로 **Iceberg 테이블과 데이터 레이크 파일을 직접 통합**해 트랜잭션과 고속 쿼리를 지원하는 확장  
- S3 등 **객체 스토리지의 Parquet, CSV, JSON, Iceberg 파일을 직접 조회·가져오기·내보내기** 가능  
- **DuckDB 쿼리 엔진**을 내부적으로 활용해 Postgres 환경 내에서 빠른 실행 성능 확보  
- Iceberg 테이블 생성, 외부 파일 자동 스키마 추론, COPY 명령을 통한 S3 입출력 등 **데이터 레이크하우스 기능**을 단일 SQL 인터페이스로 제공  
- Snowflake가 2025년 Crunchy Data 인수 후 **오픈소스로 공개**, Postgres 생태계에서 데이터 레이크 통합을 확장하는 기반  
  
---  
### pg_lake 개요  
- **pg_lake**은 Iceberg 및 데이터 레이크 파일을 Postgres에 통합하는 확장 기능으로, Postgres를 독립형 **레이크하우스 시스템**으로 활용 가능  
  - Iceberg 테이블에 대한 트랜잭션 보장 및 빠른 쿼리 지원  
  - S3 등 객체 스토리지의 원시 데이터 파일 직접 접근 가능  
- 주요 기능  
  - Iceberg 테이블 생성·수정 및 다른 엔진에서 쿼리 가능  
  - Parquet, CSV, JSON, Iceberg 형식의 데이터 파일 조회 및 가져오기  
  - COPY 명령으로 쿼리 결과를 Parquet, CSV, JSON 형식으로 객체 스토리지에 내보내기  
  - GDAL이 지원하는 GeoJSON, Shapefile 등 **지리공간 데이터 형식** 읽기  
  - 반정형 데이터용 **내장 map 타입** 제공  
  - heap, Iceberg, 외부 파일을 **단일 SQL 쿼리에서 결합** 가능  
  - 외부 데이터 소스에서 **컬럼과 타입 자동 추론**  
  - **DuckDB 엔진**을 통한 고속 실행  
  
### 설치 및 구성  
- 설치 방법  
  - **Docker**를 이용한 간편 실행  
  - **소스 빌드**를 통한 수동 설치 또는 개발 환경 구축  
- 확장 생성 예시  
  ```sql  
  CREATE EXTENSION pg_lake CASCADE;  
  ```  
  - 관련 확장: `pg_lake_table`, `pg_lake_engine`, `pg_extension_base`, `pg_lake_iceberg`, `pg_lake_copy`  
- **pgduck_server**  
  - Postgres 와이어 프로토콜을 구현한 독립 프로세스로, 내부적으로 DuckDB를 사용  
  - 기본 포트 5332에서 동작하며 `psql`로 직접 접속 가능  
  - 주요 설정  
    - `--memory_limit`: 메모리 제한 (기본 시스템 메모리의 80%)  
    - `--init_file_path`: 시작 시 실행할 SQL 파일 지정  
    - `--cache_dir`: 원격 파일 캐시 디렉터리 지정  
- **S3 연결 설정**  
  - DuckDB의 secrets manager를 사용해 AWS/GCP 자격 증명 자동 인식  
  - Iceberg 테이블 저장 위치 지정 예시  
    ```sql  
    SET pg_lake_iceberg.default_location_prefix TO 's3://testbucketpglake';  
    ```  
  
### 사용 예시  
- **Iceberg 테이블 생성**  
  ```sql  
  CREATE TABLE iceberg_test USING iceberg AS   
  SELECT i as key, 'val_'|| i as val FROM generate_series(0,99)i;  
  ```  
  - 생성 후 `SELECT count(*) FROM iceberg_test;` 결과 100  
  - Iceberg 메타데이터 위치 확인 가능  
- **S3로 COPY 입출력**  
  ```sql  
  COPY (SELECT * FROM iceberg_test) TO 's3://.../iceberg_test.parquet';  
  COPY iceberg_test FROM 's3://.../iceberg_test.parquet';  
  ```  
  - Parquet, CSV, JSON 형식 지원  
- **S3 파일을 외부 테이블로 생성**  
  ```sql  
  CREATE FOREIGN TABLE parquet_table()   
  SERVER pg_lake   
  OPTIONS (path 's3://.../*.parquet');  
  ```  
  - 컬럼 자동 추론, 쿼리 가능 (`SELECT count(*) FROM parquet_table;` → 100)  
  
### 아키텍처  
- 구성 요소  
  - **PostgreSQL + pg_lake 확장**  
  - **pgduck_server** (DuckDB 실행 및 Postgres 프로토콜 구현)  
- 동작 방식  
  - 사용자는 Postgres에 접속해 SQL 실행  
  - 쿼리 일부는 DuckDB를 통해 병렬·컬럼 지향 방식으로 실행  
  - DuckDB를 Postgres 프로세스 내부에 임베드하지 않아 **스레드·메모리 안전성 문제 회피**  
  - 표준 Postgres 클라이언트를 통해 DuckDB 엔진에 직접 접근 가능  
  
### 구성 요소 세부 목록  
- **pg_lake_iceberg**: Iceberg 스펙 구현  
- **pg_lake_table**: 객체 스토리지 파일용 FDW 구현  
- **pg_lake_copy**: 데이터 레이크로 COPY 입출력 지원  
- **pg_lake_engine**: 공통 모듈  
- **pg_extension_base**: 다른 확장의 기반 구성요소  
- **pg_extension_updater**: 확장 자동 업데이트 기능  
- **pg_lake_benchmark**: 레이크 테이블 벤치마크 수행  
- **pg_map**: 일반화된 map 타입 생성기  
- **pgduck_server**: DuckDB를 로드해 Postgres 프로토콜로 노출하는 서버  
- **duckdb_pglake**: DuckDB에 Postgres 호환 함수 추가  
  
### 개발 및 공개 이력  
- 2024년 초 **Crunchy Data**에서 Iceberg를 Postgres에 도입하기 위해 개발 시작  
- 초기에는 DuckDB 통합 및 Crunchy Bridge 고객 대상 기능 제공  
- 이후 Iceberg v2 프로토콜과 트랜잭션 지원 구현  
- 2024년 11월 **Crunchy Data Warehouse**로 재출시  
- 2025년 6월 **Snowflake가 Crunchy Data 인수**, 2025년 11월 **pg_lake 오픈소스 공개**  
  - 초기 버전은 3.0 (이전 두 세대 포함)  
  - 기존 Crunchy Data Warehouse 사용자는 자동 업그레이드 경로 제공  
  
### 라이선스 및 의존성  
- **Apache 2.0 라이선스**  
- **Apache Avro** 및 **DuckDB** 프로젝트에 의존  
  - 빌드 시 Avro 및 DuckDB 확장에 패치 적용

## Comments



### Comment 45945

- Author: neo
- Created: 2025-11-05T23:32:46+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45812606) 
- 그냥 [Ducklake](https://ducklake.select/)을 쓰면 안 되는 이유가 있을까 하는 생각임  
  그렇게 하면 **복잡도 감소**가 가능함. 필요한 건 DuckDB와 PostgreSQL(pg_duckdb)뿐임  
  참고로 Prof. Hannes Mühleisen의 발표 영상 [DuckLake - The SQL-Powered Lakehouse Format for the Rest of Us](https://www.youtube.com/watch?v=YQEUkFWa69o)도 있음
  - DuckLake은 꽤 멋진 프로젝트임. 우리 팀도 DuckDB를 좋아함. 사실 pg_lake가 가능해진 것도 DuckDB 덕분임  
    DuckLake이 Iceberg 기반의 pg_lake가 못 하는 걸 할 수 있고, 반대로 Postgres는 DuckDB가 못 하는 걸 할 수 있음. 예를 들어 초당 10만 건 이상의 단일 행 삽입을 처리할 수 있음  
    **트랜잭션 처리**는 공짜가 아님. 엔진을 카탈로그 안에 넣는 대신 카탈로그를 엔진 안에 넣으면 분석용과 운영용 테이블 간 트랜잭션이 가능해짐  
    Postgres는 지속성(persistence)과 **연속 처리** 측면에서도 자연스러움. pg_cron과 PL/pgSQL을 이용해 오케스트레이션을 구성할 수 있음  
    또한 Iceberg는 여러 쿼리 엔진과의 상호운용성도 강점임
  - 결국 **설계 결정**의 문제임. 관련 논의는 [이 스레드](https://news.ycombinator.com/item?id=45813631)에서 볼 수 있음
  - 나도 Ducklake을 정말 좋아하려고 노력했지만, 실제로 써보면 **유지보수 문제**가 있었음. 특히 pg catalog 관련해서 Ducklake이 자체 생성한 파일에 대해 HTTP 400 오류를 던지는 경우가 있었음  
    내 데이터 쓰기 패턴(Polars DataFrame에서 Ducklake 테이블로 삽입) 때문인지, 파티션 테이블 구조 때문인지는 확실치 않음  
    개발/테스트 환경에서는 괜찮지만 팀 전체에서는 어려움이 있었음. 그래서 결국 Hive 파티션된 Parquet 파일과 DuckDB 뷰 조합으로 돌아감  
    나중에 이슈로 예시를 올릴 생각이지만, 지금은 다른 일들로 시간이 부족함
- 이건 정말 **큰 변화**임  
  예전엔 Postgres 시장에서 “오픈소스 Snowflake”가 없다고 말하곤 했음  
  Crunchy의 Postgres 확장은 현재 시장에서 가장 앞선 솔루션임. Snowflake와 Crunchy 팀이 오픈소스로 공개한 걸 축하함
  - 솔직히 말하면, 그냥 Snowflake에 돈을 내고 그 훌륭한 DB와 **에코시스템**을 활용하는 게 낫다고 생각함. 인프라가 고객 가치의 핵심이 아니라면 그 부분은 맡기고 멋진 걸 만드는 데 집중해야 함
- 나는 **데이터 레이크**와 SQL 유사 쿼리 언어를 좋아함. “모든 것은 파일이다” 철학의 진화된 형태처럼 느껴짐  
  Linux에서는 파일 시스템을 통해 시스템 설정을 읽고 쓸 수 있음 (`cat /sys/...`, `echo ... > /sys/...`)  
  FUSE를 이용하면 사용자 공간에서 파일 시스템 드라이버를 직접 구현할 수 있음. 예를 들어 SSH나 Google Drive를 마운트해서 `cp` 명령으로 복사 가능함  
  하지만 파일 시스템은 계층적 데이터에만 적합함. 현실 세계의 데이터는 대부분 **관계형 구조**임  
  데이터 레이크는 SQL이라는 우아한 추상화를 통해 서로 다른 데이터 소스를 하나의 관계형 데이터베이스처럼 다룰 수 있게 함  
  결국 많은 애플리케이션이 CRUD 중심이므로, 이런 접근은 훨씬 효율적임
- 당신은 데이터 레이크를 어떻게 쓰는가? 나에게는 단순 저장소가 아니라 **예측 불가능한 분석 작업**을 위한 공간임  
  이런 경우 Postgres는 한계가 있음. 더 많은 CPU와 RAM이 필요하고, 결국 **분산 엔진**이 필요함
  - 데이터 레이크의 핵심은 **컴퓨트와 스토리지의 분리**임. Postgres는 컴퓨트 계층이 아니라 접근 계층임  
    컴퓨트는 Postgres에 “이 키들의 현재 데이터는?” 혹은 “2주 전의 데이터는?”을 묻고, 실제 분석 쿼리는 Parquet 파일에서 직접 수행함
- Snowflake가 Crunchy Data를 인수했을 때, 이런 **매니지드 버전**을 제공하길 기대했음  
  로컬 Docker로 실행할 수 있는 건 좋지만, AWS에서 Snowflake 계정으로 통합 청구되는 형태로 운영할 수 있으면 좋겠음
- 지금은 정말 **PostgreSQL의 황금기**라고 느껴짐
- 나는 데이터 엔지니어는 아니지만 관련 분야에서 일함. 이게 어떤 문제를 해결하는지 **쉽게 설명**해줄 수 있는 사람이 있을까 궁금함
  - 예를 들어 어떤 서비스가 S3에 Parquet 파일로 로그 데이터를 쌓는다고 하자. 이 데이터를 Postgres에서 바로 쿼리하고 싶을 때 pg_lake가 유용함  
    Parquet 데이터를 Postgres로 불러와 쿼리할 수 있고, 기존 테이블과 **조인**도 가능함
- 두 가지 질문이 있음  
  (1) Iceberg 대신 Ducklake 스펙을 사용하도록 호환 계획이 있는가? Ducklake은 카탈로그를 파일이 아닌 SQL 테이블로 관리해 **동시 쓰기**나 스냅샷 관리가 더 간단함  
  (2) pg_duckdb가 시간이 지나면 같은 기능을 하게 될 가능성이 있는가?
  - (1) 고려는 했지만 현재 계획은 없음. Ducklake을 그대로 쓰기보다는 Postgres 내부에서 직접 구현해 **트랜잭션 경계**를 유지하고 싶음  
    다만 인라인 데이터 처리 등 복잡성이 있음. 이를 해결하면 높은 트랜잭션 성능을 얻을 수 있음  
    (2) pg_duckdb는 Ducklake 구현을 재사용하기 더 쉽지만, 리소스 관리나 안정성 측면에서는 그 구조가 덜 적합하다고 봄
- S3 Table Buckets, Cloudflare R2 Data Catalog, 그리고 이번 프로젝트까지 보면 **Iceberg가 승리**하는 분위기임
- Postgres Wire 호환 DB로 데이터를 쉽게 적재하고 싶다면 [sling-cli](https://github.com/slingdata-io/sling-cli)를 추천함  
  CLI, YAML, Python으로 **ETL 작업**을 실행할 수 있음