こんにちは、喜田です。

Snowflake Postgresの発表以来、関連ニュースを追ったり、速報ブログを英語化して公開したところ多数のリアクションをいただき、海外のエンジニアや調査会社からDMで取材？ディスカッション？の依頼をいただくなど、注目度の高さを痛感しています。がんばってきてよかった！

Snowflake Postgresについては、既報の6/2 Crunchy Dataの買収発表、6/10 Snowflake Postgresの開発進行中アナウンスがありましたが、いずれも具体的な製品デザインに触れるようなものではありませんでした。

そこから約1週間を経て、また新たな養分が投下されたのでした。うまうま～～～
AI文字起こしでもいいんですが、せっかくアーカイブがあるので詳細が気になる方はぜそちらを見ていただくとして、やっぱり熱かった Snowflake × Crunchy Data というところを強く感じたのでこの発表から読み取れることを解説していきます。

youTube配信での開発者トーク

日本時間で6/19 2:00AM～、30分間の開発者対談がyoutubeLiveで配信されました。
https://www.youtube.com/watch?v=Coj7PeCW2xc

登壇者

Craig Kerstiens氏 ：元Crunchy Data、現Snowflake Postgresチームの製品責任者
Matt Gardner氏 ：Snowflakeデベロッパーリレーション責任者
Sumesh Kumar氏 ：Snowflakeアプリケーション製品責任者

Snowflakeのお二人がトークを進行してCraig氏が答えていきます。
めーーーっちゃ語ってるので台本はある程度あるのだと思いますが、それにしても忖度無しで率直にしゃべってると言う感じで「その質問は何回も答えてきたけど嫌いな質問ではある」みたいなことも言いながらちゃんと回答してくれてましたｗ

Craig氏が見る Why Postgres？

対談の内容を振り返りつつ熱いパートを解説していきます。

Craig氏の自己紹介とWhy PostgreSQL

15年ほどPostgreSQLに携わり、Crunchy Dataの前はHeroku（業務アプリケーションの開発・ホスティングプラットフォーム）でバックエンドのPostgreSQLを担当してきた、Heroku上で稼働するあらゆるアプリのバックエンドとして信頼性とセキュリティに優れ、ワークロードの特性に合わせた拡張が可能なPostgreSQLを推すに至ったとのエピソードが紹介されました。
（↑ このことは以降のトークの中でも何度もでてきて、PostgreSQLの最大の魅力として見ていることが伝わってきます。）

またSnowflake側もPostgreSQLは 世の開発者たちに愛されている と見ていたことが語られました。

これは長年PostgreSQLに携わってきた私見ですが、パッケージベンダーや業務システム開発者はPostgreSQL（互換の商用製品も含む）を真に気に入って使っている割合が高いです。PostgreSQL採用してみたけど使いづらいしｘｘｘだからやめたよ！という人を一人も見たことがないぐらいです。（昔それで炎上した某配車アプリ企業がありましたが、まあそこまで巨大なサービスは何にしても苦労もあるでしょう、ではある。）
クラウドプラットフォーマーは第一の選択肢としてPostgreSQL互換性を謳うようになってきました。PostgreSQLを前提に作られたコードはクラウド/オンプレ問わずどこでも動き、また期待する要件に合わせた高度な実装～安価でライトな環境までなんでも受け止めることができます。
PostgreSQL前提のコードが書けるエンジニアはどんなアプリの仕事も引き受けることができる、が、ストリーミングレプリケーションの登場以降、そして AWSのRDS for Postgresの登場以降、この10年ばかりで地で実現されているな～と思うほどです。「世の開発者たちに愛されている」は大いに納得できます。

PostgreSQLの拡張性について

対談から少し話がそれますが、PostgreSQLの拡張性こそが強みであるという論調でしたので、そこを解説します。
PostgreSQLはトランザクション（ACID）のサポートやセキュリティといった質実剛健なデータベースとしての柱を最重視したうえで、プロセス管理、バッファ管理といった核となる技術が実装されています。加えて、これらと並んで拡張性を維持するような各種コードのAPI化、拡張ツールのためのコードレベルのインターフェースが明確に定められています。

例を挙げて説明します。

エクステンション EXTENSION

各々のPostgreSQL環境で、特定の目的にフィットした機能を追加で導入することができます。
このような追加機能もまたOSSとしてボランティアベースで開発されていたり、企業が自社プロダクトのために開発しているものもあります。特徴としてエクステンションというPostgreSQLの機能拡張のお作法に則った実装がされている限り、利用者は既存のPostgreSQLを再インストールしたり環境を壊すことなくその機能を簡単に追加して利用することができます。

近年最も注目を集めたのはpgvectorでしょう。

CREATE EXTENSION vector;

のようなSQLで機能を追加インストールすることができ、このエクステンションパッケージの中にはベクター型の列を定義できる機能、入力値を多次元ベクトルに変換するembedding処理関数、格納済みのベクター列と入力値の類似度を比較する関数などがセットで提供されています。
ChatGPTの登場でAI関連に注目が集まるやいなや、pgvectorを使ったRAG on PostgreSQLができるといった話題で非常に注目されました。

インデックスの拡張

エクステンションよりはPostgreSQLそのものの開発サイドの話題になりますが、昔からPostgreSQLの拡張性で紹介されるものの一つにインデックスアルゴリズムの拡張性がありました。
PostgreSQLは標準で提供されるB-Treeの他にもいくつかのインデックスアルゴリズムを持っているのですが、それ以上に特定のデータに最適な検索を実現するインデックスを実装することができます。PostgreSQLのコード仕様としてIndex Access Methodというインターフェースが定義されており、その仕様に則って作られた新しいインデックスアルゴリズムはちゃんと実行計画作成時に認識されてコストベースの候補になってくれるというものです。

例えば、日本語全文検索 pgbigm があります。
全文検索とは、

WHERE comment LIKE '%感動しました%'

のような自由な文字列に対する中間一致検索はB-Treeインデックスが効かずにフルスキャンになってしまうため、いかに効率的に目的の行を探すか？というための機能です。
英語の全文検索の場合、アルファベット2文字で何かを表現するケースは稀で、連続する3文字からなるTri-gramという方法が取られてきましたが、日本語は2字熟語が検索対象になることが非常に多く、連続する2字を探すBi-gramに対応しなければなりませんでした。

テーブルの拡張

同じくテーブル（の背後にある物理データの格納方式、バッファ管理方式も含めて）についても拡張インターフェース Table Access Method が定められています。
例えば通常の行指向テーブルではなく、列指向フォーマットでデータを保管するようなもので分析用途のデータベースとしてPostgreSQLを使うというケースも現実的になっています。

このような拡張性を前提としたPostgreSQL本体があり、その時々の需要に合わせて生み出されてきた無数の拡張機能たち（＝PostgreSQLエコシステムと呼ばれる）があり、それによってPostgreSQLは時流に合わせたデータベース製品として進化し続けてきた、ということをCraig氏も語っていました。

Crunchy版PostgreSQLで取り組んできたこだわり

対談の中でCraig氏が語っていたのが、最近はCrunchyDataが開発した拡張ツールpg_parquetがありPostgreSQLからParquet形式にネイティブに書き出せるものであったり、pg_incrementalはインクリメンタルなデータ処理（私も初見でしたが、おそらくParquet形式での吐き出しを継続的にやるなどができる・・・？）といったものがあります。分析用途とOLTPの統合、HTAPはトレンドではあるけどいまや自然な流れでできる段階にきた。
（それは5年後10年後には当たり前でであって強みとすらいえないものだとしても、）今のトレンドによって起こった進化であり、5年後10年後にはまたその時必要な進化を遂げることができる。それができるのがPostgreSQLであり、それに取り組んできたのがCrunchy Dataである。（超意訳！）

拡張性とエコシステムこそがPostgreSQLの強みだということを熱く熱く語ってくれていました！

見えてきたSnowflake Postgresの製品デザイン「100％ピュアなPostgreSQL」って？

Snowflake Postgresの重要なコンセプトが明かされました。
PostgreSQLは寛容なライセンスゆえ、商用ディストリビューションがたくさん生み出されているという話があり、それに対してSnowflake Postgresでは何を重視しどう実現していくかが語られました。

商用のPostgreSQLディストリビューションについての解説

PostgreSQLはオープンで寛容なライセンスゆえ、PostgreSQLをフォークした商用データベースプロダクトが多く生み出されています。企業が独自にPostgreSQLの改変を行い、プロプライエタリなデータベース製品として販売する場合であっても、「元がPostgreSQLである」ということを明記すればあとは自由と言うライセンスです。Amazon Auroraしかり、Oracle互換を謳ったEDBしかり。
ただし、このフォークした独自製品は個社ごとの開発体制等に大きく依存し、メジャーバージョンアップサイクル、不具合修正サイクルなどがOSS PostgreSQLから常に遅れることになります。私も携わってきたEDBでは不具合修正レベルは数日、メジャーバージョンで数カ月の時間差があり、これでも他のディストリビューションと比べて随分早いものでした。（他の多くのディストリビューションでは半年～1年遅れでした。）

Snowflake Postgresのこだわり「100％ピュアなPostgreSQL」

PostgreSQLの芯の部分の安定性・信頼性といった部分は前提として、活発な開発コミュニティによって製品そのものはどんどん進化していきます。
実はこの部分も開発コミュニティの中の話を聞くと安全寄りに倒していくという思想が根強いそうで、破壊的な変更へのチャレンジは起きづらいという話もあるぐらいですが、それでも素の能力が年々向上しています。それに加えて、時流に沿った進化をとりいれていく拡張機能のエコシステムがあるのは上述の通りです。

Crunchyが目指してきた「10年後も同じように好きでいられるPostgreSQL」

熱すぎるポイントなのでそのままの雰囲気で和訳します。

私たちはコミュニティ版の純粋なPostgresをベースにして、その上で拡張機能のフレームワークを活用して構築しています。他の多くの会社はPostgresをフォークして独自のものにしようとする。でも私たちは、数か月単位の短期的な賭けをしているわけじゃなくて、10年、20年スパンの長期的なビジョンで取り組んでいます。Postgresと共に進化し、コントリビュートし、拡張を通して強化していく。だから、5年後に「この選択を後悔している」と思うようなことはありません。
あなたが今Postgresを好きなら、10年後も同じように好きでいられる。それが私たちの「純粋なPostgres」です。そして、それを私は本当に誇りに思っています。
これは、「100%ピュアなPostgres」であるというだけでなく、コミュニティプロジェクトに貢献しながら、その上に開発者の喜びや生産性、フローの維持を築いていくという考え方です。そして、この「三本柱」の三つ目が、SnowflakeがCrunchyDataを見て最初に魅力を感じた部分でもある、企業レベルの運用への対応力だと思います。

PostgreSQL本体へのコントリビュート（貢献）を惜しみなく続けてきたCrunchy Dataのこだわりと、それに対するSnowflakeのリスペクトが明確に語られた瞬間でした。ぎゃぁぁぁぁぁぁ！エモすぎる～～～！

ちゃんとEnterprise Ready で Snowflakeファミリーとして価値ある Snowflake Postgresの予告

100％ピュアなPostgreSQLといっても、素のOSS PostgreSQLではなく、クラウドネイティブなSnowflakeプラットフォーム上にデプロイされてフルマネージドのサービスとして仕上がってくるであろうこと。エクステンションの仕様に則った拡張機能を備え、常に最新かつ最強、「僕の考える最強のPostgreSQL」が産み出されるということが明確に予告されたと捉えて良いと思います。

フルマネージドの真意は言葉の端々にあり、コネクションプーラーを内包していること（PostgreSQLは同時多重の接続に対してCPUネックになりやすく、その対策）や、インプレイスのメジャーバージョンアップなどオンプレミス環境では数カ月規模の一大プロジェクトで行うような設計・実装・運用がカバーされるようなことを語っていました。

拡張機能の一端として、HTAPの要求に応えていくことは当然ロードマップに入っていること、AI Data CloudとしてのSnowflakeが実現する世界に大きく貢献するものであることが示されました。

Snowflakeのより大きなビジョンは、アプリ開発のための「データとAIのプラットフォーム」になることなんです。あなたの言う通りですね。そして「Snowflake Postgres」は、そのビジョンの中でアプリ開発者にとって非常に重要な構成要素です。
Snowflakeというプラットフォームは、単に一つのプロダクトというより、さまざまな機能が集まった「能力の体系」なんですよ。開発者が「もっとデータを活用したい」と思ったときに、今は Cortex AI を使うことができますし、素晴らしいアプリケーションを構築して、それをSnowflakeの中に直接デプロイできる。
それだけじゃありません。Snowflake Marketplace を通じて、作ったアプリケーションを「公開・配布・販売」することもできるわけです。つまり、Snowflakeは開発者のための「拡張性の高い基盤」をすでに持っていて、たとえば Snowparkコンテナ、持続可能なアプリケーション環境、Snowparkを使ったビジネスロジックの構築など、全部Snowflakeの中で完結できます。
そして今回、そこに Snowflake Postgres が加わったことで、この基盤がさらに強化されたんです。なぜなら、開発者が愛してやまない「本物のトランザクションデータベース」がAIデータクラウドの中でネイティブに使えるようになったからです。
でも、これは単にPostgresが使えるようになった、というだけではありません。私はこれを繰り返し強調したいんですが、「Snowflake AIデータクラウドが提供する、開発者向けの全機能のセット」があるからこそ意味があるんです。AIの活用から始まり、Marketplaceでの流通、アプリの開発・デプロイ・販売まで、一貫してこのプラットフォームの中で実現できる。それが最大の魅力です。

上記の文字起こしの中でも触れられている話題ですが、
「Snowflakeのマーケットプレイスにあらゆる業務パッケージベンダーがプロバイダーとして参入できるようになりますよね？」
「利用者はワンクリックであらゆる業務アプリを買ってPostgreSQLと共にそれを利用することができると想像しているがどうですか？」
というコメントを入れたところ、即答で「Yes！」 と返答をいただきました。

まとめ

30分間、ノンストップで語りまくる配信だったので、細部はもっともっといろいろ語られていたのですが最重要ポイントとして気になっていた両社が実現したいビジョン、OSSプロジェクトへの貢献とリスペクト、そしてSnowflake Postgresの製品デザインに絞って、私なりの解説を交えて記事にしました。

しかしまあ、熱い想いをめちゃくちゃ感じる配信でしたね！早口でめｃｃｃｃっちゃおもいのたけを語ってくれてるので、ぜひ雰囲気だけでも見ていただくと熱さが伝わってくると思います。
そしてこの配信をみて私の中でのSnowflake Postgresへの期待値は忖度無しに急上昇してます！

こんな文字だらけの記事を読んで、熱さに胸を打たれて、PostgreSQLってすごいな、Snowflake Postgres楽しみだな、と思ってくれる方が一人でもいれば幸いです。