Understanding Replicas

Algolia has one ranking formula per index. Every index has a unique sorting strategy, which is statically defined at the index level, and can’t be changed at query time. Pre-sorting at indexing time instead of at query time leads to a considerable performance boost.

Use replica indices to provide different rankings for the same data..

Algolia provides primary/replica relationships to let you automatically replicate the content of one index (the primary) onto other indices (the replicas) and synchronize content changes.

Algolia offers two flavors of replicas, standard and virtual replicas. You can choose either one or the other depending on your needs.

What are standard replicas?

Standard replicas are linked to their primary index: a standard replica copies its primary index’s content but can have different settings. Though linked to its primary, a standard replica is a separate index. This means standard replicas increase the number of records on your application.

Data synchronization and settings in standard replicas

Standard replicas have the same data as their primary index, and Algolia handles the data synchronization for you. Every time you add, update, or delete records in your primary index, your replica is automatically modified. You can’t alter this automatic data synchronization.

For example, you can’t directly add, update, or delete records in your replica indices. Standard replicas start with the same settings as their primary index. However, you can change a replica’s settings.

The most common modifications to a replica’s settings are to its exhaustive sorting strategy.

What are virtual replicas?

Unlike standard replicas, virtual replicas don’t copy their primary index’s content. While they slightly increase the primary index’s size (less than 10 MB per millions of records), they don’t affect the number of records on your application.

Virtual replicas are optimized for the relevant sort feature.

You can create 20 virtual replicas per index. Contact Algolia’s support team to increase this limit if you want to create more virtual replicas.

Data synchronization and settings in virtual replicas

Virtual replicas can be seen as a view of their primary index, meaning that virtual replicas directly access their primary index’s records. Since a virtual replica uses the same data as its primary, every time you add, update, or delete records in your primary index, the modifications are found in your replica. You can’t alter this automatic data synchronization.

For example, you can’t directly add, update, or delete records in your replica indices.

The most common modifications to a virtual replica’s settings are to its relevant sorting strategy.

How do standard and virtual replicas compare?

If it’s not obvious how to choose between standard and virtual replicas, you can refer to the following comparison table. Use your desired sorting strategy as a rule of thumb to decide between virtual or standard replicas:

• If you need exhaustive sorting, pick standard replicas.
• If you need relevant sorting, pick virtual replicas.

Managing replicas

Creating replicas

With multiple ranking formulas you can implement different sorting strategies (for example, sort by price, ascending/descending, sort by most viewed).

You can create replicas with the dashboard, or use the replicas setting when using the API. Whichever method you choose, these actions replicate all data and settings. You then need to change the sorting strategy of the replica.

Querying replicas

When you want to search a replica index, you need to target it as you would with any primary index.

Changing a replica’s settings

A standard replica is like any other index: you can change any of its settings.

Virtual replicas support a subset of the primary’s settings. For more information on which settings you can change, refer to the guide on virtual replica settings.

For both standard and virtual replicas, you typically want to keep most settings in sync with your primary index. You can ensure setting synchronization by forwarding settings changes made to your primary index to its replicas: to achieve this, set the forwardToReplicas parameter to true.

Deleting or detaching a replica

You can’t edit the contents of a replica index. If you want to edit or delete the replica, you first have to unlink it from its primary index, which turns it into a regular index. Once unlinked, changes to the primary index no longer propagate to the replica index.

Detaching a virtual replica turns it into an empty index.

Virtual replicas supported parameters subset

Virtual replicas support a subset of the index settings. You can find the supported and unsupported parameters in the following lists.

Supported parameters

Supported parameters are editable on virtual replicas.

• advancedSyntax
• advancedSyntaxFeatures
• alternativesAsExact
• allowTyposOnNumericTokens
• aroundPrecision
• attributeCriteriaComputedByMinProximity
• attributesToHighlight
• attributesToSnippet
• attributesToRetrieve
• distinct
• enablePersonalization
• enableRules
• exactOnSingleWordQuery
• highlightPostTag
• highlightPreTag
• hitsPerPage
• ignorePlurals
• maxFacetHits
• maxValuesPerFacet
• minProximity
• minWordSizefor1Typo
• minWordSizefor2Typos
• paginationLimitedTo
• queryLanguages
• queryType
• removeStopWords
• replaceSynonymsInHighlight
• responseFields
• restrictHighlightAndSnippetArrays
• snippetEllipsisText
• sortFacetValuesBy
• typoTolerance
• unretrievableAttributes

Unsupported parameters

You can’t change the following parameters for replica indices. You must change them on the corresponding primary index or create a standard replica.

• attributeForDistinct
• attributesForFaceting
• camelCaseAttributes
• customNormalization
• decompoundedAttributes
• disableExactOnAttributes
• disablePrefixOnAttributes
• disableTypoToleranceOnAttributes
• disableTypoToleranceOnWords
• indexLanguages
• keepDiacriticsOnCharacters
• numericAttributesForFiltering
• optionalWords
• searchableAttributes
• userData