💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — Search Is Infrastructure Again

In the mid-2010s, search was the era of SaaS. Algolia bundled indexing, ranking, and UI widgets and sold them as one product, and "no one writes their own search anymore" became a fixture in SaaS sales decks.

The 2026 landscape is completely different.

- Algolia still leads, but the roughly USD 1.0 to 1.4 per million searches has become tough for e-commerce and media to bear.

- After Elastic switched to the Elastic License 2.0, AWS forked OpenSearch and the ALv2 OSS camp split into two branches.

- Meilisearch 1.13, Typesense 27, and Manticore Search 6.x cemented themselves as "Algolia alternatives".

- ParadeDB created a new approach that finishes BM25 search inside Postgres itself.

- Orama (formerly Lyra) runs TypeScript-built search in browsers, edges, and servers alike.

- As AI-era RAG demand exploded, the trend of handling vector, BM25, and hybrid in one engine became the default.

This article surveys the 2026 self-hosted search engine landscape in one breath — why you would self-host, which engine fits which workload, how Korean and Japanese tokenizers plug in, and how RAG and vector search enter the picture.

Chapter 1 · Why Self-Host — Cost, Control, Customization

Three reasons to self-host first.

First, **cost**. Algolia charges around USD 1.0 to 1.4 per million searches, with index records billed separately. At 1M daily searches in e-commerce, that is USD 30 to 50K per month. Even Elastic Cloud's Search Premium tier starts at several hundred USD per node per month. Self-hosting Meilisearch or Typesense lets you serve the same traffic from a single EC2 r6g.large (around USD 80 per month).

Second, **data control**. Search queries are the data where user intent shows up most clearly. The moment medical, financial, or legal verticals send queries to SaaS, compliance burden grows. New regulations like the EU's DSA and DSP also ask where search logs are processed.

Third, **customization**. To freely change tokenizers, ranking, synonyms, stop words, and field boosting, you eventually have to dig into the engine itself. Languages like Korean and Japanese that require morphological analysis make this even truer.

The weight of those three axes has moved rapidly toward self-hosting since 2024.

Chapter 2 · Algolia — The Standard of Managed Search

Let us first cover Algolia as the benchmark.

| Item | Detail |

| ----------- | -------------------------------------------- |

| Launched | 2012 |

| License | Closed (commercial) |

| Strengths | UI widgets, global distribution, instant index |

| Weaknesses | USD 1 to 1.4 per million, external data |

| Key workloads | Store search, media, in-app SaaS search |

NeuralSearch, launched in 2023, is a vector plus lexical hybrid. It keeps your data in place and only adds embedding indexing, so no separate vector DB is needed. DocSearch is a free subset of Algolia deployed across open source docs sites.

The catch is pricing. As traffic grows, Algolia takes the per-search margin. The rise of self-hosted engines is a direct reaction to that structure.

Chapter 3 · Meilisearch 1.13 — France's "Easy Search"

Meilisearch is an MIT-licensed search engine that started in Paris in 2018. Written in Rust, it summarizes as "as easy as Algolia, but self-hostable".

Start with one Docker line

docker run -p 7700:7700 getmeili/meilisearch:v1.13

Indexing — POST a JSON blob

curl -X POST 'http://localhost:7700/indexes/products/documents' \

-H 'Content-Type: application/json' \

--data-binary @products.json

Search

curl 'http://localhost:7700/indexes/products/search' \

-H 'Content-Type: application/json' \

--data-binary '{"q":"shoes","limit":5}'

Features:

- **Typo tolerance**: auto-match within edit distance 1 to 2. "shoees" matches "shoes".

- **Instant search**: roughly 50ms response target per keystroke. Average p99 under 50ms.

- **Multilingual**: ICU tokenizer by default, auto-detects Korean, Japanese, Chinese.

- **AI search beta**: embedders added in 1.6, hybrid search GA in 1.13.

- **Single-node first**: full clustering planned for v2.

The fastest adoption scenarios are SaaS in-app search, docs sites, and small to mid-size e-commerce. Distribution is weak, so if your index passes 100GB, look elsewhere.

Chapter 4 · Typesense 27 — The Algolia Open Source Clone

Typesense is a GPLv3 search engine launched in 2019. Written in C++, it closely follows Algolia's API, ranking, and UI widgets. With v27 in 2024, it filled out clustering, vector search, and conversational search.

docker-compose.yml

services:

typesense:

image: typesense/typesense:27.0

environment:

TYPESENSE_API_KEY: xyz

TYPESENSE_DATA_DIR: /data

volumes:

- ./typesense-data:/data

ports:

- 8108:8108

Create a collection

curl 'http://localhost:8108/collections' \

-X POST \

-H 'X-TYPESENSE-API-KEY: xyz' \

-H 'Content-Type: application/json' \

-d '{

"name": "products",

"fields": [

{"name": "title", "type": "string"},

{"name": "price", "type": "float"},

{"name": "embedding", "type": "float[]", "num_dim": 768}

]

Typesense **clusters more naturally** than Meilisearch. Raft-based replication is stable from three nodes up. Direct compatibility with instantsearch.js is another strength. That is why many e-commerce teams migrate from Algolia to Typesense.

| Item | Meilisearch | Typesense |

| -------- | ------------------- | ---------------------------------- |

| Language | Rust | C++ |

| License | MIT | GPLv3 |

| Cluster | Weak (v2 planned) | Strong (Raft) |

| API | Native | Algolia-compatible |

| Memory | Lower | Higher (index resident) |

| Typos | Strong | Strong |

Chapter 5 · Manticore Search — The True Heir of Sphinx

Manticore Search is the legitimate heir to Sphinx Search from the 1990s. GPLv3, C++, and one of the oldest full-text engines around.

-- Manticore's home is its SQL interface

CREATE TABLE products (

title TEXT,

description TEXT,

price FLOAT,

category STRING

);

INSERT INTO products VALUES (1, 'Red shoes', '...', 99.99, 'shoes');

SELECT * FROM products WHERE MATCH('red');

Features:

- **SQL-first**: accepts the MySQL wire protocol so any SQL client can connect.

- **Full-text expressions**: phrase, proximity, wildcard, regex.

- **RT indexes**: real-time inserts and updates.

- **Percolation**: reverse search by storing queries instead of documents and matching incoming docs.

- **Vector search**: added in 6.x, HNSW-backed.

There is **more tuning surface** than Meilisearch or Typesense. The indexer, ranker, and tokenizer can be configured deeply, and it stays fast on bulky text. The learning curve is steep though.

Chapter 6 · OpenSearch 2.x — AWS's Elasticsearch Fork

When Elastic switched to Elastic License 2.0 in 2021, AWS forked the Elasticsearch 7.10 source and turned it into OpenSearch. It stays on ALv2.

Spin up a three-node cluster with the Helm chart

helm install opensearch opensearch/opensearch \

--set replicas=3 \

--set persistence.size=100Gi

Create an index

curl -X PUT 'localhost:9200/products' -H 'Content-Type: application/json' -d '{

"mappings": {

"properties": {

"title": {"type": "text", "analyzer": "nori"},

"price": {"type": "float"},

"embedding": {"type": "knn_vector", "dimension": 768}

}

The core that OpenSearch added in 2.x is **Neural Search**. It attaches an embedding pipeline to the index so vectors are generated at ingest time, then combines BM25 and vector scores in queries via RRF.

`RRF(k=60)` is the default for fusing two scores.

OpenSearch's strength is distribution. There is proven operational experience on 100-node clusters, 1PB indexes, and multi-tenant deployments. The downside is memory and disk cost plus JVM tuning overhead. If you double as a log search platform, it is an overwhelmingly strong choice.

Chapter 7 · Elasticsearch 8.x / 9.0 — The Licensing-Split Original

The Elasticsearch original moved from 8.x to 9.0 with features like Vector Search (KNN), ESQL (a SQL-like query language), and Search AI Platform filled in.

[Elasticsearch 9.0 highlights]

- ESQL: new query language, pipeline expressions

- KNN: HNSW-based vector search, GPU accel beta

- Semantic search: ELSER embeddings built in

- Search AI: built-in RAG pipeline

- License: Elastic License 2.0 or SSPL (pick one)

The biggest change is the **AGPL license addition**. Since August 2024, you can pick from ELv2, SSPL, or AGPLv3. In practice it reads as a signal of re-joining the OSS camp.

Elasticsearch still has the **richest feature set**. Machine learning, APM, security, and RUM all roll up in the Elastic Stack (ELK). Compatibility with OpenSearch keeps diverging after 7.10 though.

Chapter 8 · Solr 9 — The Pride of Classic Enterprise

Apache Solr is the longest-running OSS search engine, built on Lucene since 2004. With 9.0 it moved to Java 11 and reduced SolrCloud's ZooKeeper dependency.

Solr's strength is **freedom in tuning**. Tokenizers, filters, and rankers can be wired in XML, and tokenizers like Mecab-ko for Korean, Kuromoji for Japanese, and ICU for Chinese all plug in.

LINE Yahoo ran Japanese search on Solr for years and has been gradually migrating to Vespa since 2024. As Elasticsearch pulled ahead on operability and UX, Solr's market shrank, but it is still alive in enterprises that need precision tuning.

Chapter 9 · Vespa.ai — The Ranking Engine from Yahoo

Vespa is a search and ranking platform that Yahoo open sourced in 2017. ALv2, C++ core, summarized as "BM25 plus vector plus ranking models in one place".

schema.sd — Vespa's schema DSL

schema product {

document product {

field title type string {

indexing: index | summary

index: enable-bm25

}

field embedding type tensor(x[768]) {

indexing: attribute | index

attribute {

distance-metric: angular

}

rank-profile hybrid inherits default {

first-phase {

expression: bm25(title) + closeness(embedding)

}

Vespa's differentiator is that **ranking models run inside the engine**. You attach an ONNX model and run two-stage ranking (first-phase and second-phase), with GBDT, MLP, or transformer models in play.

Yahoo's ad, news, and mail searches all run on Vespa. It is roughly the only OSS search engine that treats tensor operations as a first-class citizen. The learning curve is huge and it is heavy for small teams.

Chapter 10 · Quickwit, Tantivy, Bleve, Whoosh — Library and Specialized Engines

| --------- | -------- | -------- | -------------------------------------- |

**Quickwit** specializes in log search. It searches indexes directly on object storage (S3, GCS), enabling "storage and compute separation" and advertising more than 10x cost reduction over Elasticsearch on 1TB logs. Datadog acquired it in 2024 and some features are being absorbed into Datadog internal search.

**Tantivy** is a Lucene-like library in Rust. Other engines (Meilisearch, ParadeDB, Quickwit) embed Tantivy internally.

**Bleve** is the Go ecosystem's full-text library. CouchDB's search runs on Bleve.

**Whoosh** is a pure Python search library. Better for learning and small tools than for performance.

Chapter 11 · ParadeDB and pg_search — Finishing It Inside Postgres

ParadeDB is a 2023 effort that bolts BM25 full-text search onto Postgres. The core is the `pg_search` extension.

-- After installing pg_search

CREATE EXTENSION pg_search;

-- BM25 index

CREATE INDEX product_search_idx ON products

USING bm25 (id, title, description)

WITH (key_field='id');

-- Query

SELECT id, title, paradedb.score(id) AS score

FROM products

WHERE title @@@ 'red shoes'

ORDER BY score DESC

LIMIT 10;

ParadeDB's strength is that it **finishes everything in one database**.

- No separate search engine to operate — one Postgres does it.

- No ETL/CDC pipeline — the index updates inside the transaction.

- Permissions, transactions, and JOIN apply natively.

Combine with `pgvector` and you handle BM25 plus vector hybrid in the same Postgres instance. If more than 90 percent of search candidates already live in Postgres, ParadeDB is a remarkably strong choice.

Chapter 12 · Orama (formerly Lyra) — Embedded Search Written in TypeScript

Orama started as Lyra in 2022, rebranded in 2023, and is a TypeScript search engine. It runs in browsers, edges, or servers.

const db = create({

schema: {

title: 'string',

price: 'number',

embedding: 'vector[768]',

})

await insert(db, { title: 'Red shoes', price: 99.99, embedding: [...] })

const results = await search(db, {

term: 'shoes',

properties: ['title'],

limit: 5,

})

Features:

- **Pure JavaScript**: a single npm install with no native deps.

- **Embedded**: serialize the index and ship it with static hosting; search works in place.

- **Vector plus BM25**: both are supported, hybrid too.

- **Cloudflare Workers, Bun, Node, Deno** — all supported.

It fits small docs sites, JAMstack, and static e-commerce catalogs really well. Once the index reaches the hundreds of thousands of records, memory and load time become bottlenecks.

| Library | Size | Highlight |

| ------------ | -------- | ---------------------------------- |

| Orama | ~30KB | Full JS, even vector |

| MiniSearch | ~8KB | Lightweight full-text only |

| Fuse.js | ~12KB | Fuzzy matching focus |

| FlexSearch | ~10KB | Full-text, compact index |

| Lunr.js | ~28KB | Classic, around since jQuery days |

Chapter 13 · Shapes of Search Engines — Inverted Index, Vector, Hybrid

Three core shapes.

First, **inverted index plus BM25**.

documents:

doc1: "red shoes"

doc2: "blue shirt"

doc3: "red shirt"

inverted index:

"red" -> [doc1, doc3]

"shoes" -> [doc1]

"blue" -> [doc2]

"shirt" -> [doc2, doc3]

For the query "red shirt", you intersect the posting lists of `red` and `shirt` and sort by `BM25(doc, query)`. This has been the search standard for nearly 50 years.

Second, **vector plus ANN**.

embedding model -> 768-dim vector

insert into HNSW graph

query -> embed -> ANN search -> nearest K

Semantic search starts here. The reason "sneakers" matches "running shoes" is distance in vector space.

Third, **hybrid (BM25 plus vector plus RRF)**. The two scores combine via Reciprocal Rank Fusion. `RRF(k=60)` is the default formula. Since 2025 almost every engine (OpenSearch, Vespa, Elastic, Meilisearch, Typesense, ParadeDB) provides it as a built-in option.

Chapter 14 · Multi-Tenancy and Sharding

Big search engines come down to two axes — sharding and replication.

**Elastic/OpenSearch** splits an index into N shards and replicates each shard R times. Data moves across hot-warm-cold tiers. Hot nodes sit on SSD, cold nodes on object storage.

**Vespa** groups content clusters into groups and distributors, with a container cluster dispatching queries on top.

**Meilisearch/Typesense** implements multi-tenancy by splitting indexes across nodes. Tenant equals index equals filter key. Small tenants can share an index with a multi-tenant key; large tenants get their own.

**ParadeDB** uses Postgres partitioning and RLS directly. Isolate tenants by schema or RLS policy.

Chapter 15 · Geo Search, Facets, Autocomplete

Three standard search UI features.

**Geo search**. Elastic uses `geo_point` mapping, Meilisearch uses a `_geo` field, Typesense uses `geopoint`. All support filters like "within X km of these coordinates". Store locators in e-commerce, delivery apps, and real estate live on top.

**Faceted search**. Side filters by color, size, brand, etc. Meilisearch has `facets`, Typesense has `facet_by`, Elastic has `aggregations`. The UI pattern that Algolia created and standardized.

**Autocomplete / instant search**. Meilisearch's `instant-meilisearch` and Typesense's `typesense-instantsearch-adapter` accept Algolia's `instantsearch.js` directly. Replying within 50ms per keystroke is the standard.

On top come **synonyms** and **stop words**, configured per field. Match "TV" equals "television" equals the Korean "텔레비전" as one token; drop Korean particles like "을, 를, 이, 가" from the index.

Chapter 16 · Korean, Japanese, Chinese Tokenizers

English splits by whitespace, but Korean, Chinese, and Japanese do not.

**Korean**.

- **Mecab-ko**: MeCab-based morphological analyzer. Both Solr and Elastic support it.

- **Nori**: Elastic-built Korean analyzer. Bundled plugin since 7.x.

- **Open Korean Text (OKT)**: Twitter-based Korean analyzer, strong on Twitter abbreviations and neologisms.

Input: "빨간 운동화를 샀다"

Nori output tokens: [빨갛다(VA), 운동(NNG), 운동화(NNG), 사다(VV)]

The point is to split off particles and endings while restoring nouns and verbs to their dictionary forms.

**Japanese**.

- **Kuromoji**: standard in Solr and Lucene. Relatively light and fast.

- **Sudachi**: morphological analyzer from Works Applications. Larger vocabulary.

- **MeCab**: the oldest Japanese morphological analyzer. C++.

Input: "赤い靴を買った"

Kuromoji output: [赤い, 靴, を, 買っ, た]

**Chinese**.

- **jieba**: the most widely used Python Chinese analyzer. Elastic and Solr plugins exist.

- **ICU**: Unicode standard tokenizer that covers many languages. Lower accuracy, broader coverage.

Pick the wrong tokenizer and search quality collapses instantly. Typing "신발" in Korean and getting no match on "신발들", or "텐트치다" not splitting into "텐트 plus 치다" are real failure modes. If you do Korean search, the tokenizer is the non-negotiable first decision.

Chapter 17 · Cluster Sizing — Shards, Replicas, Tiers

Rules of thumb for big search clusters.

- **Shard size**: 30 to 50 GB. Smaller has overhead; larger makes rebalances slow.

- **Shards per node**: 1 to 3 hot shards. Too many blows the JVM heap.

- **Replica count**: 2 is the norm. 3 is for PB-class deployments.

- **JVM heap**: 50 percent of node memory, max 31 GB. Anything more breaks GC.

- **Disk**: SSD for hot, HDD/S3-ish for cold.

Elastic and OpenSearch automate hot to warm to cold to delete with ILM (Index Lifecycle Management). Policies like 30 days hot, 60 days warm, 1 year cold are common.

Chapter 18 · AI Search in 2026

The next chapter of search is AI.

**Algolia NeuralSearch** fuses BM25 and vectors with RRF to return results aligned to user intent. It moved quickly into e-commerce after its 2023 launch.

**Vespa Hybrid** is the most expressive way to run BM25, vectors, and ML rankers in a single query.

**OpenSearch Neural Search** attaches an embedding pipeline at ingest and fuses with RRF at query time. Models are brought in BYOM-style as ONNX or HuggingFace.

**Meilisearch plus Embedders** went GA in v1.13. Configure OpenAI, Cohere, or HuggingFace embedders and vector indexing happens automatically.

**Typesense Conversational Search** embeds RAG inside the search engine. User question becomes search becomes LLM synthesized response in one API.

Chapter 19 · Search Meets RAG

Search is exactly the retrieval stage of RAG.

[User Query]

[Embedder] -- query embedding

[Hybrid Search] -- BM25 + vector + RRF

[Reranker] -- Cohere Rerank, bge-reranker, etc.

[Context Builder] -- inject top K docs into LLM

[LLM] -- Claude / GPT / Llama

[Answer]

The three self-hosted engines most RAG-friendly:

- **ParadeDB**: Postgres plus pg_search plus pgvector. Metadata, full-text, and vectors all in one DB.

- **Meilisearch plus Embedders**: fastest to set up, hybrid built in.

- **Vespa**: most expressive ranking, including multi-stage models.

Elastic and OpenSearch are strong too but heavier to operate. Under 100K documents, Meilisearch or ParadeDB usually suffices for RAG.

Chapter 20 · Case Studies — Korea and Japan

**Korea**.

- **NCsoft**: ran Elasticsearch for in-game search for years. Added OpenSearch for GenAI search since 2024.

- **Coupang**: catalog search runs on Elasticsearch. Korean tokenizers are in-house.

- **Naver**: their own search engine is the main act, but Elastic is used for external search.

**Japan**.

- **Mercari**: listing catalog search runs on Elasticsearch. Heavy Kuromoji tuning.

- **LINE Yahoo**: ran Solr for years, migrating to Vespa since 2024.

- **Sansan**: business card data search on Elasticsearch plus in-house tokenizers.

Two patterns repeat. First, **at large scale everything ends up on Elastic, OpenSearch, or Vespa**. Second, **language-specific tokenizers receive the heaviest investment**. Baseline Nori or Kuromoji, then dictionary boosts, neologism handling, and domain noun additions become the difference.

Chapter 21 · Cost Matrix

Rough estimates at 1M daily searches and 50GB index.

| Option | Monthly USD | Notes |

| ----------------------- | ----------- | ------------------------------------ |

| Algolia | 500 - 1500 | Traffic-based, priciest but zero ops |

| Elastic Cloud | 300 - 800 | Depends on cluster size |

| AWS OpenSearch | 200 - 600 | r6g.large times 3 |

| Meilisearch (self) | 50 - 150 | EC2 r6g.large times 1 or 2 |

| Typesense (self) | 80 - 200 | t3.xlarge times 3 cluster |

| ParadeDB (self) | 50 - 120 | RDS db.r6g.large single instance |

| Vespa (self) | 200 - 500 | Higher op complexity |

| Manticore (self) | 50 - 100 | c6g.large times 1 |

These are rough estimates. Traffic pattern (peak vs average), indexing frequency, and backup/DR requirements can shift the figures by 2x or 3x.

Chapter 22 · Performance Comparison

Numbers reported in vendor benchmarks and independent benchmarks (2025).

- **Meilisearch**: 1M documents, p99 under 50ms (single node).

- **Typesense**: 1M documents, p99 30 to 50ms (three-node cluster).

- **Elasticsearch**: 10M documents, p99 100 to 200ms (three nodes with shard tuning).

- **OpenSearch**: similar to Elasticsearch, plus ~20ms with Neural Search.

- **Vespa**: 100M+ documents and still under p99 100ms (large clusters).

- **ParadeDB**: 1M documents, p99 50 to 100ms (single Postgres instance).

- **Manticore**: 1M documents, p99 30 to 80ms.

Performance alone is not the differentiator. The gap shows up in **tuning effort** and **scalability as index size grows**. Up to 1M docs, any engine is fast. From 100M up, the distributed track record of Elastic, OpenSearch, and Vespa pulls ahead.

Chapter 23 · Selection Guide by Use Case

| ----------------------------------- | -------------- | ---------------------- | ------------------------------------ |

Chapter 24 · Migration Patterns

Three common paths.

**Algolia to Typesense**. The smoothest thanks to API compatibility. Keep instantsearch.js and swap the adapter. Cost typically drops by 10x.

**Elastic to OpenSearch**. For teams that want the ALv2 license. Up through 7.10 the APIs match; afterwards they diverge. Moving from 7.x is easiest; 8.x to OpenSearch 2.x needs migration tooling.

**Elastic to Vespa**. When ranking models or tensor operations are the priority. The schema and query DSL are entirely different, so it is essentially a rebuild.

The most critical piece during migration is **reproducibility of the indexing pipeline**. Build a standard query set (NDCG, MRR) for evaluating search quality and measure the same query set on the new engine to migrate without regression.

Chapter 25 · Operations Best Practices

Closing with operational notes.

- **Index asynchronously**. Put Kafka, Redpanda, or SQS in front; let the search engine consume. Keeps indexing failures from spilling onto core flows.

- **Separate indexing and search nodes**. Even on small clusters, indexing and search load different resources.

- **Measure search quality**. Click-through rate, zero-result rate, and average depth measured quarterly. NDCG@10 and MRR on a domain query set.

- **Version indexes**. Blue/green indexes for zero-downtime reindexing. Switch via aliases.

- **Backups**. Both index snapshots and source data. Backing up only the index makes recovery impossible after schema changes.

- **Monitoring**. Query latency (p50/p99), indexing queue length, disk usage, JVM heap if applicable. Zero-result rate is a business KPI too.

Search engines do not move once entrenched. Picking the tokenizer, license, and distribution model carefully up front saves five years of effort.

Chapter 26 · Epilogue — Search Got Interesting Again

Search in the 2010s was "use Algolia". Search in the early 2020s was "operate an Elastic cluster". Search in 2026 is neither of those.

Small teams launch search on Meilisearch or ParadeDB within a week. Mid-sized teams run Typesense or OpenSearch clusters. Big teams stack ML rankers on Vespa or Elastic. AI/RAG teams glue embedders and rerankers onto the search engine into one pipeline.

The point is that **the option set got rich**. The era when SaaS was the only answer is over, and so is the era when OSS was the only answer. Choosing tooling based on the four variables — domain, traffic, language, and budget — is what 2026 search engineering looks like.

References

- [Meilisearch Documentation](https://www.meilisearch.com/docs)

- [Typesense Documentation](https://typesense.org/docs/)

- [Manticore Search Documentation](https://manual.manticoresearch.com/)

- [OpenSearch Documentation](https://opensearch.org/docs/latest/)

- [Elasticsearch 8.x Documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html)

- [Apache Solr Reference Guide](https://solr.apache.org/guide/solr/latest/)

- [Vespa.ai Documentation](https://docs.vespa.ai/)

- [Quickwit Documentation](https://quickwit.io/docs/)

- [Tantivy GitHub](https://github.com/quickwit-oss/tantivy)

- [ParadeDB pg_search](https://docs.paradedb.com/documentation/full-text/overview)

- [Orama Documentation](https://docs.orama.com/)

- [Algolia NeuralSearch](https://www.algolia.com/products/ai-search/)

- [Elastic License 2.0 Changes](https://www.elastic.co/pricing/faq/licensing)

- [OpenSearch Neural Search](https://opensearch.org/docs/latest/search-plugins/neural-search/)

- [Nori Korean Analyzer](https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-nori.html)

- [Kuromoji Japanese Analyzer](https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-kuromoji.html)

- [BM25 Wikipedia](https://en.wikipedia.org/wiki/Okapi_BM25)

- [HNSW Paper (Malkov 2016)](https://arxiv.org/abs/1603.09320)

- [Reciprocal Rank Fusion (Cormack 2009)](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf)

- [Vespa Ranking Documentation](https://docs.vespa.ai/en/ranking.html)

- [Open Korean Text](https://github.com/open-korean-text/open-korean-text)

- [Sudachi Japanese Tokenizer](https://github.com/WorksApplications/Sudachi)