FAQ / Accounts & Billing / How does Algolia count records and operations?
Nov. 06, 2019

How does Algolia count records and operations?

How We Count Records

Let’s look at an example before explaining the record-count logic.

  • 5000 objects in main index
  • 3 replica indices
  • Total records: 5000 x 4 (1 primary index + 3 replicas) = 20,000 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 are either indexing or search operations.

Let’s first look at an example:

  • 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 the following indexing operations:

  • Record operations: Each add, update, or delete applied to an object counts as one operation. This is true even if no object is added, updated, or deleted (for example, if the objectID you’re targeting is unknown).
    • If you choose to batch indexing calls, each modified object is counted as one operation.
    • An exception is the Delete By Query operation, which can delete more than one object but only counts as one operation.
  • Rule operations: Each add, update, or delete counts as one operation.
  • Synonym operations: Each add, update, or delete counts as one operation.
  • ACL operations: Each add, update, or delete of an API key or its ACL counts as one operation.
  • Index operations: Every set settings call counts as one operation. Changing multiple settings in a single call, still counts as one operation. Settings include searchable attributes, facets, highlighting, or any setting in our full list of index settings.
    • Moving, deleting, or copying an index counts as one 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.

Note that the search, browse, and searchForFacetValues methods count as individual search 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.

Did you find this page helpful?