編集、2016年—両方ではないのはなぜですか？
PostgresとLuceneに興味があるなら、両方ではないのはなぜですか？ ZomboDB を確認してください Elasticsearchをファーストクラスのインデックスタイプとして統合するPostgresの拡張機能。まだかなり初期のプロジェクトですが、私には本当に有望に見えます。
（技術的にはHerokuでは利用できませんが、それでも一見の価値があります。）
開示：私はWebsolr
の共同創設者です および
Postgresの全文検索について読んだところ、単純なユースケースではかなり堅実ですが、Lucene（したがってSolrとElasticSearch）がパフォーマンスと機能の両方の点で優れている理由はいくつかあります。
手始めに、 jpountz SolrがPostgresよりもはるかに高速なのはなぜですか？ 本当に消化するために、数回読む価値があります。
最近のRailsCastエピソード Postgres全文検索とSolrの相対的な長所と短所を比較します。ここで要約します：
Postgresの実用的な利点
- 他の何かを設定して維持（または料金を支払う）する代わりに、すでに実行している既存のサービスを再利用します。
- 非常に遅いSQL
LIKEよりもはるかに優れています オペレーター。 - すべて同じデータベースにあるため、データの同期を維持する手間が省けます。一部の外部データサービスAPIとのアプリケーションレベルの統合はありません。
Solr（またはElasticSearch）の利点
頭のてっぺんから、順不同…
- 通常のデータベースの負荷とは別に、インデックス作成と検索の負荷をスケーリングします。
- アクセントの正規化、言語ステミング、Nグラム、マークアップの削除などのより柔軟な用語分析…スペルチェック、「リッチコンテンツ」（PDFやWordなど）の抽出などの他の優れた機能…
- Solr / Luceneは、Postgres全文検索TODOリストですべてを実行できます。 大丈夫です。
- 検索時に効率的にカスタマイズできる、はるかに優れた高速な用語関連性ランキング。
- 一般的な用語や複雑なクエリの検索パフォーマンスがおそらく高速になります。
- おそらくPostgresよりも効率的なインデックス作成パフォーマンス。
- プライマリデータストアからインデックスを分離することで、データモデルの変更に対する許容度を高めます
明らかに、Luceneをベースにした専用の検索エンジンがここでのより良いオプションだと思います。基本的に、Luceneは検索の専門知識の事実上のオープンソースリポジトリと考えることができます。
ただし、他の唯一のオプションがLIKEの場合 演算子の場合、Postgres全文検索は間違いなく勝利です。