Snowflake Postgres, Lakebase, and HorizonDB: 클라우드 네이티브 Postgres의 새로운 물결 탐색하기

데이터베이스 환경이 변화하고 있습니다. 지난 1년 동안 Snowflake, Databricks, Microsoft와 같은 세 개의 대형 데이터 플랫폼 제공업체가 "Postgres-flavored" 데이터베이스를 출시했습니다. 이들은 모두 PostgreSQL과의 wire-compatibility를 주장하지만, 커스텀 스토리지 레이어를 활용하고 "scale-out compute, shared storage" 아키텍처를 사용하는 등 기본 엔진과는 근본적으로 다릅니다.

이러한 서비스들—Snowflake Postgres, Databricks Lakebase, Azure HorizonDB—은 운영(OLTP)과 분석(OLAP) 워크로드 사이의 간극을 메우는 것을 목표로 합니다. 그러나 이들 사이의 선택은 단순히 기술적 우월성에 관한 것이 아니라, 여러분의 데이터가 이미 어디에 머물고 있는지에 관한 문제입니다.

Ecosystem Lock-In Framework

이러한 플랫폼을 평가할 때, 핵심 질문은 "어떤 데이터베이스가 가장 좋은가?"가 아니라 "어떤 데이터 플랫폼을 이미 표준으로 사용하고 있는가?"입니다.

  • Snowflake Users: 분석 웨어하우스가 Snowflake라면, Snowflake Postgres는 관리형 클라우드 네이티브 PG 경험을 위한 논리적인 선택입니다.
  • Databricks Users: 분석 플랫폼이 Databricks라면, Lakebase가 자연스러운 선택입니다.
  • Azure Shops: VM 관리에 지친 Azure 에코시스템에 깊이 투자한 사용자라면, HorizonDB가 깊이 통합된 대안을 제공합니다.

저자가 언급했듯이, 이러한 벤더들이 "운영 및 분석의 수렴"을 마케팅하고 있지만, 이 수렴은 오직 그들만의 독점적인 장벽 안에서만 일어납니다. 이러한 플랫폼 간에 데이터를 이동하는 것은 여전히 클라우드 egress fees로 인해 비용이 많이 드는 작업입니다.

Technical Breakdown: 세 가지 다른 접근 방식

Postgres wire compatibility를 공유함에도 불구하고, 이 세 제품의 아키텍처 철학은 크게 다릅니다:

Snowflake Postgres

이 세 가지 중 가장 "Postgres-like"합니다. Crunchy Data 팀의 작업을 기반으로 구축되었으며, lakehouse 연결을 위해 pg_lake를 활용합니다. pg_lake는 오픈 소스이며 표준 Postgres와 호환되므로, 개발자가 표준 PG에서 프로토타입을 만들고 특정 기능에 종속되지 않고 Snowflake로 마이그레이션할 수 있습니다. 여기서 주요 트레이드오프는 가격입니다. Snowflake의 특정 비용 구조를 따르게 됩니다.

Databricks Lakebase

Lakebase는 Neon-derived branching 모델 덕분에 개발자들에게 특히 매력적입니다. 이는 CI/CD를 위한 즉각적인 데이터베이스 브랜칭을 가능하게 하며, 시점 복구(point-in-time recovery)를 재해 복구 절차에서 표준 운영으로 변화시킵니다. 컴퓨팅과 스토리지를 분리하여 저렴한 scale-to-zero 기능을 제공합니다. 그러나 그 가치 제안은 Databricks 워크스페이스에 강하게 결합되어 있습니다.

Azure HorizonDB

HorizonDB는 아키텍처 측면에서 가장 공격적입니다. 기존 엔진을 수정하는 대신, Microsoft는 Postgres wire protocol을 사용하는 스토리지 엔진을 처음부터 새로 구축했습니다. 이 접근 방식은 대규모 확장을 가능하게 하며—최대 3,072 vCores와 128 TB 데이터베이스를 지원한다고 주장하며—OLTP 워크로드에서 표준 Postgres보다 3배의 처리량을 보여주는 벤치마크를 보여줍니다. 여기서의 위험은 "wire compatible"과 "실제 Postgres" 사이의 간극입니다. 특정 확장 기능(extensions)이나 심층적인 툴링에 크게 의존하는 경우 이 간극이 매우 중요해집니다.

"Postgres-Flavored"의 숨겨진 비용

벤더 마케팅은 종종 표준 PostgreSQL에서 독점적인 scale-out 버전으로 이동할 때 무엇을 잃게 되는지를 간과합니다:

  • Extension Support: PostGIS는 일반적으로 잘 지원되지만, 덜 흔한 확장 기능은 도박입니다. 자체적인 background worker를 필요로 하는 확장 기능은 특히 위험합니다.
  • Logical Replication: 각 플랫폼은 이를 다르게 처리합니다. Lakebase의 브랜칭과 HorizonDB의 shared-storage 아키텍처는 아직 완전히 문서화되지 않은 logical decoding에 대한 복잡성을 유도합니다.
  • **Operational Tooling: 표준 도구인 pg_basebackup, pgBackRest, 그리고 Patroni는 거의 무의미해집니다. 쿼리 지식은 전수되지만, 운영적 숙련도는 전수되지 않습니다.
  • Upgrade Control: 새로운 Postgres 버전(예: PG 19)으로 테스트하고 이동하는 일정을 스스로 조절할 수 없습니다. 벤더의 로드맵에 따라야 합니다 합니다.

Final Verdict: 언제 Scale Out을 해야 하는가

대부분의 프로덕션 워크로드의 경우, 강력한 primary 하나와 몇 개의 replica가 있으면 충분합니다. "3,000 vCores"라는 약속은 실제로 필요한 사람이 거의 없는 사치스러운 기능입니다.

만약 여러분이 이미 지배적인 인접 데이터 플랫폼(Snowflake, Databricks, 또는 Azure)를 보유하고 있지 않다면, 실제 Postgres를 실제 인스턴스에서 사용하거나 Aurora, Cloud SQL, 또는 Crunchy Bridge와 같은 기존의 관리형 서비스를 사용하는 것을 권장합니다.

공유 스토리지 scale-out 아키텍처가 하나의 인정받은 카테고리로 수렴하는 것은 중요한 산업 트렌드입니다. 하지만 대부분의 엔지니어에게 가장 안전한 선택은 프리뷰 제품에 운영 스택을 거는 첫 번째 사람이 되지 않는 것입니다.

Sources