Use the best practices listed here as a quick reference when building an application that uses Firestore.
When you create your database instance, select the database location closest to your users and compute resources. Far-reaching network hops are more error-prone and increase query latency.
To maximize the availability and durability of your application, select a multi-region location and place critical compute resources in at least two regions.
- Avoid the document IDs
- Avoid using
/forward slashes in document IDs.
Do not use monotonically increasing document IDs such as:
Product 3, ...
Such sequential IDs can lead to hotspots that impact latency.
Avoid the following characters in field names because they require extra escaping:
Avoid using too many indexes. An excessive number of indexes can increase write latency and increases storage costs for index entries.
Be aware that indexing fields with monotonically increasing values, such as timestamps, can lead to hotspots which impact latency for applications with high read and write rates.
For most apps, you can rely on automatic indexing as well as any error message links to manage your indexes. However, you may want to add single-field exemptions in the following cases:
|Large string fields||
If you have a string field that often holds long string values that you don't use for querying, you can cut storage costs by exempting the field from indexing.
|High write rates to a collection containing documents with sequential values||
If you index a field that increases or decreases sequentially between documents in a collection, like a timestamp, then the maximum write rate to the collection is 500 writes per second. If you don't query based on the field with sequential values, you can exempt the field from indexing to bypass this limit.
In an IoT use case with a high write rate, for example, a collection containing documents with a timestamp field might approach the 500 writes per second limit.
|Large array or map fields||
Large array or map fields can approach the limit of 40,000 index entries per document. If you are not querying based on a large array or map field, you should exempt it from indexing.
Read and write operations
Avoid writing to a document more than once per second. For more information, see Updates to a single document.
Use asynchronous calls where available instead of synchronous calls. Asynchronous calls minimize latency impact. For example, consider an application that needs the result of a document lookup and the results of a query before rendering a response. If the lookup and the query do not have a data dependency, there is no need to synchronously wait until the lookup completes before initiating the query.
Do not use offsets. Instead, use cursors. Using an offset only avoids returning the skipped documents to your application, but these documents are still retrieved internally. The skipped documents affect the latency of the query, and your application is billed for the read operations required to retrieve them.
The Firestore SDKs and client libraries automatically retry failed transactions to deal with transient errors. If your application accesses Firestore through the REST or RPC APIs directly instead of through an SDK, your application should implement transaction retries to increase reliability.
For the best snapshot listener performance, keep your documents small and control the read rate of your clients. The following recommendations provide guidelines for maximizing performance. Exceeding these recommendations can result in increased notification latency.
|Reduce snapshot listener churn rate||
Avoid frequently churning listeners, especially when your database is under significant write load
Ideally, your application should set up all the required snapshot listeners soon after opening a connection to Firestore. After setting up your initial snapshot listeners, you should avoid quickly adding or removing snapshot listeners in the same connection.
To ensure data consistency, Firestore needs to prime each new snapshot listener from its source data and then catch up to new changes. Depending on your database's write rate, this can be an expensive operation.
Your snapshot listeners can experience increased latency if you frequently add or remove snapshot listeners to references. In general, a constantly-attached listener performs better than attaching and detaching a listener at that location for the same amount of data. For best performance, snapshot listeners should have a lifetime of 30 seconds or longer. If you encounter listener performance issues in your app, try tracking your app's listens and unlistens to determine if they may be happening too frequently.
|Limit snapshot listeners per client||
Keep the number of snapshot listeners per client under 100.
|Limit the collection write rate||
Keep the rate of write operations for an individual collection under 1,000 operations/second.
|Limit the individual client push rate||
Keep the rate of documents the database pushes to an individual client under 1 document/second.
|Limit the global client push rate||
Keep the rate of documents the database pushes to all clients under 1,000,000 documents/second.
This is a soft limit. Firestore does not stop you from surpassing this threshold but it greatly affects performance.
|Limit the individual document payload||
Keep the maximum document size downloaded by an individual client under 10 KiB/second.
|Limit the global document payload||
Keep the maximum document size downloaded across all clients under 1 GiB/second.
|Limit the number of fields per document||
Your documents should have fewer than 100 fields.
|Understand the Firestore standard limits||
Keep in mind the standard limits for Firestore.
Pay special attention to the 1 write per second limit for documents and the limit of 1,000,000 concurrent connections per database. These are soft limits that Firestore does not stop you from exceeding. However, going over these limits might affect performance, depending on your total read and write rates.
Designing for scale
The following best practices describe how to avoid situations that create contention issues.
Updates to a single document
You should not update a single document more than once per second. If you update a document too quickly, then your application will experience contention, including higher latency, timeouts, and other errors.
High read, write, and delete rates to a narrow document range
Avoid high read or write rates to lexicographically close documents, or your application will experience contention errors. This issue is known as hotspotting, and your application can experience hotspotting if it does any of the following:
Creates new documents at a very high rate and allocates its own monotonically increasing IDs.
Firestore allocates document IDs using a scatter algorithm. You should not encounter hotspotting on writes if you create new documents using automatic document IDs.
Creates new documents at a high rate in a collection with few documents.
Creates new documents with a monotonically increasing field, like a timestamp, at a very high rate.
Deletes documents in a collection at a high rate.
Writes to the database at a very high rate without gradually increasing traffic.
Ramping up traffic
You should gradually ramp up traffic to new collections or lexicographically close documents to give Firestore sufficient time to prepare documents for increased traffic. We recommend starting with a maximum of 500 operations per second to a new collection and then increasing traffic by 50% every 5 minutes. For instance, you can use this ramp up schedule to grow your read traffic to 740K operations per second after 90 minutes. You can similarly ramp up your write traffic, but keep in mind the Firestore Standard Limits. Be sure that operations are distributed relatively evenly throughout the key range. This is called the "500/50/5" rule.
Migrating traffic to a new collection
Gradual ramp up is particularly important if you migrate app traffic from one collection to another. A simple way to handle this migration is to read from the old collection, and if the document does not exist, then read from the new collection. However, this could cause a sudden increase of traffic to lexicographically close documents in the new collection. Firestore may be unable to efficiently prepare the new collection for increased traffic, especially when it contains few documents.
A similar problem can occur if you change the document IDs of many documents within the same collection.
The best strategy for migrating traffic to a new collection depends on your data model. Below is an example strategy known as parallel reads. You will need to determine whether or not this strategy is effective for your data, and an important consideration will be the cost impact of parallel operations during the migration.
To implement parallel reads as you migrate traffic to a new collection, read from the old collection first. If the document is missing, then read from the new collection. A high rate of reads of non-existent documents can lead to hotspotting, so be sure to gradually increase load to the new collection. A better strategy is to copy the old document to the new collection then delete the old document. Ramp up parallel reads gradually to ensure that Firestore can handle traffic to the new collection.
A possible strategy for gradually ramping up reads or writes to a new collection is to use a deterministic hash of the user ID to select a random percentage of users attempting to write new documents. Be sure that the result of the user ID hash is not skewed either by your function or by user behavior.
Meanwhile, run a batch job that copies all your data from the old documents to the new collection. Your batch job should avoid writes to sequential document IDs in order to prevent hotspots. When the batch job finishes, you can read only from the new collection.
A refinement of this strategy is to migrate small batches of users at a time. Add a field to the user document which tracks migration status of that user. Select a batch of users to migrate based on a hash of the user ID. Use a batch job to migrate documents for that batch of users, and use parallel reads for users in the middle of migration.
Note that you cannot easily roll back unless you do dual writes of both the old and new entities during the migration phase. This would increase Firestore costs incurred.