A guide on how to choose a database for your mobile apps

A guide on how to choose a database for your mobile apps Wayne is the Chief Architect of Mobile at Couchbase, where he is responsible for leading vision, strategy and development for the company’s mobile solutions. Before Couchbase, Wayne spent 7 years at Oracle as the Architect responsible for driving mobile innovation within the CRM and SAAS product lines. He has 11 patents pending from his work at Oracle. Prior to Oracle, Wayne held technical leadership positions at Siebel working on their CRM product line.


To require an internet connection for mobile applications is to live in the past. If apps rely on a connection, odds are high that the experience will be sluggish and unpredictable.

To avoid reliance on the network, providers of databases and cloud services have started to add synchronization and offline capabilities to their mobile offerings. Solutions like Couchbase’s Couchbase Mobile, Microsoft’s Azure Mobile Services, Amazon’s Cognito, and Google’s Firebase offer the all-important sync that enables apps to work both online and offline. 

With so many offerings available, how does a mobile developer select the right technology for the right application? The following six key criteria are most important when evaluating mobile solutions: platform support, security, modeling flexibility, conflict resolution, sync optimization, and topology support.

Support for the right platforms

What client platforms are supported? Do you need to go beyond iOS and Android? Are you looking to support platforms that aren’t traditionally considered mobile, such as embedded systems, IoT devices, and wearables? Are you looking to support Windows and OS X desktops and laptops as well? Many of today’s applications start on mobile, then add a native desktop or Web companion app. It is important to evaluate database and cloud options based on the platform support that you need not only today but also in the future.

Secure at rest and in motion

When you’re using synchronized and decentralized storage it is important to access, transmit, and store data securely. To cover this completely, you need to address authentication, data at rest, data in motion, and read/write access.

Authentication should be flexible and allow for the use of standard, public, and custom authentication providers. Support for anonymous access is also important for many apps. For data at rest on the server and client, you’ll want support for both file system encryption and data-level encryption. For data in motion, communication should be over a secure channel like SSL or TLS. For data read/write access, the database should offer granular control over what data can be accessed and modified by users.

Models need flexibility

Data modeling flexibility will dictate whether you can articulate the model requirements for your apps in an efficient and appropriate way. Even more important, it will dictate whether you can efficiently evolve your model as your requirements change moving forward. Model flexibility is specifically important in mobile because today’s mobile apps evolve at a very fast pace.

Relational databases are still a good choice if an app requires strong data consistency or its data is highly relational. But when these requirements can be relaxed, NoSQL databases offer much greater flexibility.

Pesky conflicts

For mobile platforms or any other platform that utilizes decentralized data writes, the same data can be simultaneously modified on multiple devices, creating a conflict. The system needs to support a mechanism for resolving those conflicts. The flexibility of the conflict resolution mechanism is important and should allow resolution automatically, on the device, in the cloud, by an external system, and by a human. 

Conflict handling will differ for each system. Couchbase Mobile, for example, uses revision trees with a default resolution rule of “most active branch wins.” This is the same approach taken by revision control systems such as Git and much different than clock-based systems that take a “most recent change wins” approach. Clock-based resolution systems are problematic due to the issues around clock differences across devices. Couchbase also allows customization (via code on the client or on the server) to perform more sophisticated conflict resolutions like a three-way merge.

Sync at the right times

In addition to being able to resolve conflicts, it is important to have the ability to control how the system syncs. This includes replication strategy, conditional replication, and replication filtering. For replication strategy, look for support for streaming, polling, one-time, continuous, and push. You should also have the ability to use a combination of these strategies. For conditional replication, you may need to replicate data only under certain conditions, such as when the device is on Wi-Fi or when it has sufficient battery power. For replication filtering, you should have the ability to replicate some data but not other data.

Sync with the right partitions

Configurable sync topology support is needed to allow you to meet your partition requirements. In other words, you need the ability to configure the system to allow certain parts to operate offline. The most common topology is star. In a star topology, each device is connected to a central hub using a point-to-point connection that allows the devices to operate offline. Other common topologies such as tree and mesh allow different parts of the system (in addition to the devices) to operate offline. You may also want support for cloudless topologies that allow devices to communicate peer-to-peer and directly sync data among themselves. 

A POS (point of sale) system is a good example of a tree topology. POS systems require that a brick-and-mortar store continue to operate if it becomes disconnected from the rest of the system. In this configuration, POS devices would sync with a store-level database, which would sync with a global system. Thus stores could continue to operate and sync data with their POS devices regardless of connectivity to the global system.

When looking to add sync to your apps, you will need to determine if you should build a solution or get it from a provider. Building sync correctly is notoriously difficult and expensive, as it must deal with all of the complexities of distributed computing. For most apps, you will be better off leaving data synchronization to a specialized stack and focusing on your app features. The key is choosing a solution that is flexible. If you go down the build path, be ready to expend a significant portion of your time and resources on building sync and supporting everything listed above.

When choosing a mobile sync and storage provider, taking full measure of the above criteria will be critical to building secure, flexible, and manageable mobile apps that always work — with or without an Internet connection.

View Comments
Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *