Firestore pricing

The following table lists pricing for reads, writes, deletes, and storage for each Firestore location:

No free quota for named databases

To create a named (non-default) database, you must enable billing.

There's no additional cost to you for creating or deleting the named databases, but those databases do not qualify for the free quota. Instead, you will be charged on usage incurred on those named databases.

Reads, writes, and deletes

You are charged for documents and index entries read to satisfy a query. You are charged for each document write and delete that you perform.

Charges for writes and deletes are straightforward. For writes, each set or update operation counts as a single write.

Charges for read operations have some nuances that you should keep in mind. The following sections explain these nuances in detail.

Index entry reads

You are charged one read operation for each batch of up to 1000 index entries read by a query except in the following:

Note: You can use Firestore Query Explain to confirm if a query charges index entries read.

• For K-nearest neighbor vector search queries, you are charged one read operation for each batch of up to 100 kNN vector index entries read by the query.

For example, if the following vector search query with limit: 5 returns 5 documents and reads 1550 kNN vector index entries, you are billed 5 read operations for the documents returned and 16 read operations for the index entries:

• Queries that have up to one range field are not charged for index entries read.

For example, the following query contains one equality field (age) and one range field (start_date) and is not charged for index entries read:

• Queries that have up to one range field are not charged for index entries read.

For example, the following query contains one equality field (age) and one range field (start_date) and is not charged for index entries read:

The following query contains two range fields (age and start_date) and is charged for index entries reads:

A field that appears in the order by clause is considered a range field when there is at least one other range field in the query. Therefore the following query contains two range fields (age and start_date) and is charged for index entries reads:

The __name__ field is always considered a range field, even if it is only used in an equality filter. Therefore the following query contains two range fields (age and __name__) and is charged for index entries reads:

Aggregation queries

For aggregation queries such as count(), sum(), and avg(), you are charged for index entries read by the query as described above. For aggregation queries that read 0 index entries, there is a minimum charge of one document read.

For example, count() operations that read between 0 and 1000 index entries are billed for one document read. For a count() operation that reads 1500 index entries, you are billed 2 document reads.

To learn more about the indexes used and the index entries read, use Query Explain.

Listening to query results

Firestore allows you to listen to the results of a query and get realtime updates when the query results change.

When you listen to the results of a query, you are charged for a read each time a document in the result set is added or updated. You are also charged for a read when a document is removed from the result set because the document has changed. (In contrast, when a document is deleted, you are not charged for a read.)

Billing of listeners in the mobile and web SDKS also depends on whether offline persistence is enabled or not:

• If offline persistence is enabled and the listener is disconnected for more than 30 minutes (for example, if the user goes offline), you will be charged for documents and index entries read as if you had issued a brand-new query.
• If offline persistence is disabled, you will be charged for documents and index entries read as if you had issued a brand-new query whenever the listener disconnects and reconnects.

Note: Queries with up to one range field are exempted from charging for index entries read. See here for details.

Managing large result sets

Firestore has several features to help you manage queries that return a large number of results:

• Cursors, which allow you to resume a long-running query.
• Page tokens, which help you paginate the query results.
• Limits, which specify how many results to retrieve.
• Offsets, which allow you to skip a fixed number of documents.

There are no additional costs for using cursors, page tokens, and limits. In fact, these features can help you save money by reading only the documents that you actually need.

However, when you send a query that includes an offset, you are charged a read for each skipped document. For example, if your query uses an offset of 10, and the query returns 1 document, you are charged for 11 reads. Because of this additional cost, you should use cursors instead of offsets whenever possible.

Queries other than document reads

For queries other than document reads, such as a request for a list of collection IDs, you are billed for one document read. If fetching the complete set of results requires more than one request (for example, if you are using pagination), you are billed once per request.

Minimum charge for queries

There is a minimum charge of one document read for each query that you perform, even if the query returns no results.

Firestore Security Rules

For mobile and web client libraries, if your Firestore Security Rules use exists(), get(), or getAfter() to read one or more documents from your database, you are charged for additional reads as follows:

• You are charged for reads that are necessary to evaluate your Firestore Security Rules.
• For example, if your rules refer to three documents, but Firestore only has to read two of those documents to evaluate your rules, you will be charged for two additional reads for the dependent documents.
• You are only charged one read per dependent document even if your rules refer to that document more than once.
• You are charged for rule evaluation only once per request.
• As a result, it can cost less to read multiple documents than to read documents one at a time, because reading multiple documents requires fewer requests.
• When you listen to the results of a query, you are charged for rule evaluation in all of the following cases:
• When you issue the query.
• Each time the query results are updated.
• Any time the user's device goes offline, then comes back online.
• Any time you update your rules.
• Any time you update the dependent documents in your rules.

Database storage size

You are charged for the amount of data that you store in Firestore, including storage overhead. The amount of overhead includes metadata, automatic indexes, and composite indexes.

Each document stored in Firestore requires the following metadata:

• The document ID, including the collection ID and the document name.
• The name and value of each field. Because Firestore is schemaless, the name of each field in a document must be stored with the field value.
• Any single-field and composite indexes that refer to the document. Each index entry contains the collection ID; any number of field values, depending on the index definition; and the document name.

Storage costs are in GiB/month and calculated daily. Firestore measures the database size daily. Over the period of a month, these sample points are averaged to calculate the database storage size. This average value is multiplied by the unit price of storage (GiB-month)

Learn how Firestore storage is calculated at Storage Size Calculations.

PITR data

If you enable PITR, you are charged for the storage of PITR data. Most customers will find that the overall cost of PiTR data storage is similar to the storage cost of the database.

Note: PITR data is billed separately from the database storage size billing. PITR data doesn't affect your data storage size costs.

Storage costs for PITR are in GiB/month and calculated daily. Firestore measures the database size daily. Over the period of a month, these sample points are averaged to calculate the database storage size. This average value is multiplied by the unit price of PITR (GiB-month).

For example, if the average size of your database during a month is 1 GiB and PITR is enabled for the whole month, then the billable PITR data size is 1 GiB as well.

Minimum billing: You may be charged up to 1 day of PITR storage cost even if you disable PITR within a day after enablement.

Backup data and restore operations

If you enable backups, you are charged for the storage of your database backups. The storage size for a backup is equal to the storage size of the database when the backup was taken.

Storage costs for backups are in GiB/month. Over the period of a month, the number of days for which each backup is retained, averaged over the month is also calculated. The cost of each backup is calculated using the storage size of the backup multiplied by the proportion of the month the backup is retained, multiplied by the unit price. Day boundaries are defined by the America/Los_Angeles time zone for billing purposes.

When you perform a restore operation, Firestore measures the size of the backup for the restore operation. The size of the backup is multiplied by the unit price of restore operations (GiB).

Query Explain

Use of Firestore Query Explain incurs costs.

When a query is explained with the default option, no index read operations are performed. Regardless of query complexity, one read operation is charged.

When a query is explained with the analyze option, index and read operations are performed, so you are charged for the query as usual. There is no additional charge for the explain and analyze activity, only the usual charge for the query being executed.

Network bandwidth

You are charged for the network bandwidth used by your Firestore requests, as shown in the following sections. The network bandwidth cost of a Firestore request depends on the request’s response size, the location of your Firestore database, and the destination of the response.

Firestore calculates response size based on a serialized message format. Protocol overhead, such as SSL overhead, does not count towards network bandwidth usage. Requests denied by your Firestore Security Rules do not count towards network bandwidth usage.

To learn how much network bandwidth you have used, you can use the Google Cloud console to export your billing data to a file.

General network pricing

For requests that originate within Google Cloud Platform (for example, from an application running on Google Compute Engine), you are charged as follows:

Internet data transfer rates

You will be charged for internet data transfer for the following:

• Google Cloud requests between regions, not including traffic between US regions
• Requests from outside of Google Cloud (for example, from a user's mobile device)

Network Outbound data transfer: Worldwide Destinations (excluding China & Australia, but including Hong Kong) (per GiB)