Firestore Multiple Databases is now generally available

Today, we are announcing the general availability of Firestore Multiple Databases, which lets you manage multiple Firestore databases within a single Google Cloud project, enhancing data separation, security, resource management, and cost tracking. With this milestone, multiple databases are now fully supported in the Google Cloud console, Terraform resources, and all of Firestore’s SDKs.

Each Firestore database operates with independent isolation, ensuring robust data separation and performance. For example, hotspotting traffic loads on one database will not negatively impact the performance of other databases within the project.

Getting started with creating a Firestore database

Here's how to create a new Firestore database with a few clicks in the console:

1. Navigate to the Firestore service.
2. Click the "CREATE DATABASE" button.
3. Choose a database id, which serves as the identifier for your database.
4. Select the desired database configuration settings (Database Mode, Location, Security Rules configuration, etc.).

Note: Database ID and location cannot be changed after creation, so choose carefully!

Want even more control over your Firestore database creation and management? You can use gcloud, Firebase CLI and Terraform to create and manage the Firestore database. For a detailed guide on these options, visit the "Create a database" section in the Firestore documentation.

Configure security on databases

Firestore lets you apply granular security configurations on an individual database through IAM conditions. This functionality allows distinct security policies to be applied to different databases, enabling precise, granular control. For instance, you can grant specific user groups access solely to designated databases, ensuring robust security and data isolation.

To set conditions on a specific database, within the conditions editor tool:

• Choose "firestore.googleapis.com" as the resource.type
• Specify the database resource name as the resource.name, adhering to the format "projects/<project-id>/databases/<database-id>".

Things you should know when configuring security policy:

• When a condition is not specified, any IAM principals granted permission will inherently gain access to all Firestore databases residing within the project.
• Firestore integrates with tags. The integration lets you grant or deny access to a designated group of databases, through a tag association. Visit the Tags and Conditional Access documentation for more information.
• Firestore extends similar functionality to Firebase Security Rules, allowing for granular control over database access within your Firebase project. To delve deeper into Granular Firebase Security Rules for Firestore, visit the "Set up Firestore Security Rules" section for comprehensive instructions.

View database usage and cost with billing breakdown

Firestore offers granular billing and usage breakdowns, per database. To access this cost data, you can use BigQuery. As an example, the following query demonstrates how to retrieve usage data for October 18, 2023 (UTC), segmented by individual Firestore database IDs.

To establish a seamless workflow for exporting your Cloud Billing data to BigQuery, please consult the Cloud Billing documentation for step-by-step instructions. Additionally, you can use tags to facilitate granular cost breakdown across multiple Firestore databases. For a deeper understanding of the resulting data structure and schema, please refer to the “Structure of Detailed data export” documentation.

Delete a database

If your Firestore database has served its purpose and you no longer need it, you can easily delete it directly from the console with a few clicks.

Things you should know when deleting the database:

• Deletion - Once deleted, Firestore performs the data deletion on your behalf.
• Cost - There is no associated cost with executing the deletion operation itself. Firestore stops charging you for the storage cost one day after the deletion operation.
• Backups - Firestore backups operate with independent resource lifecycles. Removing your Firestore database will not automatically delete the backups associated with the source database.

Best practices

• If you are new to the Firestore, we recommend starting with a new database with the resource name `(default)`. The (default) database benefits from free-tier support, enabling you to explore Firestore’s functionality without incurring immediate costs. Additionally, legacy App Engine runtime support is limited to the default database.
• Always activate delete protection for critical databases. This safeguard prevents accidental deletion and helps ensure data integrity in production environments.
• Carefully choose database resource names and locations during creation, as these attributes cannot be altered post-creation. However, you can delete the existing database and subsequently create a new one with the same desired resource name, but in a different location. This lets you adjust the location but retain the original resource name. Remember to back up your data beforehand if you plan to recover it in the new location.

What’s next?

In the near future, Firebase Console will introduce support for managing multiple Firestore databases. Stay tuned!