NeonがLakebase Searchを一般提供開始、Postgres拡張でベクトルとキーワードのハイブリッド検索を実現
Neonは2026年7月2日、Postgres向けのハイブリッド検索機能「Lakebase Search」を一般提供開始した。ベクトル検索用のlakebase_vectorと全文検索用のlakebase_textという2つの拡張機能で構成され、単一のデータベース上でセマンティック検索とキーワード検索の両方を大規模に処理できる。
従来のPostgres標準検索では、数百万ベクトル規模でメモリ不足やレイテンシ悪化が発生していた。Lakebase SearchはNeonのコンピュート・ストレージ分離アーキテクチャに最適化されており、10億ベクトル超のインデックスを単一で扱える点が最大の特徴だ。
開発中のアプリケーションに検索機能を組み込むエンジニアや、スケーラビリティの壁に直面しているチームにとって、検討すべき選択肢となる。本記事では仕組みと導入のポイントを解説する。
Postgres標準検索にあった3つの限界
検索機能をPostgres単体で完結させるのは、開発初期には手軽で合理的な選択だ。pgvectorのHNSWインデックスでベクトル検索を、tsvectorカラムとGINインデックスでキーワード検索を実装するパターンは広く使われている。
しかしデータ量が増えるにつれ、以下の3つの問題が顕在化する。
HNSWがRAMを圧迫する
HNSW（Hierarchical Navigable Small World）はグラフベースの近似最近傍探索アルゴリズムで、高速な検索を実現する。だがインデックス全体をメモリ上に保持する必要があるため、500万〜1000万ベクトルを超えるとPostgresインスタンスのサイジングがベクトルインデックスに引きずられる。
1億ベクトルを超えるとワーキングセットがRAMに収まらなくなり、クエリレイテンシが急上昇する。インデックス構築にも数時間を要する。さらにpgvectorのvector型はHNSWの次元数上限が2000で、text-embedding-3-large（3072次元）のような最新の埋め込みモデルを使う場合、halfvecへのキャストや次元削減といった回避策が必要だった。
GINは本来のBM25ではない
PostgreSQLの全文検索で使われるts_rankは、コーパス全体の文書頻度（IDF）を考慮しない。テーブルが大きくなるほど関連性スコアが徐々にずれていく。またGINインデックスにはTop-Kプッシュダウン機能がないため、LIMIT句が適用される前に全一致文書をスコアリングしてしまう。コーパスが大きいほどクエリは遅くなり、ランキング精度も落ちる。
ハイブリッド検索の実装は自己責任
ベクトル検索と全文検索を組み合わせる場合、スコア正規化やタイブレーク、テナント単位のフィルタリングといった処理はすべて自前のSQLで実装・保守する必要がある。データ規模が拡大するほど、この手間は無視できなくなる。
従来構成ではベクトル検索・全文検索・ハイブリッド化のすべてに構造的な課題があった。Lakebase SearchはこれらをPostgres拡張の形で解決する。
Lakebase Searchの仕組み
Lakebase Searchはlakebase_vectorとlakebase_textの2つのPostgres拡張機能で構成される。Lakebase（レイクベース）という名称は、Neonのコンピュートとストレージを分離したアーキテクチャに由来する。インデックスがオブジェクトストレージ上に永続化され、必要に応じてコンピュートがアタッチする仕組みだ。
lakebase_vectorの内部設計
lakebase_vectorはIVF（Inverted File）パーティショニングとRaBitQ量子化を組み合わせたlakebase_annインデックス型を提供する。RaBitQはベクトルを約32倍に圧縮する手法で、従来のHNSWでは約300GBのRAMを必要とした1億ベクトルのインデックスが10GB未満に収まる。
仕組みはこうだ。ベクトル空間を事前にクラスタ分割し、各クラスタをオブジェクトストレージ上の連続ブロックにマッピングする。クエリ時は重心との比較で関連クラスタを少数特定し、それらを並列でフェッチする。RaBitQで圧縮されたベクトルはスキャンコストが低く、クエリは少数の大きな独立リードになる。
pgvectorのベクトル型や距離演算子（<->、<#>、<=>）はそのまま使える。既存のクエリを変更する必要はなく、インデックス型だけを差し替えればよい。インデックス構築速度は同じデータのHNSW比で50〜100倍高速だ。
lakebase_textのBM25実装
lakebase_textはGINインデックスを使う従来の全文検索を、本格的なBM25（Best Matching 25）インデックスで置き換える。BM25は文書内の単語出現頻度とコーパス全体での希少性を組み合わせたランキング関数で、情報検索の分野で広く使われている。
このインデックスは構築時に文書頻度や平均文書長といったコーパス全体の統計情報を保存する。<@>演算子が本物のBM25スコアを返し、Block-Max WANDアルゴリズムによるTop-Kプッシュダウンで、全一致文書をスコアリングせずに上位K件だけを取得できる。GINにはできない動作だ。
標準のtsvector型とtsquery演算子はそのまま動作し、追加要素は<@>演算子とto_bm25query()ヘルパーのみ。既存の全文検索クエリを大きく書き換える必要はない。
アプリケーションから見ると、単一のPostgresインスタンスに対して通常のSQLを発行するだけで、内部で2つの拡張機能がオブジェクトストレージ上のインデックスを並列に検索する。
Neonアーキテクチャとの統合がもたらす利点
Neonはコンピュートとストレージを分離したサーバーレスPostgresだ。ストレージはRAM、ローカルNVMe、Pageserver、オブジェクトストレージの4階層で構成される。ホットなページはローカルディスク並のレイテンシで返り、全階層でミスした場合のみオブジェクトストレージにアクセスする。
Lakebase Searchの両インデックスはこの階層構造に合わせて設計されている。フットプリントが小さいため上位階層に収まりやすく、深い階層へのアクセスが必要な場合も連続ブロックの大きなリードになるようレイアウトされている。
スケールトゥゼロとブランチング
Lakebase Searchのインデックスはオブジェクトストレージ上に永続化される。Neonの特徴であるスケールトゥゼロ（アイドル時にコンピュートを停止する機能）と組み合わせても、インデックスはそのまま維持される。コンピュートの再起動後、インデックスは再構築不要で即座にアタッチ可能だ。
コールドスタート直後はキャッシュが空のため、最初の数クエリはオブジェクトストレージのレイテンシを支払う。レイテンシ重視のワークロード向けには、lakebase_ann_prewarm()関数で初回クエリ前にインデックスをメモリにロードできる。
Neonのブランチ機能も検索チューニングに活用できる。本番データベースを数秒でブランチし、同じlakebase_annおよびlakebase_bm25インデックスを引き継いだ状態で、異なるフュージョン戦略（RRFのk値調整やベクトル・BM25スコアの重み付け変更）を試せる。
評価スイートを本番データで実行し、再現率とレイテンシを比較した上で、良ければ本番に適用、悪ければブランチを削除すればよい。本番環境はその間も通常通り稼働し続ける。
ブランチ機能により、本番データを使った検索チューニングの実験が安全に行える。インデックスを再構築する必要がないため、評価サイクルが短縮される。
HNSWからの脱却が実現した理由
Neonは2023年にpg_embeddingというHNSWベースのベクトル検索拡張をリリースした経緯がある。しかしHNSWは従来型サーバー向けに設計されたグラフインデックスであり、Neonのアーキテクチャとは根本的に相性が悪かった。
HNSWの検索はグラフのノードをたどりながら小さなランダムリードを繰り返す。メモリ上やローカルNVMeならマイクロ秒単位で処理できるが、オブジェクトストレージでは各ホップが依存関係のあるリモートリードになり、クエリ全体が数十ミリ秒単位のラウンドトリップの連鎖にシリアライズされてしまう。
Neonにとって「ディスク」はオブジェクトストレージであり、コンピュートはゼロにスケールする。S3へのランダムリードは数十ミリ秒かかり、コールドスタートではクエリ実行前にグラフ全体の再水和が必要になる。HNSWベースの拡張を差し替えるだけでは解決できない構造的な問題だった。
Lakebase Searchはこの問題に対して、インデックスの物理設計をオブジェクトストレージに適した形に根本から再設計した。HNSWのようなランダムアクセス前提のグラフ探索ではなく、事前分割と連続ブロックリードを前提とするIVFベースの設計に切り替えたことで、Neonのアーキテクチャ上で大規模検索が実用的になった。
導入時のポイントと今後の展望
Lakebase Searchの導入はNeonプロジェクト上で拡張機能を有効化するだけだ。クイックスタートガイドが公開されており、最初のハイブリッドクエリを試すまでの手順がまとめられている。インデックスパラメータやチューニングの詳細は公式ドキュメントを参照する。
既存のpgvectorやPostgreSQL全文検索からの移行はスムーズに設計されている。pgvectorのクエリ構文はそのまま動作し、tsvector型も変更不要だ。インデックス型を差し替え、<@>演算子とto_bm25query()を追加するだけでBM25検索に移行できる。
Neonチームは今後、lakebase_vectorとpgvectorの詳細なベンチマーク比較を公開予定としている。すでにDatabricksのアナウンスではLakebaseアーキテクチャ全体のベンチマークが示されており、今回の一般提供によりNeon上での実測値が明らかになる見込みだ。
この記事のポイント
- Lakebase Searchは
lakebase_vectorとlakebase_textの2拡張で提供される - 従来のpgvector HNSWが抱えていたメモリ消費・次元数制限・構築速度の問題をIVF + RaBitQで解決
- 全文検索はGINの疑似BM25から本格的なBM25 + Top-Kプッシュダウンに刷新
- Neonのスケールトゥゼロおよびブランチ機能と統合され、インデックス再構築不要で実験可能
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Neon、有料プランのデータ転送量を5倍に増量。500GBで実質エグレスフリー
サーバーレスPostgreSQLサービスのNeonは2026年6月1日、全有料プランに含まれる月間データ転送量を従来の100GBから500GBへと5倍に引き上げた。この変更は自動的に適用され、利用者側での設定変更は不要だ。
500GBという上限は、ほとんどの一般的なワークロードにおける全データ転送（エグレス）コストを実質的にゼロにする水準だ。Neonのブログによれば、チャットボットのバックフィル処理や設定ミスによる超過リスクも、この増量によって大幅に緩和される。
本記事では、増量の具体的な内容と背景、利用者が知っておくべきポイントを整理する。
月間500GBへの増量。その具体的な内容
今回の変更の核心はシンプルだ。Neonの全有料プラン（Launch、Scale、Enterprise）において、月間のパブリックデータ転送（エグレス）の無料枠が100GBから500GBに拡大された。
500GBを超過した場合の追加課金体系に変更はない。超過分はこれまでと同一の従量課金レートで計算される。Neonの記事では「データ転送の計測方法や料金体系に変更は一切ない」と明言されている。
変更は自動適用。請求書にも即時反映
この増量は2026年6月1日からユーザー側の操作なしで自動適用される。Neonのコンソール（管理画面）で利用状況を確認可能で、6月分の請求書には新たな500GBの枠が反映される。
なぜNeonは5倍への増量を決断したのか
Neonのブログ記事は、意思決定の背景を率直に説明している。最大の動機は「予期せぬエグレス課金の排除」だ。
エグレス課金のストレスを根本から減らす
クラウドデータベースにおけるデータ転送料金は、しばしば利用者にとっての「見えないコスト」となる。チャットボットが想定以上にデータを取得したケース、分析ジョブが大量の履歴データを読み込んだケース、設定ミスでループ接続が発生したケースなど、原因は多岐にわたる。
これらの超過は後になってから請求書で気づくことが多く、事後対応が難しい。Neonの著者Carlo Daniele氏は「請求書に届いてからでは遅すぎる」と指摘している。500GBへの増量は、この「事後ショック」をほとんどのユーザーから無くす狙いがある。
競合との差別化とサーバーレスの信頼性向上
サーバーレスデータベース市場では、Vercel PostgresやSupabaseなどもデータ転送枠を設けている。500GBという閾値は、これらのサービスと比較しても実質的な「エグレスフリー」を実現する水準だ。
Neonにとって、この変更はプラットフォームの信頼性向上と、サーバーレスアーキテクチャへの移行障壁を下げる施策といえる。特にスタートアップや個人開発者にとって、突発的なコスト増はサービス継続のリスクになりうる。その不安を軽減する効果は大きい。
利用者に求められる対応と確認方法
必要な対応は一切なし
繰り返しになるが、利用者が実施すべき設定変更や申し込みは存在しない。Neonの全有料プラン契約者に対し、2026年6月1日以降の月間データ転送量が自動的に500GBへと引き上げられている。
利用状況の確認方法
自身のデータ転送量を把握したい場合は、Neon Consoleにログインし、請求および利用状況のダッシュボードでエグレス使用量を追跡できる。不明点はNeon公式Discordコミュニティで質問することも可能だ。
今後のデータ転送戦略とユーザーへの影響
今回の増量は、Neonが「データ転送をコスト障壁にしない」という姿勢を明確に打ち出したものと捉えられる。サーバーレスデータベースの利点である「従量課金の柔軟性」は、往々にして「予測不能なコスト」と紙一重だ。
500GBの無料枠は、その両面を切り離す試みだ。実際の利用データにもとづきNeonが「ほとんどのワークロードでエグレス課金が発生しなくなる」と明言している点は、単なるマーケティングではなくユーザー利用統計に裏付けられた判断といえる。
将来的にNeonがさらなるデータ転送枠の拡大や、完全なエグレスフリー化に踏み切る可能性もあるが、現時点ではこの変更が最大のハードルを解消したと評価できる。
この記事のポイント
- Neonは2026年6月1日より、全有料プランの月間データ転送量を100GBから500GBに増量
- 変更は完全自動適用。利用者による操作や設定変更は不要
- 500GB超過分の従量課金体系に変更はなく、データ転送の計測方法も据え置き
- 大半の一般的なワークロードがエグレス課金の対象外に。実質的なコスト障壁が大幅に低下
- 予期せぬエグレス課金への不安を解消し、サーバーレスデータベースの信頼性を強化
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験