Algolia Replica Indices: Multiple Sort Orders Without Multiple Data Pipelines

You ship an e-commerce search. The default results are tuned for relevance, and then product asks for "sort by price: low to high," "newest first," and "best sellers." Your first instinct might be to sort client-side or maintain three separate indices with three separate sync jobs. Algolia's answer is replica indices: copies of one index that share your data pipeline but override ranking, so each sort order is just a different index name at query time.

The reason replicas exist at all is a hard constraint: a single Algolia index has exactly one ranking formula. Relevance is computed by an ordered list of criteria (typo tolerance, word position, custom ranking attributes, and so on), and you can't reorder that list per query. If "price ascending" needs to beat textual relevance, it has to live in a separate index with a different formula. Replicas are how you do that without duplicating your indexing code.

What a replica actually is

A standard replica is a full copy of its primary index. When you add, update, or delete records in the primary, Algolia propagates those changes to every replica automatically. You manage one data pipeline; the replicas just follow along.

What differs is settings. A replica inherits the primary's settings by default, but you can override them — most commonly the ranking array, which defines the order of ranking criteria. To sort by price, you promote a numeric attribute to the front of that list so it dominates the relevance computation.

Newer Algolia plans also offer virtual replicas: same alternate sorting behavior, but without storing a second copy of your records. Availability depends on your plan and API client version, so check the current docs before designing around them — the cost section below explains why this matters.

Worked example: relevance plus three sort orders

Say your primary index is products, ranked by textual relevance with customRanking set to desc(popularity) as a tiebreaker. You want three additional sorts: price ascending, price descending, and newest first.

First, declare the replicas on the primary index. Run this wherever you manage index settings — a backend script or CI job using an Algolia API client, with an API key that has editSettings permission (typically your Admin API key; never expose it client-side):

// Node.js, server-side only
await client.setSettings({
  indexName: 'products',
  indexSettings: {
    replicas: [
      'products_price_asc',
      'products_price_desc',
      'products_newest'
    ]
  }
});

Then override ranking on each replica. For the price-ascending replica:

await client.setSettings({
  indexName: 'products_price_asc',
  indexSettings: {
    ranking: [
      'asc(price)',
      'typo',
      'geo',
      'words',
      'filters',
      'proximity',
      'attribute',
      'exact',
      'custom'
    ]
  }
});

The key move: asc(price) sits first, so price order wins over every textual criterion. For products_newest you'd use desc(created_at_timestamp) instead — store the date as a Unix timestamp, since ranking needs a numeric attribute.

At query time, nothing special happens. Your frontend picks the index name based on the selected sort control:

const indexBySort = {
  relevance: 'products',
  price_asc: 'products_price_asc',
  price_desc: 'products_price_desc',
  newest: 'products_newest'
};
// search with indexBySort[selectedSort]

To verify it works: index a handful of products with distinct prices and similar titles, query products_price_asc with a matching term, and confirm results come back in strict price order. Then query the primary with the same term and confirm the order differs — that difference is the replica doing its job.

The trade-offs you sign up for

Relevance takes a back seat. When price leads the ranking formula, a cheap but barely-relevant product can outrank a perfect textual match. Users sorting by price usually accept this, but it's worth knowing you're making a deliberate sacrifice, not getting a free sort.

Cost multiplies with standard replicas. Each standard replica stores a full copy of your records, and on plans billed by record count, three replicas of a 100k-record index means roughly 400k records counted. The number of sort options you offer directly multiplies indexing cost. Virtual replicas exist precisely to address this, but plan availability varies — the practical check is your Algolia dashboard's usage page: create one replica, wait for it to build, and see whether your record count doubled.

Settings drift is a real hazard. Replicas inherit the primary's settings, but once you override a setting on a replica, later changes to the primary won't necessarily flow through the way you expect. Keep replica configuration in code (as above) rather than clicking around the dashboard, so a redeploy reproduces the exact state.

When to reach for something else

If you only need to filter (category, brand, in-stock), you don't need replicas — attributesForFaceting on one index covers that. Replicas are specifically for changing order. And if your sort attribute changes constantly (say, live inventory counts), remember every record update propagates to every replica, so write volume also multiplies; a frequently-updated sort key can make replicas expensive in operations, not just storage.

The actionable takeaway: start with one primary index, add replicas only for sorts users actually select, define all of it in versioned code, and check your plan's record accounting — or virtual replica availability — before offering a dozen sort options. Sort order is a product feature, but on Algolia it's also a billing line item.