How does Algolia count records and operations?

How We Count Records

The number of records is equal to the sum of records that you have in all of your indices (including replica indices).

Your plan may allow you to store only a certain number of records at any given time. You can update, delete, or add as many records as you want as long as the total number of indexed records does not exceed the base number of records included in your plan. If you go over this base inclusion, you’ll be charged an over-quota based on the maximum number of records you’ve reached. Depending on your plan, there may be an opportunity to pre-purchase additional records at the beginning of your contract period at a discounted price.

To offer some flexibility, Algolia ignores the 3 days with the most records in each month before calculating the total number of records.

How We Count Operations

We charge for all “operations” which consists of “Indexing Operations” and “Search Operations”.

Let’s look at an example before explaining the counting logic.

• Counting records:
  • 5,000 objects in main index
  • 3 replica indices
  • Total records: 20,000 (1 primary index + 3 replicas)
• Counting operations:
  • 40,000 object updates per month
  • 20,000 search operations per day = 600,000 per month (for a 30-day month)
  • Total operations per month: 640,000 (index operations + search operations)

Under the terms of your plan, you may be billed based on the total number of indexing operations performed every month. If you hit the limit of your plan, we’ll charge you a fee for the extra operations you’ve performed, based on the over-quota pricing of your current plan. You may be able to pay a lower rate by pre-purchasing additional operations and records: contact your Account Executive to learn more.

Counting indexing operations

We count only those operations that change an index, which include update, add, and delete objects, as well as changing index settings. All other indexing operations are not counted.

We count only a select group of indexing operations, as follows:

• Each add, update, or delete of an object or part of an object counts as 1 indexing operation. This is true even if no object is added, updated, or deleted, which can happen, for example, when the objectID is unknown.
• Same for Query rules and Synonyms: each add, update, or delete counts as 1 indexing operation.
• If you choose to batch your indexing calls, each modified object will be counted as a single operation.
• Changing an index’s settings is different. Every set setting call is counted as 1 operation. So, whether you change 1, 10 or 100 settings in 1 call, it will only count as 1 operation. Settings include searchable attributes, facets, highlighting, etc. See full list here.
• Moving, deleting, or copying an index counts as 1 operation.
• There are also some exceptional cases. For example, the Delete By Query operation, which can delete more than one object, only counts as 1 operation.

Counting reindexing operations

Let’s say you you want to “reindex” (recreate an entire index) of 10K records. Customers do this to update all records instead of only some of them. When reindexing, the process counts operations as follows: create a temporary index, index 10K records, move temporary index to production index (this is what we call an atomic reindex). In this case, we will charge you for 10001 operations: 10K + 1: 10K for the writes to the temporary index + 1 operation for the move.

Counting search operations

A search operation is counted when a search is performed. In autocomplete and search-as-you-type implementations, a search is performed on every keystroke. In case your search engine is querying N indices at each keystroke (a product index, a brand index, a categories index, etc.) then one keystroke will correspond to N operations.

In InstantSearch implementations, all duplicate searches are being cached to limit the amount of searching operations. Some InstantSearch widgets (like the refinementList) need two search operations to function properly: one to get the count for the refinements, and one to perform the actual search. Any refinement - like grouping, sorting and filtering - triggers a new search operation if the search hasn’t been cached yet.

On the Starter and Pro plans, if fewer operations are performed than included in your plan or purchased with overage, the unused operations do not roll over to the following service period.

Maximum QPS

Your plan may also have a limit on the maximum allowable QPS (the allowed number of queries performed per second). Find out how we calculate the max QPS. You can monitor how your max QPS graph is evolving over time under the Performance tab in your dashboard, or retrieve the information via the Usage API.

Counting operations on replica indices

Replicas are an exception: some operations on replica indices are not charged.

• When you send data to a primary index, or update existing data, these changes are automatically forwarded to your replica indices. However, the changes on the replica indices do not add anything to your count.
• When you forward settings on your primary index to your replicas, using the forwardToReplicas setting, this will not add any additional operations.
• However, adding settings directly onto your replicas (i.e settings that differ from your primary index’s settings), this will count as 1 operation.
• Adding synonyms and rules to your replicas will also count as additional operations.