If you are looking to develop rich applications using a completely scalable and serverless database, Cloud Firestore is your answer. It scales to meet any requirement and seamlessly integrates with Google Cloud Services and Firebase. An intrinsic component of the Google Firebase platform, this cloud-based NoSQL database server is ideal for syncing and storing data and integrating with mobile and web apps.
It offers flexible cloud database storage with real-time updates and descriptive query features. Although it has numerous attributes that help speed up development at a low cost, it does come with a few drawbacks that can hinder the pace of development. Firestore can be the best choice to get your app to the market quickly, but it is necessary to be aware of its shortcomings.1
Cloud Firestore – An Overview
Besides being reliable and simple to use, developers can integrate Firestore with several technologies like C++, Java, Unity, Go, REST, SDK’s, and RPC APIs.
It leverages Google’s Access Management and Cloud Identity technologies for authentication. Data stored is logically subdivided into collections and the document supports several file types, strings, numbers, and nested objects.2
Before we dive into certain features of Firestore that can make or break your application, it is imperative to understand the its model.1
Cloud Firestore Data Model
Firestore is a document-oriented, NoSQL database without tables or rows like a SQL database. Data is stored in documents which are then organized into collections. Each document is stored in key-value pairs and it is optimized to store huge collections of small documents. The collections have sub-collections and nested objects that include primitive fields such as strings and complex objects like lists. Collections and documents are implicitly assigned to Firestore. Data is assigned to a specific document within a collection. If the document or the collection does not exist, it creates it.3
Main Drawbacks of Cloud Firestore
Now that we have gone through the basics let’s look at a few aspects that may not work for your application, especially for developer testing.
- Does not run locally: Setting up databases in Firestore is challenging as it does not support a local database environment that you can download and set up on your computer. If you need to write and run tests that need a local database setup, it is difficult to implement this.4
- Too Slow: The initial call to subscribe to a Firestore collection takes a long time. A single call takes over 10 seconds in production code before the result is returned. This call delay happens in every test, making it a frustrating problem for the developers. Often, the tests fail due to timed-out requests when the query may not return data for 20 seconds.3
- Cannot test complex queries: Firestore allows multiple queries to be submitted by stringing conditions together. However, the only way to index a complex query is by manually pressing a button in the Web Console and waiting for the indexing to finish. Although this may work fine for production, it is not optimal for testing. If you do not have a local database and choose to let the test suite create the top-level collection in Firestore for testing, these collections will be unindexed. Any complex queries to this collection will be rejected. Even if you create a Firebase project just for testing, the database will be shared amongst the tests across client apps and all will write to the data simultaneously, causing tests to fail.
- No control for developer tests: If your test involves writing a test suit that adds 5 items to the database, it is impossible in Firestore. Since it only supports a shared database environment, several tests add and delete items and it is impossible to maintain the count between the start and end of the test. Database cleanup after every test is also not attainable with Firestore.5 Fundamentally, it works great for production but not so much for developer testing.
- Querying limitations: One of the biggest drawbacks is its inability to query data by their sub-collections. For instance, consider the data structure user collection>user document>friends collection>friend document>friend data (name, phone, email id). In this structure, it would be impossible to fetch users with a specific name and email id. Firestore offers a temporary fix for this problem which is replacing sub-collections with arrays. But this solution will impact the read-write performance as the application grows in scale. Another querying flaw is its inability to permit querying all documents within a specified radius. For instance, if you are building an app like Uber, and the user needs to find all cabs in the user’s location. This feature cannot be incorporated in Firestore without the aid of third-party libraries.6 Some other significant query limitations are:
- Only offers limited support for logical OR queries
- For compound queries, the range checks ( <, >, <= , >=, !=, not-in) comparisons must all filter on the same field
- You can use utmost one “array-contains,” “array-contains-any”, “in” or “not-in” clause per query
- You cannot use a combination of “in”, “not-in”, and “array-contains-any” in the same query
- You cannot order your query through a field included in a “==” or an “in” clause.7
- Full-Text Search: It does not allow the users to query data by incomplete text. E.g., if a user types “Jo” to search for the name John by scanning all the names that contain “Jo”, it is not possible and needs a third-party software to perform a full-text search. 5
- Document write frequency: If you are not prepared, Firestore’s limit on write frequency on documents could catch you off guard. The app will not be able to scale due to load. The maximum write rate to a document offered is 1 per second. The user may manage frequent writes for short time but may not sustain for more time at a higher rate. Although this issue may not impact development, it could pose a problem under load during production.5
- Document size limit: Firestore imposes a limit of 1 MB on the size of data that can be stored in a document. Although this may be sufficient in most cases, it could hinder the use of array field types that can grow over time. If you have an array field type without an upper limit, such as a string array to store user IDs, your app could run into scaling issues. Over time, repeat occurrence of the ID cannot be stored due to the 1MB limit, and further writes to the document will fail.5
- Indexing Limit: There is a limit on the number of indexes that can be used. The maximum number of composite indexes for a database is currently 200 and the limit of indexes per document is 40,000. This represents the maximum number of fields you can index for each document. 8
Cloud Firestore is powerful, but it doesn’t always work
Just like any other database out there, it is optimized for specific use cases only. Fortunately, there are workarounds to manage a few of its limitations. Although Firestore does not accomplish everything, it can be used alongside other databases for specific queries or searches.