Nick Vlku, VP of Growth at Algolia, here. Wanted to dive in a bit more on Ben's answer below. To be honest, I was surprised at this limitation too when I first starting using Algolia. Upon some research, it turns out this is really complicated and Algolia errs on doing what yields the best experience for end users (even if it might require a little bit more work).

Basically, we are trying to avoid the phenomenon when you apply a filter search (like "sort by price") and returning something that has nothing to do with your query or intent. For example, a customer searching for an "Eames chair" and then sorting by lowest price would return things like $2 postcards of Eames chairs.

So, in order to capture the right kind of intent for that sort (and also allow our customers to further customize results), we require a separate replica of the data. (Maybe if somebody sorts for cheapest Eames chair, you would bump up a similar cheaper chair by another company instead of a postcard?)

The good news is, for most of these cases, there is no additional cost. You basically can create a virtual replica which points to your same records with different ranking strategies. So no doubling up the records! See here for info on this: https://www.algolia.com/doc/guides/managing-results/refine-r...

It's a balancing act between "magical sorting just working" and "doing what looks right for the customer". We landed on this approach because we think it provides the most value and the best flexibility for everyone.

Let me know if this makes sense, or if you have any other questions! Thanks!

Have you looked at using virtual replicas (https://www.algolia.com/doc/guides/managing-results/refine-r...) at all? They don't increase the number of records as they use the same underlying data.