Snowflake Postgres, Lakebase, and HorizonDB: クラウドネイティブPostgresの新潮流をナビゲートする

データベースの景観が変化しています。この1年で、Snowflake、Databricks、Microsoftという3つの最大級のデータプラットフォームプロバイダーが、「Postgres風」のデータベースをリリースしました。これらはすべてPostgreSQLとのワイヤー互換性を主張していますが、カスタムストレージレイヤーと「スケールアウト・コンピューティング、共有ストレージ」アーキテクチャを利用しており、標準のエンジンとは根本的に異なります。

これらの提供サービス——Snowflake Postgres、Databricks Lakebase、およびAzure HorizonDB——は、運用（OLTP）と分析（OLAP）のワークロード間のギャップを埋めることを目的としています。しかし、それらの選択は、単なる技術的な優位性に関するものではなく、すでにデータがどこに存在しているかによって決まることがほとんどです。

エコシステム・ロックインのフレームワーク

これらのプラットフォームを評価する際、主要な質問は「どのデータベースが最適か？」ではなく、「すでにどのデータプラットフォームを標準として使用しているか？」です。

  • Snowflakeユーザー: 分析ウェアハウスがSnowflakeであれば、マネージドなクラウドネイティブPGの体験を得るための論理的な選択肢はSnowflake Postgresです。
  • Databricksユーザー: 分析プラットフォームがDatabricksであれば、Lakebaseが自然な選択となります。
  • Azureユーザー: VMの管理に疲れ、Azureエコシステムに深く投資している場合は、HorizonDBが深く統合された代替案を提供します。

著者が指摘するように、これらのベンダーは「運用と分析の収束」をマーケティングしていますが、この収束は彼ら独自のプロプライエタリな壁の中でのみ発生します。これらのプラットフォーム間でデータを移動させることは、依然としてクラウドのデータ転送（egress）料金というコストのかかる作業となります。

技術的内訳：3つの異なるアプローチ

Postgresのワイヤー互換性を共有しているものの、これら3つの製品のアーキテクチャ哲学は大きく異なります。

Snowflake Postgres

これは3つの中で最も「Postgresらしい」ものです。Crunchy Dataチームの成果に基づいて構築されており、レイクハウスへのフックとしてpg_lakeを利用しています。pg_lakeはオープンソースであり、標準のPostgresと互換性があるため、開発者は標準的なPGでプロトタイプを作成し、特定の機能に縛られることなくSnowflakeへ移行することが可能です。ここでの主なトレードオフは価格であり、Snowflake独自のコスト構造に従うことになります。

Databricks Lakebase

Lakebaseは、Neon由来のブランチングモデルを採用しているため、開発者にとって特に魅力的です。これにより、CI/CDのためのインスタントなデータベース・ブランチの作成が可能になり、ポイントインタイム・リカバリを災害復旧手順から標準的な操作へと変貌させます。コンピューティングとストレージを分離することで、安価なスケール・トゥ・ゼロを実現しています。しかし、その価値提案はDatabricksのワークスペースに強く結びついています。

Azure HorizonDB

HorizonDBは、アーキテクチャ的に最も攻撃的です。既存のエンジンを修正するのではなく、MicrosoftはPostgresのワイヤープロトコルを話すストレージエンジンをゼロから構築しました。このアプローチにより、大規模なスケールが可能になり（最大3,072 vCoresと128 TBのデータベースを謳っています）、ベンチマークではOLTPワークロードにおいて標準のPostgresの3倍ののスループットを示しています。ここでのリスクは、「ワイヤー互換」と「実際のPostgres」の間のギャップであり、これは特定の拡張機能や深いツールへの依存度が高い場合に重要になります。

「Postgres風」の隠れたコスト

ベンダーのマーケティングは、標準のPostgreSQLからプロプライエタリなスケールアウト版へ移行する際に失われるものをしばしば見過ごしています。

  • 拡張機能のサポート: PostGISは一般的にサポートされていますが、あまり一般的でない拡張機能はギャンブルとなります。独自のバックグラウンドワーカーを必要とする拡張機能は特にリスクが高いです。
  • 論理レプリケーション: 各プラットフォームはこれを異なる方法で処理します。LakebaseのブランチングやHorizonDBの共有ストレージ・アーキテクチャは、論理デコーディングに対して、まだ十分に文書化されていない複雑さをもたらします。
  • 運用ツール: pg_basebackup、pgBackRest、およびPatroniのような標準的なツールは、ほとんど役に立ちません。クエリの知識は転用できますが、運用上の「筋肉の記憶」は転用できません。
  • アップグレードの制御: 新しいPostgresバージョン（例：PG 19）へのテストと移行を自分自身のスケジュールで行う能力を失います。ベンダーのロードマップに左右されることになります。

最終的な判断：いつスケールアウトすべきか

大多数のプロダクション・ワークロードにおいて、単つの強力なプライマリといくつかのレプリカがあれば十分です。「3,000 vCores」という約束は、実際にはほとんど必要とされない贅沢品です。

もし、すでに支配的な隣接データプラットフォーム（Snowflake、Databricks、またはAzure）を使用していないのであれば、推奨されるのは、実際のPostgresを実際のインスタンス上で使用するか、Aurora、Cloud SQL、またはCrunchy Bridgeのような確立されたマネージドサービスを利用することです。

共有ストレージによるスケールアウト・アーキテクチャが、認知されたカテゴリーとして収束していることは、重要な業界のトレンドです。しかし、ほとんどのエンジニアにとって、最も安全な選択は、プレビュー製品に運用スタックを賭ける最初の人間にならないことです。

Sources