2

Firebase: RealtimeDB & Firestore

 3 years ago
source link: https://blog.knoldus.com/firebase-realtimedb-firestore/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Firebase: RealtimeDB & Firestore

Reading Time: 2 minutes

Recently, while searching for persistence solutions for one of our projects, we started considering the hosted and managed offerings on the Firebase Platform. Firebase has two primary database offerings, the original Realtime Database (RtDB) and the newer Cloud Firestore (CFS) which is currently in beta.

In this post, we’ll briefly list down some of the current similarities and differences that we encountered while tinkering with both and hopefully arrive at a good starting point for considering one over the other.

Similarities

  • Both RtDB and CFS, are cloud-based, that means the ONLY place we get either of these, is across the network, and that we can’t have a local instance running on our machine.
  • Both are NoSQL document stores. That means, out of the box, they don’t enforce any schema constraints on the persisted data. They are schemaless by default.
  • Both support real-time data synchronization across devices. That means, devices subscribed to them will all receive real-time data update events, as and when data changes in the DB. This functionality is provided by the client SDKs which are officially provided for the supported platforms.
  • Mobile SDKs for both support local storage for making offline-ready apps. That means, that the app can be functional in part, even without network connectivity.
  • Both support some form of serverless authentication. That means each can be accessed securely & directly by clients, without the need of an intermediate authentication server, using out-of-the-box firebase offerings.

Differences

  • All RtDB data is stored as one large JSON tree. Think of RtDB as a cloud-hosted JSON tree, while in CFS, a Document is the unit of data storage (and it is NOT json, but rather, a set of key-value pairs). A Document can be max 1MB in size and must live inside some Collection (which are like directories).
  • In RtDB, simple data is easy to store, while complex, hierarchical data is harder to organize at scale. In CFS, simple data fits easily into a document and complex hierarchical data is easier to organize at scale, using subcollections within documents.
  • Queries in RtDB are deep by default, ie, they always return the entire subtree of the matching node. In CFS, queries are shallow by default, so, grabbing a document within a collection means, you only grab those documents. You don’t grab, additional subcollections.
  • Scaling beyond the capabilities of a single RtDB instance requires us to think sharding our data across multiple instances. In CFS, after beta, scaling will be completely managed and automatic.
  • In RtDB, charges are for bandwidth & storage. CFS charges primarily on operations performed (read, write, delete) in the DB. The former is costlier than the latter.
  • RtDB is a mature product, and comes with a bundled SLA on Firebase platform. CFS is still in beta so its performance guarantees aren’t as strong as RtDB yet, but are expected to be stronger than RtDB later.

Hopefully, this post gave a quick overview for considering one over the other, but as they say, the devil is in the details, so it is always advisable to evaluate your project requirements against the specifics of the solutions. Following are the detailed references for the same:
RtDB Docs | Firestore Docs | RtDB-vs-Firestore | RtDB Data Model | CFS Data Model


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK