When architecting your solution, you should avoid patterns that require more indices as your user base or usage increases, as this may eventually risk the performance issues that come with having a large number of indices.
In order to protect the stability and performance of your search, and to prevent this potentially problematic number of indices, Algolia has a built-in limit of 1,000 total indices per application.
If you have a use case that requires more indices, there are a few different options.
------------------------------------------------------------------------
One option is to condense the indices using attributes and filters. The piece of information that is being used to logically separate your indices can instead be added as an attribute, and a filter can be sent for that attribute at query time when necessary.
For example, let's say your application manages search for many different local stores, and each of those local stores has its own products, like so:
Index name:
"Store 123"
Example product:
{
name: "Bread"
price: 3.99
}
You could instead have all products from all stores be part of the same index, but each product has a "stores" attribute that lists the stores in which it's available.
Index name:
"All Stores"
Example product:
{
name: "Bread"
price: 3.99
stores: "Store 123", "Store 234", "Store 345"
}
In this layout, each local stores' search page would sent a filter at query time, e.g. Store 123 would send a filter like "stores:Store 123" to ensure it retrieves the relevant products.
This method has the added benefit of potentially reducing the overall number of records, since multiple stores may carry the same products.
------------------------------------------------------------------------
The second option would be to simply create a new application. Once you hit 1,000 indices, future indices can be created on the second application. The only change this would require is an update of the application ID depending on which index needs to be accessed for a given store/site/query.