※本記事は自社ブログに掲載した記事の転載です。Qiitaで続報を解説するにあたり微修正して転記しています。
以下、Snowflakeによる新しいOLTPデータベースサービス「Snowflake Postgres」のリリース計画が発表された6/10に執筆した内容です。
こんにちは、喜田です。
Snowflake Summitで発表された Snowflake による Crunchy Data の買収と Snowflake Postgres リリース予告！その瞬間から関連ニュースを漁り、過去のPostgreSQLコミュニティで知りえたCrunchyの実績などなど調べ速報記事を出して、引き続き注目してくぞ！と言ってきたところで本日公式から養分が投下されました。（Snowflake Postgres の続報がでました。）
この記事では、上記の公式発表＋サミット後数日たって諸々を整理しながらもう少しSnowflake Postgresについて見えてきたこと＆今回のこの発表から連想されるとある壮大な世界観についての考察を書きたいと思います。
2025.6.10時点の公式リリース
以下のブログが公開されました。
ざっくり要約すると、エンタープライス用途に最適なPostgreSQLをSnowflakeのDBaaSとして提供するよ！という内容です。
その名も 「Snowflake Postgres」！
Snowflakeの名を冠した肝入りのプロダクトになりそうです。だって創業から14年（かな？）クラウドDWH一本でやってきたSnowflakeが、ついに2個目のデータベースプロダクトを出すというのです。PostgreSQL in Snowflake じゃないんです。 ファミリーとしてラインナップされる全く新しいデータベースサービス！ どういう形で提供されるかはまだ全く未知ですが、こういう所からも本気度とリスペクトを感じて嬉しいといったらないですね。高まるぅ～～～★
言っていることは順当に、まともに、当たり前のことではある
セキュリティやコンプラ遵守 として、暗号化、法規制への完全な対応を挙げています。
OSS PostgreSQLではHW、OS、データファイルと様々なレイヤでデータ保護の手法があります。各種法規制に対して、どこまでやるべきか？といったガイドも多くのPostgreSQLを取り巻くベンダーの努力によって解説されていて、ノウハウはあるのですが、性能とのトレードオフなどもあり実装・運用の難度が跳ね上がります。
これをサービスのレイヤで当たり前に実装しているのはエンタープライズユースとしては有益でしょう。
BCP（事業継続性）とDR（災害復旧機能） 、これらはオンプレ時代のデータベースでも当然対策されてきた問題です。
PostgreSQLはもう10年以上前になりますがStreaming Replicationという技術で常時最新状態に追いつくデータベースの複製を持てるようになり、そのあたりからエンタープライズ用途での採用が急激に増加したという背景があります。これこそ皆が当たり前に実装してきたことなので、ノウハウは溢れているのですが、それでも適切に運用しつづけることは大変で、サービス側で完結してくれることはありがたいです。
が、 当然の期待であって目新しいものではありません。
パフォーマンスと本番環境へのクリアな道筋 について。
ここはブログ記事でも定性的な表現でなんとも言えない部分ですが、検証環境では十分だった性能が本番の同時多重アクセスに全く耐えられないということはありがちで、それを救ってくれるのでしょうか。
PostgreSQLはその書き込みアーキテクチャがオンプレミスのHDD時代に想定されたものであって、スケールアップ/スケールアウトの限界について度々議論されています。直近のSnowflakeのリリースでもディスク書き込みの見直しによって「ある処理では3-5倍高速になる」と言われるほどの改善がありました。反面、そのようなボトルネックをいまだに孕んできたということです。
こういうところを現代のアーキテクチャにフィットさせつつ、「数msのレイテンシ」や「同時数万の並列実行」といったオンプレPostgreSQLがこなしてきた性能をもっと引き上げてくれることを期待しています。（たぶんこの話で効いてくるのは並列実行性のほう。CPUをどんなに積んでも最後にはディスク書き込みでボトルネックになっているのは未だにOSS PostgreSQLでは解消されていない。レイテンシのほうはクラウドで物理的に離れると最高でも現状維持でしょう。）
当たり前のことは既に世にサービスとして存在している
わかりやすくRDS Aurora for PostgreSQL がまさにそうで、現代のアーキテクチャにフィットさせ性能の大幅向上を達成しています。現に、Auroraではチェックポイント（一気に大量に発生するI/Oで性能安定化の大敵）を排除して超多重を扱えるなど目に見えて高性能な面があります。セキュリティや障害復旧の要件に対しても様々なオプションを持ち、やりたいことはだいたいできるでしょう。Snowflakeのブログで記載された定性的な表現でいうと、5～10年前から既にそういったものがあって、ただこれらをSnowflake Postgresで実装しただけでは後発でしかありません。じゃあ定量的に見比べた場合に、驚くような改善がされ、PostgreSQL界に革命を起こしてくれるのか？！
（実はそうではないんじゃないかと私は考えています。それでもPostgreSQLを取り込む必然性について、この記事の最後に考察します。）
- Crunchy Data版PostgreSQLが既に異次元の高速化を達成しているという話は聞いたことがない
- Crunchyが力をいれてきたコンテナ技術＋Snowflakeのインフラに最適化はしてくるだろうが目を見張るような違いにはならないのでは？Azure SQL for PostgreSQLはコンテナベースだったはずなのでそこも大きな差はないはす。
- DBaaS系はAuroraぐらいしか試したことがないが、並列実効性は高く、レイテンシは普通。
- 新興形でNeonがあるが、HTAP需要のためにアーキテクチャを攻めてる印象でレイテンシはむしろ遅い（試したことはないので誤解があったら申し訳ないが）上記のブログにもある通り高性能を謳っているのでこっちの路線は無さそう。
と言う中で、少なくともSnowflake Postgresの最初のリリースが革命的に高性能とか言うことはなく、便利に使えるPostgreSQLぐらいを期待しているのが正直なところです。PostgreSQL愛ゆえに、そのまま使えればむしろ言うことなしと思っているまであります。みんなの期待とはもしかしたら違うのかもだけど！
Meet the Crunchy Data Postgres Team に参加してきた
Snowflake Summit内にはGROUP BYエリアがあって、テーマ別や地域別のMeetUPイベントが次々と開催されていました。その中の1枠に突如として現れたCrunchy DataチームとのMeetUP！こちらに参加して、生まれたてホヤホヤの新生Postgresチームのメンバーからお話を聞いてきました。
左のCraig氏は日本PostgreSQLユーザ会の年次イベントでキーノートにお招きしたことがあります。Snowflake社員に紹介してもらったのですが、会ってみたら覚えてる顔で感無量でした！！！
ここで会話してきたことを紹介しておきます。（通訳なし単騎で突撃してきたので、私のプアな理解の範囲です。。。）
私のこの時点でのスタンスとして、PostgreSQL愛が強すぎるがゆえに、「そのまま動いてくれれば言うことなし。安定性、性能、セキュリティ、拡張性、全部において不満はない。素敵アーキテクチャを売り文句にするのは好きにやってくれ！」ぐらいの想いであったことを最初に書いておきます。
OSSへのコントリビューションは継続する
どんな素敵サービスに仕上げてくるか？よりも一番気になっていた部分がこれで、PostgreSQLの歴史に大きく貢献してきたCrunchyだからこそ、OSS活動への熱い想いを持ち続けていて欲しいし、Snowflakeには「PostgreSQL開発の歴史を背負う企業」に名を連ねることを理解して、フルコミットして欲しいと思って質問しました。
直接的な答えは英語力の問題でほぼ聞き取れず。すみません。。。むしろ分かったことは、Crunchyメンバーは今回のJOINとこれからのチャレンジを非常にエキサイティングに思っていることでした。特に熱をいれてい説明されたのははやりセキュリティや性能面で、Snowflakeのノウハウをかけ合わせていままで実現されていないことを成すという感じでした。上述した通り自分には「当たり前」に聞こえちゃったんだけど、より高度な要件に対応していくのかな？と期待を持てた瞬間でした。
その後のブログで、SnowflakeがIceberg、Polaris、Streamlit等でOSSプロジェクトに貢献を続けていることに触れ、
Our dedication to developers is also reflected in Snowflake’s commitment to open source software, as seen in our participation in projects such as Apache IcebergTM, Apache Polaris and Streamlit. Crunchy Data’s deep roots in the open source community and long-standing reputation for robust, developer-friendly tooling will allow us to provide developers the best of both worlds: unconstrained Postgres flexibility with an enterprise-tested foundation.
和訳
私たちが開発者に注ぐ情熱は、Snowflakeがオープンソースソフトウェアに対して取り組んでいる姿勢にも表れています。これは、Apache Iceberg™、Apache Polaris、Streamlitといったプロジェクトへの参加からも明らかです。Crunchy Dataはオープンソースコミュニティに深く根ざし、堅牢で開発者に優しいツール群で長年にわたって高い評価を得てきました。このCrunchy Dataとの連携により、開発者には「制限のないPostgresの柔軟性」と「エンタープライズで実証された基盤」の両方を提供できるようになります。
としていますので、当初の疑問は安心感と共に解消したのでした。
PostgreSQL開発者（ユーザー）にとって馴染みのある体験をそのまま提供する
ブログでも触れられていますが、OSS PostgreSQLと100％の互換性を提供するとしています。PostgreSQLにデータを読み書きするアプリケーションにとって、JDBCなどの各種言語用ドライバの互換性、SQL構文の互換性、内部情報をすべて保管しているカタログ群、そしてサードパーティ（多くが別のOSSプロジェクト）によって開発されている拡張機能群があり、これらすべてを移植できるとしたら他のSaaSにないPostgreSQLらしさ全開の特徴といえます。
例えばAuroraはAWSがピックアップした有益な拡張機能はデフォルトで組み込み済みですが、ユーザーが希望するマイナーな拡張を追加することはできません。（需要がどれだけあるかは別として、その選択肢がとれるか？と言う意味で。）
超マイナーなポイントですが、日本語の外字をPostgreSQLで格納するために、利用企業レベルでもソースコードに介入する（外字マッピング用のファイルを編集してビルド、そのファイルをロードするような作業）ことが稀にあります。そういった拡張の余地もあるんだろうかと気になってしまいました。だって100％っていうからには・・・ねぇ？できなくても怒らないから！ここら辺は時々出してくるSnowflakeさんのキモ冴えてる実装（褒めてる）で楽しませて欲しいと思います。
真面目に良さそうなポイントとしては、
- コネクションプーラー（おそらく生のpgBouncer）をサービスに内包し、性能ネックになるようなポイントは最初からケアされている
- ストリーミングレプリケーションやロジカルレプリケーションで外部のPostgreSQLとレプリカ構成をとることができ、移行やバックアップ用途のハイブリッド構成もとれるようになる
といったサービスのデザイン的なことは普通に教えてもらえました。
また、
- SnowflakeのHybrid Tableとのシームレスな連携
- Snowflakeのデータシェアリング等への対応
といったことを質問された別のMeetUP参加者との会話が耳に入り、これらはアイデアはあるけどTBDだと言っていました。
考察：壮大すぎるSnowflakeのビジョンについて
ここまでが事実としてでてきて、じゃあ後発となるOLTP領域のDBaaSをなぜSnowflakeは本気でやっていくのか？ ということを考えています。ここからが公式からは何も示されていない完全な想像になるのですが、もう少々お付き合いいただけると幸いです。
考察1：今回発表された Openflow も dbt in Snowflake も同じ思想なのでは？
むしろETLツールやdbtとのパートナーエコシステムを売りにしてきたはずのSnowflake。ETLベンダーもそれぞれの色を出して競争しているなかで、なぜ後発のSnowflakeが自前でやりだしたのか？PostgreSQLを取り入れたことと同じ疑問がよぎります。
データベースにとって、ETLツールは「SQLを投げてくるやつ」であって、これはデータベースから見てアプリケーションの一つの形とみることができます。業務アプリとはレイヤーが違うので、造語ですがここでは「メタアプリケーション」とでも言うことにしましょう。
このメタアプリケーション、Snowflake内でみんながやってるあらゆる処理、つまりデータ取り込み・データ加工・運用管理や監視のための可視化・・・すべてAIでコード生成できてしまう未来はすぐにでも来てしまうのではないでしょうか。そのようなコードがSnowflake内で実行されていることを既にSnowflakeは十分知っているし、実際に流れた処理をログとして持っていて、Snowflakeがメタアプリケーション生成用のモデルを作って、それをネイティブの実行環境で流すだけというのは理にかなっている気がします。
（大胆予想として、この並びでいうとTerrafromのレイヤーもSnowflakeのネイティブなサービスとして取り込んでしまうと妄想しています。）
考察2：セマンティックレイヤーが今後の核になる「AI時代のデータプラットフォーム」
いきなりPostgreSQLの話題から離れますが、すべて繋がってるんだという話。
データの意味や数式を正しく整備していくことがAIやAppにとって必須になるし、逆にそこがちゃんとしてればAIがアプリを作れる時代が来ようとしているということです。現にBIダッシュボードの可視化の部分はAIで代替されていくと参加した日本人メンバーと会話するなかでも皆が実感していて、それはアプリの仕様を伝えればアプリが出来上がることとそう遠くない未来と感じています。
Snowflake IntelligenceのようなAI機能もアプリケーションレイヤーであり、1つのアプリの形として「自然言語で受け答えするUI」と言えます。そういうものは各ユーザーが産み出す必要すらなく、Snowflakeが提供してくれた一つの形です。
それプラス、自社の独自の業務遂行に必要なそれぞれのアプリは言葉で説明すればAIが産み出してくれるという未来を想像してしまいます。
考察3：BUILD THE FUTURE OF AI AND APPS
今回のSnowflake Summitのキービジュアル
このキーワードそのものについてどこにも説明がなかったのですが、AIとAppの未来を作る、これこそがAI Data Cloudが目指すビジョンなのだと解釈しましょう。今回お披露目されたAI系のサービスなんかは、すごいけど、未来とまで言えるでしょうか？世に出てきた技術を順当に実装してきたような感じはしませんでしょうか。
ですが、ここまでさんざん語ったSnowflake Postgresをはじめとした、今回目玉とされるような機能を全部トータルで見渡して「BUILD THE FUTURE OF AI AND APPS」を改めて考えます。
言葉で定義したアプリケーションがAIによって産み出される未来において、
- 蓄積されたデータの説明までがユーザーの責任になる。
- 説明されたデータはAIが解釈してアプリを生み出すことができる。
- OpenflowやdbtやTerrafromのコードを自動生成して、それをETLやTerrafromやdbtの外部サービスに渡して投げてもらうのはナンセンスで、全部Snowflake内で完結するためには自前でこれらの実行環境を作っておく必要がある。
- OLTP特性のアプリは作れません！とは言わせない。自前でOLTPに対応するデータベースサービスを持っておく。
- OLTPアプリも動作するようになると、あらゆる業務パッケージベンダーがマーケットプレイスのアプリプロバイダーに参入できるようになる。
- 例えばERPとかECサイトとか。
- DWHかOLTPか関係なく、Snowflakeのコンテナでそれらのサービスが動いて、バックエンドはPostgreSQLで。
- データベース定義もデータパイプラインもマーケットプレイスで提供されるか、欲しいものを言えばAIが作ってくれる未来！
- いまはクラウドプラットフォームによって提供されているITインフラの抽象化レイヤーを一気に引き上げ、世の中のあらゆるITシステムがSnowflake上で動くのを当たり前にしていく。
そんな壮大なビジョンに想いを馳せるキッカケとなったSnowflake Postgresの発表なのでした。
Snowflake Postgres に興味のある方へ！
まだ誰もが見たことのないSnowflake版PostgreSQL、欲しいのは当たり前のOLTPデータベースなんですが、それでもSnowflakeがこれまで私たちに見せてくれた製品へのこだわりを思うと、性能・セキュリティだけじゃなく、AIとの融合、UIなどなど、どんな味付けでリリースされるのか期待がとまりません！
「この先数カ月でリリースする」という発言もあり、Private Previewになり次第、最速で取り組んでみたく、特に本気の方と何か一緒にチャレンジしていけないかなと考えています！
例えばPostgreSQL方面の情報交換、既存PostgreSQLからの移行検証、性能評価、アプリ特性へのDWH/OLTPのマッチなどなどやりたいこと、思いつくことがたくさんあります。そして業務データベースの領域においては、Snowflakeコミュニティで関わる「データの人」の専門やいまのチームの要求から外れる領域であることもわかっているのですが、SnowfalkeとPostgreSQLが並ぶ新しいデータベースカンパニーの世界観で何ができるのかといった観点はそれだけでワクワクしませんでしょうか。興味を持っていただける方は是非リアクションいただけますと嬉しく思います。