This article highlights some limitations we faced using Algolia in a large-scale production app.
It's not to say that Algolia is a bad product. Rather, to highlight some limitations you may face should you choose Algolia for your enterprise.
It's also worth mentioning that Algolia is growing fast and by the time you read this, they may have changed things on their end rendering some of this information obsolete.
I encourage you to do your own research, and I'd appreciate if you call out anything mentioned here that is no longer true so I can update it.
Without further ado, let's jump in.
Algolia requires you to have a separate physical (or virtual) replica index for each sort in your app.
If your app needs to support 4 different sorts, then you'll need a primary and 3 replica indexes to handle each.
Unlike ElasticSearch, there is no concept of sort-on-read in Algolia.
You'll need to consider which sorts you need and apply them at index time.
You cannot page through your catalog of items exhaustively.
There is a hard limit of results Algolia lets you page through via the
If you set this param too high, you may pay a performance penalty.
If your app attempts to page beyond the limit you set, Algolia will send a 4xx error and stop sending back results.
Algolia is a black-box.
If you're using an open-source tool like ElasticSearch, you have the option to look at the source code, even fork it, to meet your business requirements.
Not in Algolia. With Algolia, what you see is what you get.
You should understand the capabilities of Algolia and make sure it meets your requirements as your business grows.
Algolia says in their documentation:
The Algolia engine does not support filtering on null value or missing attributes.
I'll defer to their documentation on this one since they explain this limitation and how to work around it.
If you thought you were going check for
null in your query,
you'll need to rethink how you design your index.
In Algolia, you cannot combine numeric filters and tag filters when using an
Here's an arbitrary example of a query that is illegal in Algolia:
foo > 10 OR tag:bar
You can't do this query because
foo > 10 is a numeric filter,
tag:bar is a tag filter, and they are joined by
For "performance reasons", Algolia does not let you construct a filter like the following:
A OR (B AND C)
As the complexity of your business rules increases, you might run into a situation where you need to make such a filter.
There are more limitations than the ones listed here. For more information, check out Algolia's documentation on how to use filters.
If in doubt, you can verify your filter with Algolia's filter syntax validator.
Algolia lets you execute multiple queries for the price of one request.
There's a catch: the queries you send will be executed in series, not in parallel.
The reasoning is opaque and not explained in their documentation.
This can cause performance implications depending on the query access patterns in your app.
In this article, we looked at some limitations we ran into working with Algolia.
Again, I'm not saying Algolia is a bad product. There are a lot of things I like about Algolia compared to the alternatives.
I'd still reach for Algolia for projects where I wanted to get up and running with search quickly. I do think Algolia has a good developer experience.
For larger, enterprise software, where business requirements are constantly changing, I'd probably reach for ElasticSearch over Algolia.
I do find ElasticSearch's API harder to wrap my head around compared to Algolia's; but I think ElasticSearch's has a richer feature-set when it comes to querying.