The Indexes API enables your app to create indexes for data collections, to make querying data faster.

An index is a map of a collection's data, organized according to fields that you select. An index increases the speed of queries by providing a query with a shortcut to the information it is looking for. Instead of iterating through every data item in the collection, a query can use the index to skip to potentially relevant items. The larger a collection is, the more time this saves.

With the Indexes API, your app can:

• Create regular indexes to accelerate query speed.
• Create unique indexes to enforce unique values.
• Access and drop existing indexes.

To learn about the differences between regular and unique indexes, see Index Types.

It's important to note the following points before starting to code:

• A collection can have up to 3 regular indexes (for up to 3 fields per index). It may also have 1 unique index (for 1 field).
• The value contained in an indexed field can't be larger than 982 bytes, including the collection name. For example, in a collection named "Products", the maximum length of each value in the indexed fields is 974 bytes.
• When an index creation fails, the failed index still occupies a slot. To remove the failed index and free up the slot for a new index, use the Drop Index endpoint.
• Case-insensitive filters, such as $startsWith, aren't accelerated by an index.

• Regular index: An index that increases query speed for up to 3 fields.
• Unique index: An index that increases query speed and enforces unique values for 1 field.

Every time you query a data collection, you are initiating filtering and sorting operations that take time to carry out because they iterate through every item in the collection. For a small collection, the time it takes to execute a query and receive its results might be negligible. But as the quantity of data in a collection increases, each query takes longer to process, and this can impact the performance of your app.

An index is a map of the collection's data, organized according to fields that you select. An index increases the speed of queries by providing a query with a shortcut to the information it is looking for. Instead of iterating through every data item in the collection, a query can use the index to skip to potentially relevant items. The larger a collection is, the more time this saves.

The best fields to use for indexes are those with a wide range of values. Indexes of fields with a narrow range of values, such as booleans, don't speed up queries significantly.

The Indexes API allows your app to create 2 kinds of indexes:

• A regular index accelerates queries for up to 3 fields in a collection.
• A unique index enforces unique values for 1 field in a collection and also functions as a regular index for that field.

You can create up to 3 regular indexes for each collection. A regular index can be created for up to 3 fields, with each field sorted either in ascending or descending order.

For example, consider a database containing information about many different products. Each data item contains productName, category, and price fields.

An index for the productName field in ascending order accelerates queries based on the productName field. Instead of searching through all of the data entries until one is found with the desired name, the index enables the query to jump based on alphabetical ordering.

An index for the category and price fields speeds up queries that include these fields. A general query for all products in a particular category, ordered by price, doesn't need to iterate through the entire collection to find all items in the specified category. The results of that search will already be ordered by price and thus will not need to be sorted again. For a large collection, this can save a significant amount of time.

A unique index enforces unique values for an indexed field. You can create 1 unique index for each collection, in addition to its regular indexes.

A unique index can only have 1 field. For that field, it functions like a regular index. For example, a unique index for the productName field in a product database enables faster queries based on that field.

In addition, a unique index enforces unique values for the indexed field in all data items across the collection. So if you created a unique index for the productName field, you will not be able to create more than one item with any given productName value.

Indexes accelerate filtering and sorting queries of certain types. Data queries are carried out using the Query Data Items endpoint. For details of the query language used in Wix Data queries, see API Query Language.

Indexes accelerate queries based on equality operators, such as $eq and $in. They also accelerate queries based on range operators, such as $gt, $gte, $lt, and $lte under certain circumstances. In Wix Data collections, indexes don't accelerate queries based on the case insensitive $startsWith operator.

The order of fields in an index determines when and how filter queries use the index to save time.

For example, consider a collection containing information about paintings. The collection has an index for fields called artist (in ascending order), dateCompleted (in ascending order), and title (in ascending order), respectively.

Queries that filter based on the fields in the following orders can use the index to find the resulting entries more quickly:

• artist alone.
• artist and dateCompleted.
• artist, dateCompleted, and title.

A query that filters based on the dateCompleted field or the title field first doesn't use the index and will iterate through all items in the collection.

A query based on artist and title uses the index for looking up values in the artist field, but then iterates through all of the resulting items for the query of the title field. The index thus improves the speed of this query, but only partially.

Note that queries can use an index to accelerate a range filter (such as $gt, $gte, $lt, or $lte) only if it is the last filtering action of the query. For example, in our example collection with an index for artist, dateCompleted, and title, the following queries would make full use of the index:

• A range filter for artist alone.
• An equality filter for artist and a range filter for dateCompleted.
• An equality filter for artist, an equality filter for dateCompleted, and a range filter for title.

An index also speeds up sorting operations in a query, if the following conditions are met:

• The query doesn't include filters that prevent the index from being used.
• The sorting order in the query either matches the order defined in the index or is its exact inverse.

For example, consider again a collection containing information about paintings, with an index for fields called artist (in ascending order), dateCompleted (in ascending order), and title (in ascending order), respectively.

A query that has no filters and sorts by artist, dateCompleted, and title uses the index if the query sorts all the fields in ascending order (corresponding to the index) or if sorts all fields in descending order (inversely corresponding to the index).

A query that contains an equality filter for artist and subsequently sorts by dateCompleted and title (in the appropriate order) also uses the index.

However, a query that contains a range filter for artist and subsequently sorts by dateCompleted and title doesn't use the index.

Consider again a collection with information about paintings. Each data item contains an artist field, a dateCompleted field, and a title field.

What indexes might be useful for this collection? The answer depends on which queries are likely to be carried out most often.

Suppose that users are most likely to carry out the following types of queries:

1. Show all paintings by a particular artist.
2. Show all paintings by all artists, ordered only by their date of completion.

Defining an index for artist (ascending order) and dateCompleted (ascending order) accelerates queries of the first kind. A query for all works by Michaelangelo, for example, uses the index and returns results more quickly than if there was no index. The same index would also accelerate a more complex query which filters by artist and sorts the results by dateCompleted.

However, a query of the second kind isn't accelerated by this index, since the index first orders by artist. To speed up a query for all paintings ordered only by dateCompleted, we can create a second index with dateCompleted as its first (or only) field.