Imagine you’re developing a simple app with a list of different objects which should be searchable. Your app has basic requirements like when an user click on an object, it must shows information like name, age, income, or anything else.
The Database selection for simple application like above won’t have drastic impact on the functionality and performance. But, it gets complicated when your application have demanding requirements.
Consider these use-cases for example:
Offline synchronization between multiple devices
When data synchronization and offline features are at the core of your mobile app, the users might have access to the same data and have the same CRUD rights.
This basically means that you would end in a situation where multiple users are editing the same data block – concurrently!
In other situations, we have an app that uses API to communicate with the server and perform CRUD operations. When a mobile app is offline, there’s no API connecting and dictating the read-write operations.
When a user now edits a shared doc that others are editing as well, the writes may or may not be accepted by the server when the app goes online again.
Let’s imagine this challenge better. Assume that we have the following situation:
Some users are editing records while they’re offline. So, how does the app responds to their changes? Let’ see which edits will be sent to the server first.
Assessing how complex the situation can get is a bit tricky, and many fail to accommodate for edge cases here. The solution here would require a locking mechanism to prevent data loss while synchronization.
When your application must work under high network interruptions
When any SQL databases lose network connection with the client side storage, it typically generates an error message instead of transferring the data as needed. If this problem occurs frequently, you may need to reconfigure your database.
Apart from that, there are other challenges to deal with MySQL and network interruptions:
Persisting local data including UN-synchronized transactions and app state
Getting mobile transactions and operations back to the main server-side database
Above listed issues occur on behalf of network interrupts, keeping a database that offers better reliability and resists connection loss is a better option in this case.
When you want to scale your app from 0 to 1 million users
Scaling = replacing all components of a car while driving it at 100mph
– Mike Krieger, Instagram Co-founder
When you think of scaling your application, you think of adding more resources in form of servers and making the database engine more efficient.
The Database should be able to utilize the resources and handle parallel processing, that means the Database must be multi-threaded.
Multi threading allows a database to schedule parallel tasks on the available resources and minimize the workload on the server-side.
Apart from multi threading, Distributed Design of a database is significantly important for scalability.
In a distributed designed database, you can split up the services on different threads to minimize the workload on the main database. This drastically improves the parallel processing of databases.
When your application needs Multi-Version Concurrency Control (MVCC) support
A support for Multi-Version Concurrency Control (MVCC) allows simultaneous access without blocking the threads or processes involved.
MVCC allows a reader to view a snapshot of the data before the writer’s changes, allowing the read and write operations to continue in parallel.
For instance, look at this table to see which databases have MVCC implementation:
Final thoughts
Many startups have failed their product and some have migrated on-time to avoid scalability issues like Crisp and Uber.
Baptiste Jamin@baptistejamin
I hope now, you'll think it twice before using Firebase: crisp.im/blog/why-you-s…18:18 PM - 18 Sep 2016
Crisp had to abandon Firebase, and Uber migrated from PostgreSQL to MySQL.
Developers and organizations should not ignore the importance of a database in their application as it can bring huge challenges in the future.
I agree that there are a wide number of database choices available to support different features of an application. Thus, it has become difficult to make a fair decision.
But, if you follow the right principles and map your app requirements correctly, then your application will not suffer from database problems.
This article is just a sneak peak of a more comprehensive guide on Database selection for mobile app developers.
Please feel free to share your thoughts and past experiences with database selection.
Top comments (0)