Why I Regret Switching from Elasticsearch to Algolia

Algolia is a strong search engine, but it is not a free-form database. That matters once your product starts asking for search behavior that feels natural to users but awkward to model in an index.

This article focuses on the limits that most often show up in real applications.

What To Plan For

1. Sorting Is Mostly An Index-Time Decision

Algolia does not behave like a database where you can sort on arbitrary fields at query time. If your app needs multiple sorts, you usually model them as separate indices or replicas.

Practical implication:

• decide which sort orders actually matter before launch
• keep the number of replicas small and intentional
• avoid inventing a sort for every edge case in the UI

A good rule of thumb is to ask:

• What is the primary sort?
• What is the fallback sort?
• Which sorts are only needed for admin or internal workflows?

If the answer is “almost none,” do not create a replica for it.

2. Pagination Has A Ceiling

Algolia is not designed for exhaustive paging through a giant catalog one page at a time. The paginationLimitedTo setting caps how far you can page through a query.

That is a feature, not a bug. Deep pagination is expensive, and most search experiences do not need it.

Use cases that often need a different design:

• data exports
• moderation tools
• analytics backfills
• “show me every result” views

For those workflows, consider a separate job or API that reads from your source of truth rather than from the search index.

3. The Index Is A Constraint, Not Just Storage

Algolia is not an open-source search engine you can patch yourself. That means your index design needs to respect the platform’s model:

• nested data may need to be flattened
• nullable fields often need normalization
• expensive query patterns should be avoided up front

If your product depends on a query shape that Algolia does not support well, the right answer may be to change the model instead of fighting the engine.

4. Null And Missing Values Need A Strategy

Algolia does not treat nulls like a relational database does. If a filter depends on a field being missing or null, you should plan how that field is represented before indexing.

Common strategies:

• normalize missing booleans to false
• store a sentinel value such as unknown
• keep a separate boolean like has_price
• index only records that should participate in the filter

If you find yourself asking “can I just filter on null?”, pause and redesign the data shape first.

5. The Filter Language Is Deliberately Narrow

Algolia filter syntax supports useful combinations, but not every logical expression you can imagine. Once the business rules get complicated, you can hit limitations around:

• mixing numeric filters and tag filters inside certain OR expressions
• deeply nested boolean logic
• rules that look simple in English but expand into unsupported query trees

When that happens, there are only a few real options:

• simplify the rule
• precompute more data at index time
• split the query into multiple requests
• move the logic into your application layer

Do not assume there is a clever filter expression hiding somewhere. Check the syntax validator early.

6. Multi-Queries Are Not Free Parallelism

Algolia supports sending multiple queries together, which is convenient. That does not mean the engine always executes them like independent parallel reads.

If you are using multi-queries for a page that must feel instant, treat it as a latency budget problem:

• measure the whole request
• keep the query count small
• avoid piling on “nice to have” requests
• cache where you can

The right optimization is often fewer queries, not more clever query composition.

A Better Way To Decide

The question is not “is Algolia limited?” Every search engine is. The useful question is:

• does this limitation affect a core user flow?
• can I model around it at index time?
• is the workaround simpler than the product feature it enables?

If the answer is yes to the first question and no to the others, you probably need a different design.

Quick Checklist

Before committing to Algolia for a new feature, check these items:

• the main sort order is known
• pagination limits are acceptable
• nullable fields are normalized
• filters are expressible in Algolia syntax
• multi-query latency fits the UX
• there is a fallback plan if a query becomes too complex

Bottom Line

Algolia works best when you embrace its model instead of trying to turn it into a general-purpose query engine. If you do that, you get a fast, pleasant search system. If you do not, the limits show up quickly and usually in the worst possible place: the user-facing query path.