Firebase, Meteor & Cognito: Just Enough Database for a Mobile World

DZone 's Guide to

Firebase, Meteor & Cognito: Just Enough Database for a Mobile World

Rather than just storing data on a single device, users also now increasingly expect apps to make their data quickly and easily accessible across all of their devices.

· Big Data Zone ·
Free Resource

This article comes to you from the DZone Guide to Database and Persistence Management. For more information—including in-depth articles from industry experts, profiles on 35 database solutions, and more—click the link below to download your free copy of the guide.

Everybody is building mobile apps these days, both natively and for the web. Part of the value of almost any non-trivial app relates to its ability to store data for a user. This can range from something as obvious as a to-do list app, whose entire value-proposition is its ability to remember things for a user, to less obvious cases like mobile games, which may want to store game state or high-scores for the user.

Rather than just storing this data on a single device, users also now increasingly expect apps to make their data quickly and easily accessible across all of their devices. Furthermore, when they have multi-device access, they don’t want to have to worry about whether internet connectivity is missing or intermittent. The app should be able to store it locally and then synchronize with the cloud later.

As soon as remote data storage becomes a requirement for an app, a whole bunch of new back-end infrastructure needs to be set up by the developer. Even with the rise of the cloud infrastructure, this is still a lot of work.

  • You need to pick app server and data store software, then run a bunch of wiring code to pipe data between the client and database.
  • If you want offline data access to work, you need to build local storage into your client and get the local- remote syncing logic right.
  • If you want real-time data syncing between clients, you need to introduce real-time web protocols, or simulate them using techniques like long-polling.
  • Finally, to secure your user’s data so that only they can see it, you need to either build your own infrastructure to securely store and verify user credentials, or integrate with services like Facebook or Twitter to allow people to use their existing credentials.

In this article, we’ll look at three platforms that aim to give developers a quick and easy way to implement the common mobile app use case of “storing stuff” for users across devices. All of these frameworks can run in offline mode and offer mechanisms for automatic syncing. They all also have the ability to integrate with OAuth-based identity services.

It’s important to understand that these platforms are not relational databases and thus do not offer features like JOIN queries or full ACID transactions. Instead, their goal is to provide just enough data storage capabilities for a mobile app to satisfy the storage needs of its users. However, they each have their own limitations and trade-offs.


The first platform we’ll cover—and probably the best known—is Firebase, an API for storing and syncing data. Recently acquired by Google, Firebase provides client-side libraries for Android, iOS, all major JavaScript browser frameworks, Node.js, and Java. These libraries give clients impressive real-time data-synchronization capabilities. The Firebase platform is essentially a fully-hosted service that stores JSON in a tree accessed via RESTful URLs. One thing to note is that when you load a node in the tree, you get all of the data under that node. Consequently, to avoid downloading too much stuff to the client, it’s important to minimize the depth of the tree.

Firebase allows data to be shared between users. To restrict how data can be accessed by particular users, it provides a server-side rules language. However, it’s important to understand that Firebase has no application layer by default—you essentially go directly from your client to the database. Because of this, the rules language also includes capabilities for doing data validation.

Firebase has simple querying capabilities. However, it’s important to configure indexing rules on query criteria to keep performance manageable. Queries that you run with Firebase are live—if the data underlying the query changes after the query has been run, then the query results will automatically update.


Meteor is a platform for building web and mobile apps. Like Firebase, it has very impressive data synchronization capabilities, including support for live queries. However, Meteor goes even further by allowing you to write code that can be run on both the client and the server-side. This gives you a great deal of flexibility from a security and data validation perspective. The catch is that all development has to be done with Javascript, HTML, and CSS. If you want to deploy your app to an app store, the best you can do is package it all up inside a native wrapper. By default, Meteor uses MongoDB as a data store, which basically means that you get Mongo’s query capabilities. There is also early support for Redis and plans for other databases in future.

It is very easy to get up-and-running with Meteor, as it bundles both an application server container and a local Mongo instance out of the box. It also provides command- line tools for automatically packaging your client and server-side code and deploying it to the cloud with a hosted app server and datastore. This saves you from having to setup a complex build and deployment process yourself. The Meteor platform is comprised of a number of libraries and tools. While they can be used in isolation, they work best together. For example, Meteor’s live-updating view library (Blaze) is designed to integrate seamlessly with its remote data syncing capabilities.

One downside of this integration is that, to get up and running quickly, you have to learn the framework in its entirety, putting aside any skills you might already have with Javascript MVC frameworks like AngularJS, Ember.js, or React. Some work has been done integrating Meteor with AngularJS to get the best of both worlds, but it is only at an early stage.


Cognito is a new offering from Amazon Web Services (AWS) that provides a quick and easy way to authenticate users and store data for them. It integrates tightly with AWS’s existing identity management infrastructure, but can also be used with other OAuth providers. Like Firebase, clients go directly to the database rather than through an application layer. To make this secure, no data can be shared between users. Any additional data validation you do will have to be duplicated between different client types, as there is no shared server to put it on.

Interestingly, Cognito has gone with a native-first approach to its client-side libraries. Full support for both the identity and data synchronization components of Cognito is available for iOS and Android, but the synchronization component for the Javascript libraries is still only in developer preview mode. These libraries provide simple support for syncing data between local and remote storage. However, in contrast to Meteor and Firebase, developers have to manually trigger when they want synchronization to happen, and handle any conflicts themselves.

All of these platforms herald a shift away from the traditional three- tier, request-response approach to storing and accessing user data.

Cognito’s data storage capabilities are very basic. An app can have multiple datasets, each of which can be considered roughly equivalent to a table. Keyed records can be inserted into each dataset. However, you can only look up records by their key—any more sophisticated querying would require a full scan of the dataset. That said, if Cognito’s data-storage capabilities are not enough, you can also use it to connect to other AWS services like S3 or DynamoDB. However, you lose its offline and synchronization capabilities when you do this.

Which One You Might Use

Which of these frameworks you use depends very much on your storage needs. If you have really simple requirements and you’re looking specifically for user authentication as a service, Cognito should be enough, especially if you are already familiar with the Amazon ecosystem. However, its inability to query or share data between users will be a deal-breaker for many scenarios.

For the majority of use cases, Firebase is probably a better fit, as it gives you a far more powerful datastore. The biggest risk with Firebase is that your security and validation requirements won’t be met by Firebase’s rules mechanism. If that’s the case, you could start using Firebase in your own app server, or move onto a full-stack framework like Meteor. The natural trade-off of the full-stack approach is that you get more locked in to the specifics of the platform. In the case of Meteor, this means you have to fully embrace JavaScript and the Meteor way of doing things.

Regardless of which you pick, all of these platforms herald a shift away from the traditional three-tier, request- response approach to storing and accessing user data. To one degree or another, they take care of the minutiae of data storage, ensuring our user data is instantly available everywhere, all the time.

BEN TEESE is a senior consultant at Shine Technologies. He spent 10 years as a back-end Java developer before moving into front-end development with Rails and, more recently, Javascript SPAs. He spends most of his time building mobile web apps and, occasionally, iOS apps.


big data, bigdata, data store, database, java, mobile, nosql, sql

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}