More and more mobile applications need data to work, and databases have for quite a while been the most common way of storing and managing data. So, in a typical scenario, a mobile application uses a database that is hosted in the cloud, and connects remotely to it in order to access its data. This, of course, implies that, in order to be responsive, a mobile application needs an active and quite fast network connection.
Where is mobile development heading to? Take the Developer Economics Survey that is now live and shape the future of mobile development.
But what if you could move your database from the cloud onto the mobile device, thereby allowing your mobile application to satisfy its storage needs without having to rely on any back-end storage service? Or what if you could keep your database in the cloud, but at the same time maintain a local up-to-date replica of it that would allow your application to be fully functional even when no network connection is available and to sync with the remote database periodically or when going back on-line? And what if you could do all that by using the same or similar tools with the ones that you are using now?
Embeddable databases are lightweight, self-contained libraries with no server component, no need for administration, a small code footprint, and limited resource requirements. Mobile applications can be (statically or dynamically) linked to them, and then use them in order to create and manage their own – private or shared – databases locally on the device. Behind the hood a database-management-related action typically involves only a few function calls within the same process.
At the moment there are several embeddable databases out there that you can use in a mobile application. Let’s examine the most popular of them and highlight some of their characteristics that have contributed to their widespread use. The next table gives an overview of the type of the data that each one of these databases can store, the license under which it is distributed, and the platforms it supports.
| Database | Type of data stored | License | Supported platforms |
|---|---|---|---|
| BerkeleyDB | relational, objects, key-value pairs, documents | AGPL 3.0 | Android, iOS |
| Couchbase Lite | documents | Apache 2.0 | Android, iOS |
| LevelDB | key-value pairs | New BSD | Android, iOS |
| SQLite | relational | Public Domain | Android, iOS, Windows Phone, Blackberry |
| UnQLite | key-value pairs, documents | BSD 2-Clause | Android, iOS, Windows Phone |
Berkeley DB
Berkeley DB is a family of open-source libraries that allow you to manage your data either in the traditional relational way (using SQL) or as key-value pairs (where both keys and values are byte arrays) or as Java objects or as XML documents. Regardless of the API you choose, Berkeley DB promises indexing, caching, transactions, single-writer/multiple-reader access, full-text search (for the SQL interface), automatic failure recovery, replication, compression and encryption. It also supports both in-memory and on-disk databases.
Another intriguing feature of Berkeley DB is that the SQL API it provides is fully compatible with that of SQLite. As a result, you can make your SQLite applications use Berkeley DB as the underlying storage engine without having to re-write them. All you need to do is link them to a suitable version of the Berkeley DB library. This combination of SQLite and Berkeley DB has been reported to perform better in case of highly concurrent, write-intensive applications.
Berkeley DB provides API bindings for several programming languages, including C++ and Java, and has been compiled, run and tested on several operating systems, including Android and iOS. Nevertheless, you might be put off by its AGPL license, in case you want to use it in your application, but you do not want to distribute your own source code in exchange.
Note also that, mainly because of its effort to provide features that are expected in traditional client/server databases, Berkeley DB is considered as a relatively heavyweight solution. So, unless you absolutely want a feature that is only offered by Berkeley DB, then there are other more lightweight alternatives you can choose from.
Update: Even though Berkeley DB technically supports iOS, it can’t be used in App Store apps due to license incompatibility with App Store terms & conditions.
Couchbase Lite
Couchbase Lite is a document-oriented database: data is stored as JSON documents. Each document may have one or more attachments, which are essentially uninterpreted binary data that is stored and loaded separately from the document itself. Couchbase Lite supports persistent indices (called views), and uses map-reduce to manage and query them.
Couchbase Lite, together with Couchbase Sync Gateway and Couchbase Server, are the three components of the NoSQL JSON mobile database solution offered by Couchbase called Couchbase Mobile. One of the key features of Couchbase Mobile is built-in synchronization (through Couchbase Sync Gateway) between local databases (Couchbase Lite) and databases in the cloud (Couchbase Server), which relieves the developer from the burden of writing their own sync code. In order to support this feature, Couchbase Lite comes with a conflict resolution mechanism that is quite similar to the one used by Git.
Couchbase Lite provides a Native API for both Android and iOS, as well as plug-ins for two widely used cross-platform tools for mobile development: PhoneGap and Xamarin.
LevelDB
LevelDB is an open-source library (written at Google) that implements a key-value store, where keys and values are byte arrays, and data is stored ordered by key (based on some, probably custom, comparison function). LevelDB supports atomic batch updates, forward and backward iteration over the contents of the store, snapshots (i.e. consistent read-only views of the entire store), caching, data integrity (using checksums), and automatic data compression (using the Snappy compression library). An important limitation imposed by the library is that at any moment at most one process can have access to a specific database.
“LevelDB has good performance across a wide variety of workloads” state its authors, and here are the results of a benchmark they put together to prove their claim by comparing LevelDB with SQLite and Kyoto Cabinet (another key-value store implementation).
LevelDB is written in C++. iOS developers can use it directly in their applications or through one of the several Objective-C wrappers that are available for it. Android developers can use LevelDB via JNI and NDK.
SQLite
SQLite is an open-source C library for managing relational databases that can be stored both on disk and in memory. It supports dynamic typing (types are assigned to values, rather than to columns), transactions, full-text search, single-writer/multiple-reader access, efficient range queries (useful when storing geographical data), and shared caching (across connections opened by a single thread to the same database).
SQLite stores each database as a single disk file in a cross-platform format. This implies that you can create an SQLite database on one machine and then use it on another machine with an entirely different architecture by simply copying the corresponding file.
The authors of SQLite believe that it is “the most widely deployed SQL database”. Bindings for SQLite are available in most mainstream programming languages. SQLite is also included in both iPhone and Android operating systems.
UnQLite
There are a lot of people that incorrectly believe that UnQLite is the NoSQL counterpart of SQLite, although the two products are completely independent. UnQLite is an open-source database that exposes both a key-value and a document store interface. It supports both in-memory and on-disk databases, transactions, multiple concurrent readers, and cursors for linear traversal. Like SQLite, UnQLite uses a cross-platform file format, and stores each database in a single file on disk.
No matter which store interface you use, UnQLite’s storage engine works with key-value pairs. A distinctive feature of UnQLite is that you can change at run-time the storage engine that is used. At the moment, UnQLite comes with two built-in storage engines, one for on-disk and one for in-memory databases.
UnQLite is written in C, and can thus be used in both iOS and Android applications (in the latter, through JNI).
Our Developer Economics Survey is now live. Have your say, shape the future of mobile development and win amazing prizes and gear. Start now.
