Search benchmark

We tested Ceisium Search, Algolia, Typesense, and Meilisearch with 1,000 queries on the Next.js App Router docs opens in a new tab . The queries included searching for exact page names, long-tail questions, typos, error messages, and more.

Note: The goal was to measure the performance using the default settings of each product rather than engineering different knobs. We left optional settings unchanged after completing the required setup, which differs for each product.

Benchmark results per provider

Ceisium Search returned an expected page in the first three results for 912 of the 1,000 queries. That compares with 357 for Algolia, 361 for Typesense, and 423 for Meilisearch.

Product	Hit@3	Hit@10	MRR@10	nDCG@10
Ceisium Search	91.2%	96.6%	0.8468	0.8761
Algolia	35.7%	38.6%	0.3149	0.3326
Typesense	36.1%	40.3%	0.3220	0.3420
Meilisearch	42.3%	49.5%	0.3679	0.3988

What do these metrics mean?

Hit@3 is the share of queries with an expected page in the first three results. Hit@10 checks the first ten.

MRR@10 measures how high the primary expected page ranks: first place earns 1, second earns 0.5, and so on. Pages outside the first ten earn 0, and we average the score across all queries.

nDCG@10 also checks the order, but considers all acceptable pages. It gives more credit to pages near the top and compares the result with the best possible order.

Higher is better for all four metrics. MRR and nDCG range from 0 to 1.

The query type made a difference

The results become clearer when we break them down by query type. These are the Hit@3 scores for each category:

Query type	What the category tests	Queries	Ceisium Search	Algolia	Typesense	Meilisearch
Exact	Known page terms	280	93.6%	80.0%	72.5%	82.5%
Long-tail	More specific descriptions	280	89.6%	14.6%	18.9%	23.9%
How-to	A task the visitor wants to complete	120	93.3%	0.8%	2.5%	3.3%
Configuration	Options and settings	80	97.5%	21.3%	25.0%	28.8%
Error	A failure the visitor wants to resolve	55	89.1%	14.6%	20.0%	20.0%
Concept	An idea the visitor wants to understand	55	80.0%	16.4%	14.6%	18.2%
Variant	Alternative wording	60	88.3%	20.0%	38.3%	48.3%
Typo	Misspelled words	50	96.0%	76.0%	62.0%	78.0%
Navigation	A destination within the documentation	20	75.0%	35.0%	45.0%	45.0%

The three external engines did best on exact queries. Their lowest scores were on how-to queries, where Ceisium Search found an expected page in the top three 93.3% of the time.

This is the problem we want Ceisium Search to solve. You should be able to describe what you need, even when you do not know the page name.

LLMs are getting people used to asking full, descriptive questions. So it only makes sense that website search handles that habit too, along with short keywords.

A few examples

To give you an idea of how different queries perform, here are a few examples from the benchmark.

The rank labels show the benchmark results. The result cards and their timings come from later checks.

For Next.js useParmas hook, the expected page was useParams. Ceisium returned it first, Algolia third, Typesense fourth, and Meilisearch fifth. All four found the page despite the typo; two put it in the top three.

Results for the useParams typo, with benchmark ranks marked for all four products.

Now take a full question: How do I add typed JSON-LD to a page component?

Ceisium returned the expected JSON-LD guide first. None of the other three returned it in the top ten. The query describes a task, which is the kind of search we want Ceisium Search to support well.

Results for the typed JSON-LD question, with the expected page ranked first in Ceisium and outside the other top tens.

Ceisium placed an expected page in the top three for 93.6% of exact queries. Next.js App Router guides was one of the exceptions. Ceisium put the expected page eighth; Algolia, Typesense, and Meilisearch all put it first.

Results for the App Router guides query, with Ceisium ranked eighth and the other products ranked first.

We still want to improve cases like this. A strong overall score does not make an individual miss less frustrating.

Latency vs quality

Ceisium Search found expected pages more often, but all three other products were faster.

Product	Median latency	P95 latency
Ceisium Search	857.86 ms	1,983.09 ms
Algolia	178.91 ms	776.95 ms
Typesense	225.41 ms	759.55 ms
Meilisearch	240.58 ms	395.78 ms

The median is the middle request time. At P95, 95% of requests finished within the reported time. These times include the network round trip from one client in Bengaluru.

Ceisium’s median was about 0.86 seconds, compared with 0.18–0.24 seconds for the others. Its P95 was almost two seconds. Meilisearch had the lowest P95 at about 0.40 seconds.

That wait matters when someone is using a search box. We believe returning the right page matters more than getting irrelevant pages faster. We also plan to improve Ceisium’s latency in the coming weeks.

What this benchmark answers

All four products could return better results with tuning, but getting those settings right takes time and effort. As your content changes, settings that once worked well can become stale and search quality can fall.

That is why we care about the quality you get before manual tuning.

With Ceisium Search, we aim to keep your website search accurate without constant manual tuning.

Also, this run covers one documentation site and a query set we wrote. We did not measure cost, setup time, performance under production traffic, or the best results each product could reach after tuning.

For a broader product comparison, read Ceisium Search vs Algolia , Ceisium Search vs Typesense , and Ceisium Search vs Meilisearch .

Methodology and how to repeat it

We ran the benchmark on September 3, 2026, using 280 Next.js App Router page URLs from an August 24 snapshot.

What “default settings” means here

Each product needs some setup before it can search these pages. We completed that setup and left optional relevance settings unchanged.

Ceisium Search crawled the Next.js pages and used the search settings generated for that website. We made no manual relevance adjustments for the benchmark.

Ceisium's source was limited to the App Router docs.

The other three products each received 390 records prepared from the same 280 page URLs. The records contained titles, headings, and body text.

Algolia used a fresh index. We left searchable attributes, ranking, synonyms, rules, and AI settings unchanged after importing the records.

Algolia shows “Not configured” for searchable attributes. Its default uses all non-reserved attributes.

Typesense Cloud 30.2 used a fresh collection. Typesense requires a list of fields to search; we chose title,headings,body, in that order, before the run. That order was our setup choice.

Typesense collection fields. The search-field order is supplied separately in each query request.

Meilisearch Cloud 1.53.1 used a fresh index with default searchable attributes and ranking rules. We added no field priorities, synonyms, custom ranking, or embedding provider.

Meilisearch ran in Singapore.

Repeat the method on your own docs

This is the method we used:

1. Save a fixed set of pages and check for missing or invalid content.
2. Keep the queries and expected pages fixed before the run.
3. Complete each product’s setup and record its settings and indexed content.
4. Send 100 successful warmup searches before measurement to reduce first-request setup effects. Exclude these requests from the scores.
5. Run the same 1,000 queries in the same order, separately for each product. Send one request at a time, at no more than 60 starts per minute.
6. Ask for up to 50 results. Normalize page URLs, remove duplicates, and score the first ten unique pages.
7. Keep failed requests in the quality scores and client latency statistics. Check the settings and indexed content again after the run.

The same method can help you compare search quality and response time on your own documentation.

In our run, Ceisium Search found expected pages more often across every query category, including exact queries. It also took longer to respond. We plan to reduce that wait while improving the results we still get wrong.

For your own test, include questions from people who do not know your page titles. Check whether they find the right page, then check how long they wait.