On this page
By design, Algolia provides 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.
When you want to provide different rankings for the same data, you need to use replica indices.
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 exact 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 exact 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 records), they don’t affect the number of records on your application.
Virtual replicas are optimized for the Relevant sort feature.
You can create 10 virtual replicas per index. If you need to create more, you can contact support to increase this limit.
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 for you to choose between standard and virtual replicas, you can refer to the comparison table below.
One rule of thumb to decide between virtual or standard replicas is your desired sorting strategy. If you need an exhaustive sort, you should pick standard replicas. If you need to use Relevant sort you should pick virtual replicas.
|Standard Replicas||Virtual Replicas|
|Usage||Optimized for exhaustive sorting strategy||Optimized for the Relevant sorting feature|
|Data||Automatically synchronized as a copy of the primary||Automatically synchronized, as they use the same data as their primary|
|Impact on number of records||Increase the number of records||Don't increase the number of records|
|Supported settings||Support all index settings||Support a subset of index settings|
|Rules||Support different Rules||Support different Rules|
|Synonyms||Support different Synonyms||Support different Synonyms, except placeholders.|
Multiple ranking formulas are useful to implement different sorting strategies (for example, sort by price, ascending, or descending, sort by most viewed, etc.)
You can create replicas with the dashboard, or you can 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.
When you want to search a replica index, you need to target the replica index as you would with any primary index.
Changing a replica’s settings
Regarding settings, a standard replica is like any other index: you can change any of its settings.
Virtual replicas supports a subset of the primary’s settings.
For more information on which settings you can change in virtual replicas, refer to the guide on virtual replicas supported 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
forwardToReplica parameter to true when using the
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.
Please note that detaching a virtual replicas turns it into an empty index.
Virtual replicas supported parameters subset
Because virtual replicas can be seen as a view of the primary’s index, they support a subset of the available index settings. You can find the supported and unsupported parameters in the list below.
Supported parameters are editable on virtual replicas.
Unsupported parameters are reusing the value of the primary index. They can not be changed on a virtual replica. In the case you want to change them, you must change them on the primary index or create a standard replica.