Snowflake Postgres와 pg_lake로 구성하는 HTAP 데이터 아키텍처

Snowflake는 2025년 6월 Crunchy Data를 약 2.5억 달러에 인수했고, 2026년 2월 Snowflake Postgres를 GA(General Availability)로 출시했다. 2025년 11월 BUILD에서 공개된 퍼블릭 프리뷰를 거쳐 나온 이 서비스는 OLTP 트랜잭션과 OLAP 분석을 같은 컴퓨트·거버넌스 레이어에서 다루는 HTAP(Hybrid Transactional/Analytical Processing) 구성을 겨냥한다.

핵심은 Postgres와 Snowflake 분석 환경이 Apache Iceberg 데이터 레이크를 함께 활용한다는 점이다. 별도의 ETL 없이 동일 데이터에서 트랜잭션과 분석을 병행하며, 하이브리드 워크로드에서는 최대 3배 처리량 향상을 제시한다.

Crunchy Data 인수가 만든 확장 경로

이 인수는 Databricks의 Neon 인수, 즉 서버리스 Postgres 전략에 대응하는 성격을 가진다. Snowflake는 분석 중심 클라우드에서 OLTP와 에이전트 AI 플랫폼까지 범위를 넓히고, 오픈소스 PostgreSQL 생태계를 플랫폼 안으로 가져오는 방향을 택했다.

PostgreSQL의 개방적인 라이선스와 Snowflake의 엔터프라이즈 거버넌스를 결합하면, 에이전트 AI가 실시간 트랜잭션 데이터에 접근할 수 있다. 전면적인 리프트-앤-시프트보다 pg_lake를 거치는 점진적 도입을 경로로 제시하는 것도 이 구조의 특징이다.

Moor Insights와 Gartner 분석에 따르면 엔터프라이즈 AI 파일럿의 30%가 Postgres-Snowflake 통합을 채택할 전망이며, 신규 레이크하우스 배포의 20%는 pg_lake 기반으로 구축될 것으로 예측된다.

Postgres와 Warehouse가 만나는 지점

⤢✕

Snowflake Postgres는 OLTP 엔진을 맡고, Snowflake Warehouse는 분석 쿼리를 처리한다. 두 경로는 pg_lake를 통해 Iceberg 오픈 테이블 포맷을 공유하며, Snowflake Horizon은 두 워크로드에 공통 거버넌스 레이어를 제공한다.

컴퓨트와 스토리지는 분리돼 있다. Postgres 인스턴스는 트래픽에 따라 동적으로 확장·축소하고, 데이터는 S3·GCS·Azure Blob 같은 객체 스토리지에 Iceberg 포맷으로 영속화한다. 같은 스토리지를 OLTP와 OLAP 엔진이 함께 쓰되 컴퓨트는 격리한다.

스토리지에는 저비용 객체 스토리지를 사용하고 컴퓨트는 필요한 시점에 활성화한다. Iceberg 스냅샷을 기반으로 Point-in-Time 복구와 시간 여행(Time Travel)도 지원한다.

pg_lake가 연결하는 행 처리와 분석 처리

⤢✕

pg_lake는 Apache Iceberg를 기반으로 벤더 종속성을 낮춘다. Postgres와 Snowflake는 동일 Iceberg 테이블을 직접 쿼리하므로, ETL이나 별도 복제본을 두지 않고 데이터를 공유할 수 있다.

분석 쿼리는 컬럼형 DuckDB 엔진으로 투명하게 라우팅된다. 행 중심 OLTP 경로는 Heap Storage와 WAL/Journal을 사용하고, 분석 경로는 Parquet on Iceberg와 Snowflake Warehouse로 이어진다. pg_lake는 Snowflake-Labs/pg_lake로 GitHub에 공개돼 있다.

기존 PostgreSQL 워크로드의 호환 범위

Snowflake Postgres는 표준 PostgreSQL wire protocol을 완전히 지원한다. psycopg2, pgx, JDBC 등 기존 드라이버를 수정하지 않고 사용할 수 있다.

PostgreSQL 16+ 문법을 지원하며, PL/pgSQL 저장 프로시저·트리거·뷰도 호환 대상이다. PostGIS, pgvector, pg_cron 같은 주요 확장과 Crunchy Data의 엔터프라이즈 확장 번들도 포함한다.

이전 경로도 워크로드별로 나뉜다.

기존 PostgreSQL에서 옮길 때는 논리 복제(logical replication)를 사용한다.
RDS·Aurora Postgres에서는 pg_dump/pg_restore 또는 CDC 도구를 선택할 수 있다.

Horizon으로 묶는 권한과 감사

Snowflake Horizon은 OLTP 테이블과 OLAP 테이블의 메타데이터를 하나의 뷰에서 제공한다. Postgres 테이블과 Snowflake Warehouse 권한은 같은 Role 체계로 관리할 수 있다.

pg_lake를 경유하는 데이터 흐름은 계보 추적(Lineage) 대상이 된다. 규제 대응 근거를 확보하는 데 필요한 흐름이며, 동적 마스킹과 토큰화 정책도 OLTP·OLAP에 공통 적용한다. 접근 로그를 통합해 SOC2·GDPR·HIPAA 감사 근거를 일원화하는 구성이 가능하다.

워크로드별로 달라지는 전환 효과

워크로드 유형	기존 아키텍처	Snowflake Postgres 도입 효과
실시간 분석 대시보드	Postgres → Kafka → Snowflake (ETL)	pg_lake 직접 공유, 지연 제로
에이전트 AI 메모리	Postgres + Vector DB + RAG	단일 엔진에서 pgvector + 분석 결합
주문·결제 OLTP	Aurora Postgres	Snowflake 거버넌스·백업 통합
고객 360 뷰	DW + 배치 ETL	실시간 OLTP 데이터를 OLAP 쿼리
로그·이벤트 분석	Postgres + Parquet 변환	Iceberg 직접 저장, 즉시 쿼리

운영 전에 확인할 제약

OLTP 트랜잭션과 OLAP 분석에는 서로 다른 SLA 목표를 둬야 한다. 컴퓨트 크레딧과 스토리지 비용도 워크로드별로 분리해 예측할 필요가 있다.

논리 복제 기반 마이그레이션에서는 10초 내외 지연을 수용할 수 있는지 확인해야 한다. 네트워크는 PrivateLink로 데이터 유출을 차단하는 토폴로지를 검토하고, Iceberg 기반이라도 pg_lake 확장은 Snowflake 최적화가 주축이라는 점을 고려해야 한다.

PoC에서는 실제 트래픽 패턴으로 최대 3배 처리량 수치를 재현할 수 있는지 검증한다.

HTAP 경쟁이 향하는 곳

Databricks Lakebase는 Neon 인수를 기반으로 서버리스 Postgres를 제공하며 Snowflake와 직접 경쟁한다. AWS Aurora DSQL은 분산 Postgres 호환 서비스로 멀티 리전 OLTP를 강화하고, Google AlloyDB는 Postgres 호환성과 컬럼형 엔진을 내장한 HTAP 구성을 내세운다.

Snowflake의 차별점은 기존 AI Data Cloud 고객 기반을 Postgres로 확장한다는 데 있다. 2026년에는 레이크하우스 시장이 HTAP 방향으로 수렴하고 Iceberg 표준화도 가속될 전망이다.

Snowflake Postgres는 관리형 PostgreSQL 하나를 추가한 것보다, OLTP·OLAP을 단일 거버넌스·스토리지·컴퓨트 레이어로 엮는 구조에 가깝다. 기존 PostgreSQL을 운영하는 조직이라면 pg_lake를 통한 단계적 도입으로 리스크를 줄이면서 하이브리드 운영 전략을 검증할 수 있다.