ハクソク

世界を動かす技術を、日本語で。

Tin: PostgreSQLの全文検索

2026年9月19日原文(planetscale.com)

概要

  • Postgres向けの新しい全文検索拡張機能「 TIN」を発表
  • 高速性・高機能・信頼性 を兼ね備えた全文検索を実現
  • 既存の全文検索インデックスを凌駕する パフォーマンス
  • 多様な検索クエリや同時更新にも対応
  • ベンチマーク結果で 圧倒的な優位性 を証明

Postgres向け全文検索拡張「TIN」概要

  • お客様から最も要望の多い 全文検索機能 を実現するため、 TIN (Text INdex) をリリース
  • TINはPostgresおよびNekiデータベース向けに GA（一般提供） として即日利用可能
  • インデックス作成例
    • CREATE INDEX an_index_name ON table_name USING tin(text_column_name);
    • SELECT * FROM table_name WHERE text_column_name ==> 'some words';
  • Boolean式、フレーズ、スパン検索 に対応
  • ファジー、ワイルドカード、正規表現 による検索をサポート
  • 大文字小文字・アクセントの無視、 COUNT(*)やBM25スコア付きtop-kクエリ も対応
  • 複雑なWHERE句や他カラムとのJOIN、継続的な更新、レプリケーション、バックアップ、トランザクション可視性にも完全対応
  • 既存の全文検索インデックス（ParadeDB, pg_textsearch, Postgres GIN等）では満たせなかった要件を TINがすべてカバー

TINの主な用途

  • eコマース ：すべてのキーワードを含む上位10商品をBM25スコア順に検索
    • SELECT * FROM products WHERE description ==> 'stretch denim jeans' ORDER BY tin.score(ctid) DESC LIMIT 10
  • リーガルディスカバリ ：特定キーワードを含むすべての文書を検索（順位付けなし）
    • SELECT * FROM emails WHERE body ==> '[insider trading conspiracy]'
  • 写真タグ管理 ：特定タグを持つ写真の正確な件数を取得
    • SELECT COUNT(*) FROM photos WHERE tags ==> '"san francisco"';
  • 挿入・更新・削除 と並行した検索、 即時反映 を実現

ベンチマークとパフォーマンス評価

  • Wikipedia全体、Redditコメント（2.3TB）、研究論文/法務文書/書籍/Enronメール（797GB） など多様なコーパスで性能検証
  • 本記事でのベンチマークはStack ExchangeのQ&A（85GB、1.5億件）を利用
  • クエリパターン： AND/OR/フレーズ の3種を1,719件生成し評価

テスト環境

  • AWS i7i.8xlarge EC2 （ローカルNVMe, AVX-512 CPU, 8vCPU, 32GB RAM）で隔離コンテナ実行
  • ParadeDB Benchmarker による測定、Postgresパラメータの調整（max_parallel_workers, shared_buffers, maintenance_work_mem等）

比較対象

  • TIN v1.0.2
  • ParadeDB v0.25.2
  • pg_textsearch v1.4.0
  • Postgres GIN v18.6

インデックス構築時間・サイズ

  • インデックスサイズはコーパスの33～61%、構築時間は8～129分
  • TIN以外は32GB RAM制限下でビルド失敗、ビルド時のみRAM増強
  • クエリ実行前に全て32GBに統一

| エンジン | 構築時間 | サイズ | 必要RAM | |:---------------|:--------|:--------|:--------| | TIN | 8分10秒 | 50.7GB | 32GB | | ParadeDB | 19分20秒| 52.1GB | 64GB | | pg_textsearch | 26分49秒| 41.5GB | 128GB | | Postgres GIN | 2時間9分| 28.0GB | 64GB |

主要ベンチマーク結果

混合クエリ（top-10, 読取のみ）

  • TIN ：QPS 199、p99レイテンシ256ms、MB/クエリ65
  • ParadeDB ：QPS 7.9、p99 6765ms、MB/クエリ582
  • GIN ：メモリ不足で完走不可
  • pg_textsearch ：AND/フレーズ非対応

AND・フレーズクエリ（top-10, 読取のみ）

  • TIN ：QPS 242、p99 212ms、MB/クエリ73
  • ParadeDB ：QPS 24、p99 1279ms、MB/クエリ668
  • GIN ：QPS 0.4、p99 288,066ms、MB/クエリ595

ORクエリ + 同時更新

  • TIN ：QPS 125、p99 354ms、MB/クエリ77、更新件数270,279
  • ParadeDB ：QPS 2.2、p99 12,634ms、MB/クエリ394、更新185,584
  • pg_textsearch ：QPS 3.5、p99 8,409ms、MB/クエリ11,656、更新735

インデックスがメモリに収まる場合（Wikipedia 8GB）

  • TIN ：QPS 10,260、p99 2ms、MB/クエリ1.7
  • ParadeDB ：QPS 291、p99 95ms、MB/クエリ22
  • GIN ：QPS 1.4、p99 30,292ms、MB/クエリ2.5

TINの高速性の理由

  • すべてのドキュメントポスティングにPostgresのctid（物理位置）を利用
  • 連続したドキュメントID ではなくctidを使うことで、 ベクトル化された高速な集合演算 （AND/OR）が可能
  • 圧縮ポスティングリスト による効率的な検索
  • 現代CPUのSIMD命令 を最大限活用する設計

まとめ

  • TIN は既存の全文検索インデックスを大きく凌駕する パフォーマンス と 機能性 をPostgresにもたらす
  • 多様な検索ニーズ と 高い同時更新性 に対応
  • アプリケーション開発者 にとって、Postgresでの全文検索実装の新たな選択肢

Hackerたちの意見

誰か興味があるかもしれないけど、https://planetscale.com/docs/postgres/search/get-started#loc...: 現時点では同じパフォーマンスのローカル拡張は提供されてないみたい。クラウドサービスだけで使えるやつだね。ローカル版の https://github.com/planetscale/lead は主に構文のテスト用で、同じ性能特性は持ってないよ。

└

彼らにとっては普通になりつつあるけど、Nekiも同じだね。これで使うことは完全に無理になった（今はそのスケールが必要な問題はないけど、過去にはあった）。Postgresのライセンスはこれを許可してるけど、個人的にはあまりいい気分じゃないな。それに、実際には「Postgres用のフルテキスト検索」じゃなくて「私たちのホスティング版Postgres用のフルテキスト検索」だから、タイトルがちょっと誤解を招くね。

└

問題は、彼らがベアメタルをサポートしていないことだね。ベアメタルサーバーでPlanetScaleを使いたいな。

SQL（SQLiteやMSSQL）の中でFTSに苦労してる。リレーショナルな問題と文書の保存方法の間に結構なインピーダンスミスマッチがあることが多い。いつもSQLを記録のシステムとして使って、外部のLuceneインデックスを構築・維持するのが好きだったんだ。これらの統合FTS機能は、ハイブリッドアーキテクチャが意味を持たなくなるほど進化してると思う？このプロバイダーにはどれくらいのカスタマイズがあるのかな？

└

私はTINの開発者の一人で、ユーザー名をググればこの分野に長くいることがわかると思う。最初の質問の答えは簡単に言うと「はい」。二つ目の質問については、TINやPlanetScaleが提供していないと思うカスタマイズは何が必要なの？これらは私たちがすぐにできることだよ。

└

私の経験では、テキストの大きな逆インデックスがデータベース内に直接あるのは結構普通だよ。必ずしも大きな文書ではないけど、ボリュームのある自由テキストレコードは確かにある。bm25とUnicodeのBreakIteratorを使うのは、これを構築するのにとても良い方法だね。基本的にはデータベース内にLuceneを入れるようなもので、データベースがすでに大きいときには理にかなってる。検索をデータベースの外に移そうとするところは、大きなデータベースを避けようとしてることが多いけど、結局はどちらの悪いところも引き受けることになることが多いね。

すべてのデータベース会社が新しいフルテキスト検索機能を提供してるのは、AIコーディングの生産性が現実に現れている例だと思う。最初はparadeDBとpg_searchから始まったね。https://www.paradedb.com/blog/introducing-search Timescaleはpg_textsearchを持ってるし、https://github.com/timescale/pg_textsearch NeonとDatabricksはLakebase Searchを提供してる。https://docs.databricks.com/aws/en/oltp/projects/lakebase-se... 今はPlanetScaleも。私の知る限り、これらはすべてBM25アルゴリズムの実装だよ。エージェントにBM25について読ませて、自分の選んだシステムに実装させることができる。面白いね。まだまだアーキテクチャや各システムへの統合の仕方で絞り出せるものがたくさんありそうだけど、これが攻撃的なコモディティ化につながるんじゃないかって気もする。

└

ParadeDBの実装は、AIコーディングが登場する前のTantivyクレートに基づいているよ。

└

これにはかなりの真実があるけど、やっぱりドメインの専門家がいるからこそ、もっと早く進められるんだよね。Planetscale（エージェント開発手法を使っていると仮定すると）は、非常に経験豊富なPostgres開発者のチームがいるからこそ、あのパフォーマンスを実現できたんだと思う。彼らのPostgres内部に関する知識が、投稿で説明されているアーキテクチャを使った計画にモデルを導くための洞察を与えたんだろうね。これはモデルだけではできないことだよ。* 世界の専門家 + LLMs = 山を動かす。 (* 研究チームの内部から見ると、ちょっと違うものが見えてるのは確かだね。彼らは、トークンを大量に消費することで、モデルが自らの洞察から新しいことをできることを示している。)

└

あなたの仮説には完全には同意しないけど、彼のTINの部分で難しいのはBM25じゃなくて、その周りのハードコアなストレージエンジンの作業だと思う。LLMは例えば、1秒間に千件の更新がある中でセグメントマージが得意なの？「パフォーマンスの底に達した」ってClaudeに言われたこともあったけど、自分でやってみたらかなり改善できたこともあったし。理論にとってもっと厳しいのは、paradebのpg_searchがエージェントコーディングの数年前に存在してたと思うことかな？

└

記事の中にAIやLLMの使用についての言及は見当たらなかったよ。記事はすごく詳しくて、どうやって実現したのか深く掘り下げてる。むしろ、データベースレベルの専門知識や既存の実装を理解して、最適化の機会を見つけたってことを示してるだけだよ。明示的に言及されてない限り、関わった人たちの功績を薄めるのはやめよう。

└

BM25は簡単な部分だね。コードは多分十数行、もしくは二行くらいだと思う。実際の作業は、そのシンプルな関数を書けるようにするためのインデックスの設計にあるんだ。メモリ内のデータ構造、ディスク上のデータ構造、それらを同期させること、フォールトトレランス、バッチ処理、他にもいろいろ。Claudeに「BM25を実装して」って頼んでも、欲しいものは得られないよ。こういうのが多いね。何も分かってない人がLLMからゴミみたいな結果を引き出してる。

Hacker Newsで議論の続きを見る