We are pleased to inform that Google were announced that Firestore Multiple Databases is now generally available. This feature improves data separation, security, resource management, and cost tracking by allowing you to manage multiple Firestore databases within a single Google Cloud project. With this milestone, all of Firestore’s SDKs, terraform resources, and the Google Cloud console now fully support multiple databases.
Strong data separation and performance are guaranteed by the independent isolation that each Firestore database enjoys. For instance, hotspotting traffic loads on one database won’t have a detrimental effect on how well other databases in the project operate.
How to create Firestore Database?
Here’s how to use the console to quickly create a new Firestore database:
- Go to the Firestore service by navigating.
- Select “CREATE DATABASE” from the menu.
- Select a database id to act as your database’s unique identifier.
- Choose the desired settings for the database configuration (Database Mode, Location, Configuration of Security Rules, etc.).
Note: Once created, the database ID and location cannot be altered, so make your selection wisely!
Do you want even more authority over the development and upkeep of your Firestore database? The Firestore database can be created and managed with Terraform, Firebase CLI, and gcloud. See the Firestore documentation’s “Create a database” section for a comprehensive walkthrough of these options.
Set up Firestore database security
Through IAM conditions, Firestore enables you to apply fine-grained security configurations on a single database. This feature enables precise, granular control by enabling the application of different security policies to different databases. As an example, you can only allow access to particular databases for particular user groups, which guarantees strong security and data isolation.
Using the conditions editor tool, apply the following conditions to a particular database:
- Select the resource “firestore.googleapis.com”.kind
- Enter the database resource name in the format “projects/<project-id>/databases/<database-id>” as resource.name.
A few things to consider when setting up a security policy are:
- If no condition is specified, all Firestore databases in the project will be automatically accessible to all IAM principals who are granted permission.
- Tags are integrated with Firestore. By using a tag association, the integration enables you to allow or prohibit access to a specific set of databases. For further details, see the documentation for Conditional Access and Tags.
- Similar to Firebase Security Rules, Firestore gives you more precise control over database access inside of your Firebase project. See the “Set up Firestore Security Rules” section for detailed instructions on how to further explore Granular Firebase Security Rules for Firestore.
View database costs and usage along with a billing breakdown
Per-database billing and usage breakdowns are provided by Firestore. You can use BigQuery to retrieve this cost data. The query that follows, for instance, shows how to obtain usage information for October 18, 2023 (UTC), broken down by specific Firestore database IDs.
For detailed instructions on setting up a smooth workflow for exporting your Cloud Billing data to BigQuery, please refer to the Cloud Billing documentation. Tags can also be used to enable fine-grained cost distribution among several Firestore databases. Please refer to the documentation titled “Structure of Detailed data export” for a more thorough understanding of the resulting data structure and schema.
Delete a Firestore database
With a few clicks from the console, you can quickly and simply remove your Firestore database if it has outlived its usefulness.
A few things to consider before deleting the database are:
Deletion: Firestore removes data on your behalf after it has been deleted.
Cost: There are no extra expenses related to carrying out the deletion process. After the deletion operation, Firestore stops billing you for the storage cost one day later.
Backups: The resource lifecycles of Firestore backups are independent. The backups connected to the source database will not be erased automatically when your Firestore database is removed.
Backup Firestore database
It is advised that you create a new database with the resource name {(default)} if you are unfamiliar with the Firestore. Free-tier support is available for the (default) database, so you can test out Firestore’s features without having to pay anything up front. Moreover, the default database is the only one supported by the legacy App Engine runtime.
For vital databases, always have delete protection enabled. In production environments, this safeguard helps maintain data integrity by preventing accidental deletion.
Because they cannot be changed after creation, database resource names and locations should be carefully chosen during creation. On the other hand, you can remove the current database and then make a new one in a different location with the same resource name as needed. By doing this, you can change the location while keeping the resource name the same. If you intend to recover your data at the new location, don’t forget to make a backup of it beforehand.
What comes next?
The ability to manage multiple Firestore databases will soon be available in Firebase Console. Keep checking back!
