【ITニュース解説】The Company Behind Cursor's Vector Search Just Killed the Vector-First Database

近年、AI技術の発展とともに「ベクトル検索」というキーワードが注目を集めている。これは、テキストや画像などの情報を数値のベクトル（埋め込み、embedding）として表現し、互いの類似性を効率的に探す技術だ。このベクトルデータを保存・検索するために、「専用のベクトルデータベース」を導入する動きが活発だった。しかし、この潮流に一石を投じる発表があった。CursorやNotionといった大規模サービスで何十億ものベクトル検索を支える企業、turbopufferが、次期メジャーバージョン（v3）において、「ベクトルを第一のデータ構造として扱うこと」をやめるという衝撃的な発表をしたのだ。

これは、ベクトル検索自体が不要になるという意味ではない。turbopufferは、ベクトルインデックスの役割を「主役」から「単なる二次的なインデックス」へと変更することを意味する。これまで、彼らのシステムではドキュメント全体がそのベクトルのクラスタアドレスによって管理されていた。この仕組みだと、インデックスが再編成されるたびに、ドキュメント全体とその関連情報も移動してしまうという問題があった。これを「書き込み増幅」と呼ぶ。一つのベクトルを更新するだけで、実際には多くのデータが移動し、システムに大きな負荷がかかっていたのだ。

v3では、ドキュメントは安定した固有のIDで管理されるようになる。ベクトルはあくまでそのドキュメントに対する追加的な情報であり、検索を高速化するためのインデックスとして機能する。この変更により、書き込み増幅の問題を解決し、より効率的なデータ管理を目指している。彼らのアーキテクチャの根幹である、低コストのオブジェクトストレージを主軸に置くという考え方は変わらない。これは、大量のデータを安価に保存し、必要な時に高速なキャッシュ層と組み合わせて利用するという、彼らが大規模サービスを支える上で重要な経済的メリットをもたらしている部分だ。

これまで、ベクトルデータベースを導入すべきか否かという議論は、「既存のリレーショナルデータベース（例えばPostgres）では不十分か」という形で進められてきた。Postgresには「pgvector」という拡張機能があり、HNSWやIVFFlatといった高速なベクトル検索アルゴリズムをサポートするインデックス機能を提供している。Postgresを支持する側は、既存のデータベース環境に統合でき、追加コストなしで利用できる点を強調する。また、ベクトル検索だけでなく、通常のデータベース操作（フィルタリング、結合、権限チェックなど）を組み合わせた複雑なクエリを一つのシステム内で完結できる強みも主張してきた。例えば、100万個のベクトルデータであれば、Postgresのpgvectorでも十分な性能を発揮することがベンチマークで示されている。

一方で、専用ベクトルデータベースの支持者は、1億個を超えるような超大規模なベクトルデータセットになると、Postgresのような汎用データベースではレイテンシやメモリ効率の面で専用エンジンに劣ると主張する。特にHNSWのようなインデックスは大量のメモリを消費するため、Postgresのメモリ管理やシャーディングの限界が問題になるとされる。また、専用エンジンは大規模データに対応するためのメモリ階層化やスケーリング機能に優れているという意見もある。

しかし、turbopufferの今回の発表は、この議論に新たな視点を提供する。彼らは、大規模なディスクベースの検索は、突き詰めれば「ストレージの経済性」の問題が大きいと指摘する。全てのデータを高速なRAMに置くのではなく、安価なオブジェクトストレージにデータを格納し、必要な部分だけをSSDキャッシュなどで高速化する階層型ストレージ戦略こそが、コストと性能を両立させる鍵だと示している。

そして、実際のアプリケーションで必要とされる検索の形を考えると、Postgresの強みがより明確になる。例えば、「特定のワークスペースに属し、特定のカテゴリで、ユーザーが既に却下していない類似ドキュメントを見つけ、表示用に詳細情報も結合して表示する」といったクエリを想像してみてほしい。専用ベクトルデータベースでは、まず類似ドキュメントを検索し、その結果をアプリケーション側で受け取り、別途リレーショナルデータベースに問い合わせてフィルタリングや結合を行う、という複数のステップが必要になることが多い。これでは、何度もデータベースとやり取りが発生し、複雑なロジックをアプリケーション側で実装しなければならない。

これに対し、Postgresでは、このような複雑な検索を単一のSQL文で記述できる。フィルタリング、結合、権限チェック、そしてベクトルによる類似度順の並べ替えまで、全てをデータベース内で完結させることが可能だ。これにより、データの整合性を保ちやすく、バックアップやリストアといった運用もシンプルになる。また、特定の条件（例えば「ワークスペースIDが特定の値である」）に限定した「部分インデックス」をベクトル検索に適用することで、大規模なインデックス全体を検索するのではなく、絞り込まれたデータ範囲内で高速に検索することもできる。

もちろん、Postgresが常に万能というわけではない。turbopuffer自身も、以下のような特定の「スケール」に関する状況では、専用エンジンが必要になることを認めている。第一に、Notionのように何百万ものテナント（名前空間）があり、そのうちのごく一部しか常にアクティブでないような超大規模マルチテナント環境では、オブジェクトストレージを核とした階層型アーキテクチャがビジネスモデルそのものとなる。第二に、1億個以上のベクトルを持つ非常に巨大な単一インデックスを、常に高いクエリ速度で維持する必要がある場合、PostgresのHNSWグラフがデータセット自体よりも多くのRAMを要求するようになり、専用エンジンのメモリ階層化が優位に立つ。第三に、ColBERTスタイルのように、一つのドキュメントに対して多数のベクトルを保存する「多ベクトルドキュメント」のシナリオでは、データの保存量が増幅する問題があり、これは行ベースのPostgresストレージには不向きなため、専用エンジンがより適している。

つまり、データベースの選択は、単に「どれくらいのベクトル数があるか」だけで決まるものではない。より重要なのは、「実際のアプリケーションでどのようなクエリを実行するのか」ということだ。単に最近傍のベクトルを見つけるだけのシンプルな検索が中心であれば、専用エンジンが強力な選択肢となる場合もある。しかし、フィルタリングや結合、権限チェックといったリレーショナルな要素が複雑に絡み合う検索が主であれば、Postgresのようなリレーショナルデータベースが圧倒的に優位だ。

今回のturbopufferの発表は、ベクトル検索という技術が成熟し、その実装が初期の「全てを新しく」という熱狂から、より実用的で堅実な方向へと収束していることを示唆している。ベクトルを第一の主役とするのではなく、安定したドキュメントIDを核とし、ベクトルを他の属性と並列に扱うインデックスの一つとして位置づける。これは、リレーショナルデータベースが長年培ってきた設計思想に回帰する動きと言えるだろう。既存のPostgresのようなデータベースは、pgvectorの進化とともに、埋め込みデータを扱うための「デフォルトの場所」として、その地位を確固たるものにしつつある。多くのアプリケーション開発者にとって、まず検討すべきは、既存のインフラであるPostgresに埋め込みデータを置くことだろう。専用ベクトルデータベースは、特定の非常に大規模なスケールの問題に直面した場合に初めて検討されるべき選択肢となりつつある。