Firebase vs. Couchbase — Feel the Difference

Kristina Skachkova and Alexey Tymchenko
Mobile Team at Rozdoum

Looking for the perfect database for a mobile application development, a developer faces the variety of options.

In this article, Rozdoum’s mobile development experts try to uncover the truth and compare at least two of them — Couchbase and Firebase. Our mobile team shares some cases based on live custom projects implementation and real-life expertise.

Last year Google announced their new product Firebase. As you may know, Firebase is a platform, which is intended to develop a mobile application quickly and contains the diversity of additional tools to implement features for apps. It may be used for data analysis, hosting, data storage and much more. I was eager to have my hand on that and rushed to try Firebase with the real projects. Indeed, the possibility to store and synchronize data in real time catch me the most. The main reason is that real-time data exchange has become the common requirement for a mobile app development. Before Firebase times and as an alternative, in our current mobile projects, we used Couchbase, as a solution for the real-time sync.

There are several cloud mobile platforms existing to help developers with mobile app creation. For example HP Cloud, Heroku, Google Cloud Platform, Amazon Web Services, Microsoft Azure, Rackspace Cloud, Couchbase Mobile, Firebase, and others. Our mobile team possesses experience with two of them — Couchbase Mobile Database and Firebase Realtime Database which we used in customers’ projects. Here I would like to compare these two, highlighting pros and cons of each of them. Let me start with a short overview of technologies under the hood.

Couchbase Mobile

Couchbase Mobile is a NoSQL database that keeps information as a JSON document. It provides security access and background synchronization between all clients. It includes Couchbase Server, Sync Gateway, and Couchbase Light.

Couchbase Server manages and stores data in a document-oriented JSON format. It can be scaled to billions of records and terabytes of data.

Couchbase Light is a lightweight embedded database that manages and stores data on a mobile device.

Sync Gateway provides synchronization between Couchbase Server and Embedded database. It supports conflict resolution and provides security connection between Couchbase Server and Embedded database.

By the way, all operations with data are executed with the built-in enterprise security level which supports user authentication, a user, and role-based data read/write access control, secure transport over TLS, and 256-bit AES full database encryption.

Couchbase schema

Our mobile development team and I have gained an extensive expertise with Couchbase and learned almost all hidden pitfalls and traps of this document store. For me developing for Couchbase Mobile was not an ordinary thing at the start and I faced a number of challenges, like:

• First of all, a developer should always keep in mind that it is not a relational database. He needs to work with a document as a data unit.
• Second, it is impossible just to make a query with the required criteria. A developer should build a View and add data to it first. It resembles a creation of the index for tables in relational DB. Further on, to obtain data you need to request this view with filters by keys.
• Third — the first initialization of Couchbase View is a time-consuming process, which might make have an effect on UI. So, a developer need prevent UI from locking when running this process.
• Another problem is that developer should download and install the Couchbase Server and Sync Gateway to start working with Couchbase Mobile (CM). Couchbase does not provide any cloud services that developer can use from the start.

The Views, that developer creates at the beginning, provide a really good speed of queries processing. Once a developer works with the view, he receives a lot of flexibility to work with data models. Owing to views, he can add different data types entities into one view and then receive them with a single request.

Synchronization

Having the server with Sync Gateway, a developer can monitor changes in every document that were added or edited from the client’s side. He can use such a document handling to add access rules, change some fields or even add additional information to the document if needed. It means that some logic can be hidden from the client and supply additional security to the app in this way.

Security

The security restrictions in CM can be established with the help of users, roles, and channels. If users and roles are standard and common features, the channels are unique functionality. Channels are some groups of entities combined with the special purpose. Subsequently, a developer can filter such groups and set access rules to them. For example, a developer can add some channels to an entity and restrict which channels a definite user can see. Moreover, he can filter what documents will be synchronized by a mobile, in order to limit the amount of transferred data.

Conflict Resolution

If one document is updated simultaneously by several users, a conflict of revisions may occur. In that case, Couchbase Mobile will store all revisions of the document. By default, CD (Couchbase Database) returns one of the conflict revisions randomly. Otherwise, a developer can always provide his custom logic to resolve conflict — merge several revisions or simply chose one, and delete all others.

To sum up, Couchbase Mobile is a tricky thing to start, while the more experience you gain, the more advantages it may provide for your projects with seamless synchronization between the server and the mobile client and managed access to data.

Firebase

Firebase is a cloud-based service, which provides functions for storing data, analytics, cloud messaging, hosting, notifications, remote config, app indexing, dynamic links and other helpful tools for developing and growing your application. The most of these functions are free, but Firebase has the restriction on the amount of data to be stored and transmitted.

Realtime Database, which I am going to describe below, is the part of Firebase platform.

Firebase Realtime Database is a NoSQL cloud-hosted database where data is stored as one JSON object and synchronized between all clients. Besides, it caches required data locally to be available offline. Due to these two features, we were really interested in trying Firebase and comparing with the existing solutions on Couchbase.

Firebase schema

To start working with Firebase, a developer should register and create an application. There is a management tool — Firebase Console with its very comprehensible UI and with a step-by-step guide to help him with this process. The next step for the developer is to provide a property file and add SDK to his project. That’s it. He can start working with all Firebase functions without any additional configuration or running supplementary servers or services.

Same as Couchbase Mobile, Firebase Realtime Database (FRD) is not a relational Database. FRD stores data in a JSON format, but unlike Couchbase the data is stored as one JSON object. It means that all entities will be set as a model tree. For example:

{
  "users" : {
    "-UserId1" : {
      "userName" : "user-111",
      "registrationDate" : 1479924199695,
    },
    "-UserId2" : {
      "userName" : "user-222",
      "registrationDate" : 1479924199695,
    }
  },
  "posts" : {
    "-PostId1" : {
      "authorId":"-UserId1",
      "createdDate" : 1480092667004
      "title" : "Post 1"
    },
    "-PostId2" : {
      "authorId":"-UserId2",
      "createdDate" : 1483492667344,
      "title" : "Post 2"
    }
  }
}

On the one hand, it is really convenient to use such a tree structure. The issue occurs when you try to receive the list of entities filtered by several conditions or sorted by multiple fields. It is not a big problem for small projects, While dealing with medium or large-scale projects, it can be the reason to refuse using FRD at all.
Synchronization
Another interesting difference between CM and FRD is data synchronization. CM synchronizes all public data the user have access to, organized by channels, with that on the client side, we get the replica of all relevant data from the server. FRD operates on local cache on a device and can be refreshed on the entity level. Update of affected entities can be initiated by a request. Both these approaches allow access to local data without a need for instant connection to the server side.
This is the point when details really matter. For example, if we are working with a social app having a post list, the CM will download all posts on the client side to show it, on the contrary to FRD where it is possible to set a limitation and download just 10 newest posts only, for instance.
Security
The security restrictions in FRD can be set using users authorisation and FRD security rules. FRD security rules are executed when data is read or written. For example, to restrict reading or writing rights of the user’s profile, the developer should add the rule where he can set that only an owner is able to do it. It will be written in two conditions in the Firebase Console:
{
  "rules": {
    "profiles": {
      "$userId": {
       ".read": "auth != null && auth.uid == $userId",
       ".write": "auth != null && auth.uid == $userId"
       }
   }
}

Like with CD channels, FRD security rules are used to set conditions for data access levels. Unlike CD channels that are simple keys or, if you like, labels, FRD Security Rules have expression based format — that give the developer more choice and flexibility.
Conflict Resolution
The conflict resolution in the FRD works via transactions. Let’s clear it out, every time an entity is updated, such the update can create a conflict, and Transaction Operation is the tool to avoid it. For example, the conflict may happen, when you update the count value of an entity. These updates should be settled as a transaction. Then the transaction block will be executed synchronously on different devices. CM offers another solution as described above. When choosing the DB for a project, a developer should learn the difference.
Conclusion
To conclude all above, Couchbase Mobile Database is an excellent service for large-scale projects with huge data amount on the server side and a complicated data processing with relative small chunks of data on the client side. Although, it may be hardly used for some projects with the big amount of public data that any user should have access to on the client.
On the other hand, Firebase Realtime Database best suits for small and medium projects, without tricky data operation, and with simple functionality. Though, if you plan to build another Facebook, it is not a solution you need.



ADVANTAGES


Couchbase Mobile Database
Firebase Realtime Database




Real-time synchronization;
All data available offline;
Security for reading and writing data;
Data indexes;
Stability;
No data restrictions;
Open source service;
The conflict resolution can be customized;
Some logic can be hidden from a client.




Real-time synchronization;
Offline work;
Security for reading and writing data;
Free for small projects;
Easy to start;


It synchronizes only data that user requests.




DISADVANTAGES


Couchbase Mobile Database
Firebase Realtime Database




Not easy to start;
Application server is needed;
It is hard to limit an amount of synchronized data;
Constant speed inspection and query optimization are required.




No possibility to run a complicated query within a database;
No reduce function;
Data amount restrictions exist;
Commercial platform;
No customization of the conflict resolution process;
All logic is provided on a client device.





 Want to persuade us? Share your thoughts, ask us the questions and read more from our mobile team expertise.