Postgresで爆速全文検索！シンプルで強力な「Tin」が登場

「Tin」は、PostgreSQL向けの軽量かつ高機能な全文検索ソリューションです。複雑な設定や外部サービスの構築に悩まされることなく、Postgresの環境そのままで効率的な全文検索機能を手に入れることができます。シンプルさを重視するエンジニアにとって、有力な選択肢となるでしょう。

気になる人向けに - https://planetscale.com/docs/postgres/search/get-started#local-development-and-ci:

現時点では、クラウドサービスと同等のパフォーマンスを持つローカル拡張機能は提供されておらず、クラウド環境のみで利用可能です。

ローカル版の https://github.com/planetscale/lead は主に構文のテスト用であり、同等のパフォーマンス特性は持っていません。

SQL内でのFTS（全文検索）には苦労させられてるよ（SQLiteもMSSQLもね）。リレーショナルな要件と、ドキュメントをどう保存すべきかという話の間には、かなり大きなインピーダンスミスマッチがあることがよくあるから。

自分はずっと、SQLをシステムの記録媒体として使いつつ、外部のLuceneインデックスを構築・保守するやり方を好んできたんだ。こういった組み込みのFTS機能が、ハイブリッドアーキテクチャがもはや不要になるレベルに達していると思う？あと、このプロバイダーにはどれくらいのカスタマイズ性があるんだろう？

各データベース企業がこぞって新しい全文検索機能を提供している現状は、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-search がある。
そして今度はPlanetScale。

知る限り、これらはすべてBM25アルゴリズムの実装だね。AIエージェントに「BM25について読んで、好みのシステムに実装して」って指示すればできてしまうんだから面白いよ。それぞれのシステムでどう設計・統合されるかによって、まだまだ性能を引き出せそうだけど、これが急速なコモディティ化につながるんじゃないかと疑わずにはいられない。

面白いことに、SQLiteのFTSはLuceneクエリを標準でサポートしていて、パフォーマンスもかなり良いんだ。たしか書き込みはしばらくするとかなり遅くなるはずだけど。
PostgreSQLがなぜその実装を自前のデータベースに組み込まないのか、ずっと不思議に思っていたんだよね。個人的にはts_queryの経験があまり良くなくてさ。LIKEよりはマシだけど、せいぜいその程度だし、何よりインデックスサイズがとんでもないことになるし…
もしこの拡張機能がオープンソースになって現実世界でテストできるようになれば、きっといい落とし所が見つかるはず。

PlanetScaleも試してみたいけど、私たちはNeonのブランチモデルにどっぷり依存しちゃってるんだよね。本当にあれには完全にハマらされたよ！

プロジェクトの規模によるだろうけど、MySQLとSQLiteのFTS機能は結構うまく使えてるよ。オープンソースの旗手であるPostgresが、これまで満足のいくFTSを搭載していなかったなんて意外だね…？

Postgresのマニュアルを読んでみて。驚くほど高機能な検索機能が標準で搭載されているから。

Postgresにはpg_fts（tsvector/tsquery/tsrank）があって、機能的なインデックス作成やクエリ最適化と統合された、かなり洗練された全文検索パッケージだよ。なぜわざわざ、コアの一部ではない「バイブスで書かれたような（vibecoded）」ものを使わなきゃいけないんだ？

PostGISのTIN（Triangulated Irregular Network）データ型と名前が衝突する可能性があるので注意。

Postgres向けのFTSソリューション全般に言えることで、個人的にうまくいっていない点がもう一つある。それは「多言語サポート」だね。

例えば今回のものだと、CJK言語（日本語・中国語・韓国語）のサポートについて触れられていない。つまり、中国語などのトークナイズが文字単位（1トークン＝1文字）になってしまい、技術的には動くし結果は出るけれど、効率が非常に悪いんだ。あと、ステミング（databases -> databaseのような活用形の正規化）も見たところ欠けているから、関連する単語がヒットするような検索は期待できないだろうね。単に大文字・小文字を統一したり、アクセント記号を無視したりするだけでは、機能的ではあっても強引な解決策に過ぎないよ。

理想を言えば、次のような機能がほしい：

• レコードごとに言語を指定できる言語認識型のトークナイズ。ステミングなども含む。また、一般的な言語に対して有用な定義済み設定があること（Postgres標準のものは多くの言語に対応できていないため）。
• CJKサポート（単語の境界でトークナイズする）。
• オプションとしてのアクセント記号や大文字・小文字の無視。

ほとんどのソリューションが「英語コンテンツ」前提に見えるし、これらすべてを満たすものにはまだ出会えていないよ。