結論(おすすめ1つ)
Typesense に乗り換えるべき。理由は3点ある。まず Algolia 互換の API レイヤーが公式に用意されており、クライアントコードをほぼ変えずに移行できる。次にオープンソース版をセルフホストすれば月額固定費ゼロで運用でき、クラウド版(Typesense Cloud)も従量課金を抑えやすい料金体系だ。最後に日本語を含む多言語トークナイザが組み込みでサポートされており、形態素解析ライブラリを別途セットアップしなくてよい。
比較表(料金/無料枠/移行コスト/対応言語)
| ツール | 無料枠・料金 | 移行コスト | 対応言語(多言語) | ホスト形態 |
|---|---|---|---|---|
| Typesense | セルフホスト無料。クラウドは公式料金ページで要確認 | 低(Algolia 互換 API あり) | 日本語含む多言語対応(組み込み) | セルフ / マネージド |
| Meilisearch | セルフホスト無料。クラウド版あり、公式ページで要確認 | 中(API 設計が異なる) | 多言語対応(CJK は設定要) | セルフ / マネージド |
| OpenSearch | AWS Free Tier あり(条件は公式で要確認) | 高(Elasticsearch 系、設定が複雑) | プラグインで拡張可 | AWS マネージド / セルフ |
| Elasticsearch | Elastic Cloud に無料枠あり(公式で要確認) | 高(DSL が独自、学習コスト大) | 多言語プラグインで対応 | マネージド / セルフ |
| Orama | 無料プランあり(上限は公式で要確認) | 中(JS ランタイム特化、Node/Edge 向け) | 基本的な多言語対応 | クラウド / エッジ |
移行手順
Algolia から Typesense へ移行する手順を示す。
1. Typesense サーバーを起動(Docker)
docker run -d \
-p 8108:8108 \
-v $(pwd)/data:/data \
typesense/typesense:latest \
--data-dir /data \
--api-key=YOUR_TYPESENSE_API_KEY \
--enable-cors
2. Algolia 互換レイヤーをセットアップ
npm install typesense-instantsearch-adapter
// 既存の Algolia InstantSearch コードを最小変更で差し替える
import TypesenseInstantSearchAdapter from 'typesense-instantsearch-adapter';
const typesenseAdapter = new TypesenseInstantSearchAdapter({
server: {
apiKey: 'YOUR_TYPESENSE_API_KEY',
nodes: [{ host: 'localhost', port: 8108, protocol: 'http' }],
},
additionalSearchParameters: {
query_by: 'title,body', // Algolia の searchableAttributes に相当
},
});
// algoliasearch() を置き換えるだけで InstantSearch がそのまま動く
const searchClient = typesenseAdapter.searchClient;
3. Algolia からデータをエクスポートして Typesense にインポート
# Algolia からインデックスを JSON 出力(algolia-cli が必要)
algolia objects browse YOUR_INDEX_NAME --output-file records.jsonl
# Typesense のコレクションを作成してインポート
curl -X POST 'http://localhost:8108/collections' \
-H 'X-TYPESENSE-API-KEY: YOUR_TYPESENSE_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"name": "your_index",
"fields": [
{"name": "title", "type": "string"},
{"name": "body", "type": "string"}
],
"default_sorting_field": ""
}'
# JSONL を一括インポート
curl -X POST 'http://localhost:8108/collections/your_index/documents/import?action=upsert' \
-H 'X-TYPESENSE-API-KEY: YOUR_TYPESENSE_API_KEY' \
--data-binary @records.jsonl
4. 動作確認
curl 'http://localhost:8108/collections/your_index/documents/search?q=テスト&query_by=title,body' \
-H 'X-TYPESENSE-API-KEY: YOUR_TYPESENSE_API_KEY'
向き不向き
Typesense が向くケース
- 月額コストを削減したいスタートアップやインディー開発者
- Algolia の既存コードベースを大きく書き換えたくないチーム
- Docker / Kubernetes でセルフホストできる運用体制がある場合
- 日本語検索を追加設定なしで動かしたい場合
Meilisearch が向くケース
- ダッシュボードや管理 UI を非エンジニアも触る必要があるチーム
- Rust 製のシンプルさを優先し、設定ファイルを最小にしたい場合
OpenSearch / Elasticsearch が向くケース
- ログ分析・アナリティクスと全文検索を同一インフラに統合したい大規模サービス
- 既に AWS / Elastic のエコシステムに深く依存している場合
避けるべきケース
- Typesense: 数十億件規模の大規模インデックスはセルフホストのチューニングが難しく、OpenSearch を先に検討すべき
- Meilisearch: CJK 検索は追加設定が必要で、設定を誤るとトークン分割が壊れる
- OpenSearch / Elasticsearch: 小規模プロジェクトでは運用コストと学習コストが利益を上回りやすい
- Orama: Node.js / エッジランタイム以外のバックエンド(Python, Go 等)では SDK が薄く、移行コストが読みにくい
Top comments (0)