Manage Your Indices

Once you’ve sent your data to Algolia, it resides in indices. You can rename indices, copy them within the same or across different applications, clear them, and delete them, either from the Algolia dashboard or using an API client.

Replicating an index

By design, Algolia allows one ranking formula per index. If you want to offer different rankings for the same data, use replica indices.

Replica indices let you replicate an index’s data (the primary) into other indices (the replicas). Replicas have the same records as their primary index, and Algolia automatically synchronizes data changes for you. Every time you add, update, or delete records in your primary index, it also updates its replicas.

When you create a replica, it starts as an exact copy of its primary index: they have the same data and the same settings. While you can’t change a replica index’s data, you can change its settings. It allows you to provide different sorts for the same data, run A/B tests, experiment with new settings, etc.

Replicas for sorting

The primary use case for replicas is to create alternative sorts. Whenever you want to offer different sorting options for the same data (for example, from lowest to highest price), you need to create replicas with different ranking settings.

Algolia provides two types of sorting:

• Exhaustive or hard sorting
• Relevant sort

Your use case determines which is a better fit.

Exhaustive sorting strategy

Exhaustive sorting is a “strict” strategy because it re-orders all results based on attributes. It’s intended for use cases that require exhaustivity or where relevance isn’t key, like for an inventory app or a database. Exhaustive sorting uses standard replicas.

Relevant sorting strategy

Relevant sorting only reorders relevant results. This behavior is the preferred sorting experience for ecommerce, marketplace, and media content discovery. Relevant sorting uses virtual replicas.

Replicas for testing

Another use case for replica indices is testing. You can create a replica for pre-production testing (user acceptance, quality assurance), to experiment with different settings, or to perform A/B testing. If the parameters you’re testing use virtual replicas this will save space but if you want separate indices for separate environments, you should use standard replicas.

Managing replica indices

A replica is no different from any other kind of index, which means you can rename, copy, or delete it. When you rename or copy a replica, you detach it from its primary index. The replica becomes a primary index itself and is no longer synchronized with its former primary index.

If you want to reattach an index as a replica, you need to follow the same steps as creating a replica for the first time. In other words, you need to declare the index as a replica of the primary, either through the dashboard or API using the replicas setting.

If you delete a primary index, you need to delete its replicas manually. Otherwise, they remain on your application as primary indices: you can change their data, and create replicas from them.

Standard replicas, unlike virtual replicas, take up the same disk space as their primary index. They also add to your record count. To keep your application at a reasonable size, make sure to remove unused replicas. You shouldn’t exceed ten replicas unless necessary. The higher the number of replicas, the longer the total indexing update time.

Indices and analytics

Algolia stores analytics data on dedicated servers, separate from the indices. Algolia collects Search and Click and Conversion Analytics asynchronously, in parallel to search processing. This way, gathering analytics never impacts the speed of search.

There’s no hard link between your indices and their analytics. They’re two different sets of data stored on separate servers. Consequently, index management methods such as copying, moving, and deleting have no effect on analytics data. For example, if you delete an index, it doesn’t remove its associated analytics data.

Analytics data is referred to by the name of its index. This reference never changes.

Renaming an index

Changing the name of an index doesn’t change the name of the index’s analytics. The new name references new analytics—the old and new analytics aren’t merged. If you want to preserve an index’s analytics history, you need to keep using the old name.

Conversely, this mechanism ensures that you never lose analytics data when you atomically reindex your records.

Deleting an index

When you delete an index, it doesn’t delete the associated analytics data. It remains available under the deleted index’s name, allowing you to export it using the Analytics REST API.

Copying an index

When you copy an index, it doesn’t copy the associated analytics data. The new index starts fresh. Be careful when using the copyIndex method to overwrite an existing index, as it associates the existing analytics data of the overwritten index with the new one.