Once I decided my journalism app needed a database, I considered first and foremost what data would be stored and what I wanted to do with it.
Determining the requirements surrounding your data and application is, in my mind, the most important consideration in choosing a database. There is no one superior database—all have different pros and cons. It’s important to know what you absolutely need, and what you can do without.
In my application, users will be able to put together outlines from excerpts of existing notes. Those outlines would need to be saved somehow from session to session. I also know my users need to be able to access their work offline. That meant that I needed a database that would sync data and allow my app to work both online and offline. Second, even if I stored data locally at first, I could easily picture a scenario where the user generates so much content that it fills up the allotted space on their device. I would eventually want to set up a remote database to push content.
I’m developing an iOS app using PhoneGap, and my database would need to play nice with those technologies. Although not necessary, I liked the idea of a flexible data structure without needing to rely on tables (NoSQL it is). Finally, I wanted good performance in general and relative ease of use.
There are some things I did not require. For instance, I don’t need robust conflict handling, because multiple people will not be editing the same document at the same time. Each user will have their own set of work, so that requirement is not applicable.
Checking Out the Options
I came to the conclusion that I had three main options for my mobile app database. First, I could store all data locally (perhaps with an embeddable database) on the device itself. Second, I could store data on a remote server. Finally, I could offload everything—the maintenance of a server, creating an API, and all tasks—to a third-party solution, also known as backend as a service.
I mainly considered options one and two, purely out of ease of use.
My Brief Fling with Local Storage
For awhile, I entertained the idea of relying solely on local storage. Local storage is basically an object that operates on a key/value system, allowing you to save data across sessions. Since it’s client-side, the user can access their data offline. What drew me to it is how simple it is to use. No additional setup is required to use local storage, as it’s already available to you on your browser.
After more research, though, I realized that using local storage wouldn’t be a good move for my application in the long run, especially as I’m dealing with more and more story outline and note objects. Local storage doesn’t scale well and can quickly become heavy and messy. Second, local storage data is be confined to the device. If a user deletes Leder, he or she would all lose their data as well.
Playing the Field
I looked at over a dozen databases that ranged from full-service database and hosting services like Parse and Firebase, embeddable databases like SQLite and Couchbase Lite, and open-source scalable databases like RethinkDB. I even considered non-database plugins and libraries like ng-Storage and localForage that make use of local storage in an easier and neater way.
They all loosely fit my requirements to some degree. I noted the pros and cons of each, and even tried setting up a few to test them out.
The Perfect Match
I finally decided to go with PouchDB, an open-source NoSQL database designed to run in the browser. It is free, syncs offline and online, and integrates well with Ionic and Angular.
According to their website, PouchDB lets you create a local database or a remote database. Local PouchDB databases use whatever underlying datastore is available (which means IndexedDB in most browsers). It can also communicate directly with a remote database, be it CouchDB, Couchbase, etc. This makes it easy to sync between the two, so even though I’m starting out just using a local database, I can easily set up a remote one down the road. Plus, as a NoSQL database, PouchDB lets you store unstructured documents rather than tables, which is a better fit for my data.
It’s been about a week since I set up my PouchDB database, and it’s going surprisingly well. Getting my database up and running was refreshingly simple. I followed this guide by Ashteya Biharisingh, lifting a few lines from the API itself. After I initialized the database, I set up a service that will get and post data. Basic database methods (get data, put data, update data) are intuitive and easy to execute in PouchDB. So far, I have no complaints.
What do you think about my pick? Which databases are you using for your mobile apps? Leave your thoughts in the comments below!