Firestore vs. Realtime Database
For the development of any application such as desktop, mobile, and web, a database is our prerequisite to store data. Storage is required where we can store and manipulate the data in such a way that every application can access the same data. Firebase provides Firestore and Firebase Realtime Database. These databases are cloud-based, client accessible database solutions which support real-time data syncing.
Cloud Firestore
Firestore is the newest database used for mobile app development. Cloud Firestore has richer features, faster queries, and scale further than the real-time database. Cloud Firestore is a flexible as well as scalable NoSQL cloud database. It is used to store and sync data for client and server-side development. It is used for mobile, web, and server development from Google Cloud Platform and Firebase.
Realtime Database
It is the original database of Firebase. It is a low latency solution and efficient for mobile applications which require synced states across the client's real-time. The Firebase Realtime Database is a cloud-hosted database in which data is stored as JSON. The data is synchronized in real-time to every connected client.
Let's understand the difference between Firestore and Realtime database.
The Cloud Firestore is the recommended database for most of the developers to start a new project. Cloud Firestore provides additional functionality, performance, and scalability over infrastructure designed for supporting more powerful features in future releases. Expect to see more robust security rules, new query types, and performance improvements among the advanced features employed for Cloud Firestore. There are the following factors based on which we can compare both of the database solutions:
Data Model
The Firestore and the Firebase Realtime database are NoSQL database that means there is no need to create the table and define the schema.
| Realtime Database |
Cloud Firestore |
| In the Realtime database, data is stored as one large JSON tree. |
In Cloud Firestore, data is stored as a collection of documents. |
| The data is simple, so it is very easy to store. |
In documents, simple data is very easy to store. Documents are very similar to JSON. |
| The complex, hierarchical data is difficult to organize on a large scale. |
By using sub-collections, the complex and hierarchical data is easy to organize on a large scale.
It requires very less de-normalization and data flattening. |
Realtime and offline support
Realtime database and Firestore support local data storage to offline-ready apps and have real-time SDKs.
| Realtime Database |
Cloud Firestore |
| Offline support for Android and iOS clients. |
Offline support for Android and iOS clients. |
Presence
Presence is useful to know about when a client is online or offline. Firebase Realtime Database provides updates whenever the client's connection state changes by recording client connection status.
| Realtime Database |
Cloud Firestore |
| Realtime database supports presence. |
The Firestore doesn't support presence natively. We can take advantage of the help of real-time databases by syncing Cloud Firestore and Firebase Realtime database using cloud functions. |
Querying
Retrieving, sorting, and filtering data from either the Realtime Database or Cloud Firestore through queries.
| Realtime Database |
Cloud Firestore |
| It allows us to perform deep queries with limited sorting and filtering functionality. |
It allows us to perform indexed queries with compound sorting and filtering. |
| The queries can sort or filter on a property, but not for both. |
In Cloud Firestore, we can chain filter and combine filtering and sorting on a property in a single query. |
| It has deep queries by default, so it always returns the entire subtree. |
It has shallow queries, so these queries return documents in a particular collection or collection group. These queries don't return sub collection data. |
| Realtime database queries can access data at any point, down to individual leaf-node values in the JSON tree. |
Cloud Firestore queries always return whole documents. |
| These queries don't require an index. But, the performance of certain queries degrades as our dataset grows. |
Cloud Firestore queries are indexed by default. The performance of the query is proportional to the size of our result set rather than a dataset. |
Write and Transection
| Realtime Database |
Cloud Firestore |
| Only basic write and transection operations can perform. |
It allows performing advance write and transection operations. |
| In real-time, the data is written through set and update operations. |
In Cloud Firestore, data is written though set and update operation. With the help of advanced transformations such as array and numeric operators, we can also write data. |
| On a specific data subtree, the transactions are atomic. |
From any part of the database, the transections can atomically read and write data. |
Reliability and Performance
| Realtime Database |
Cloud Firestore |
| It is a single-region solution. |
It is a multi-region solution which scales automatically. |
| For zonal availability in a single-region, databases are limited. |
Protects our data across multiple data centers in different regions, ensuring global scalability and strong reliability. |
| Extremely low latency, the ideal option for frequent state-syncing. |
Available in either regional or multi-regional configurations around the world. |
Scalability
| Realtime Database |
Cloud Firestore |
| Sharding is required for scaling. |
Here, scaling is automatic. |
| It scales approximately 200000 concurrent connections, and 1000 writes per second in a single database. Beyond that, it is required to divide the data into multiple databases. |
The scaling is done automatically. At present, it can scale up to 1 million concurrent connections, and 10000 writes per second. The limits can be increased in the future. |
| For an individual piece of data, there is no local limit on write rates. |
It has limits for individual documents or indexes. |
Security
| Realtime Database |
Cloud Firestore |
| It uses cascading rules-language, which separates authorization and validation. |
It uses no-cascading rules which combine authorization and validation. |
| By Realtime database rules, reads and writes from mobile SDKs secured. |
With the help of Cloud Firestore security rules, reads and writes from server SDKs secured. |
| The read and write rules are a cascade. |
The rules are not cascaded unless we use a wildcard. |
| The data is validated separately using the validation rule. |
The rules can constrain queries. If the result of the query might contain data, the user doesn't have to access it, then the entire query fails. |
Pricing
| Realtime Database |
Cloud Firestore |
| Charges for bandwidth and storage only, but at a higher rate. |
Mainly the operations performed in our database and are charged at a low rate, bandwidth, and storage. |
|