SQLite, ORMs, NoSQL: what Android developers use and why

At yesterday’s Droidcon Berlin barcamp, we compared different database approaches (SQLite, ORMs, NoSQL). In our interactive session we asked about 80 developers how they use databases on Android and what advantages and disadvantages they see in each approach. Here are the gathered results:

Plain SQLite

~40% of the participants have used SQLite without additional tools.Advantages

Toolchain, e.g. DB browser

No dependencies

Developers can define exactly the data schema they want

Developers have full control, e.g. handwritten SQL queries

Debuggable data: developers can grab the database file and analyse it

Easy to write ContentProviders to use with Loaders (although writing ContentProviders is a rather special case for sharing data, which is not required for most cases). Side note by Markus: writing Loaders for plain SQLite is easy.

Disadvantages

A lot of boilerplate code

Reinventing the wheel (tools do the work already)

ContentProviders are another layer (again, you don’t have to use them, it’s still a somewhat confusing topic)

No compile time checks (e.g. SQL queries)

Manual schema updates (maintenance, migration scripts)

SQL is another language

SQL queries can get loooooong

Testability (how to mock a database?)

ORMs (Object/Relational Mappers)

~10% of the participants have used an ORM before. Because ORMs were not widely known among the participants, Markus gave a brief intro: an ORM is a layer between the database (SQLite) and the Java world. It lets developers work with Java objects (data objects aka entities, and data access objects aka DAOs). ORMs do most of the SQL part for the developer, while typically also allowing raw SQL queries if required.

Being asked about which ORMs are around, Markus and the audience gathered a couple of popular ORMs:

Realm

Direct interaction with objects; it is not an ORM on top of SQLite (although its Java layer looks pretty much like an ORM to its own native database)

RX support

Good docs and tools

To complete the picture, one could add that Realm may have performance advantages in certain areas (e.g. queries, especially when not reading the properties of returned RealmObjects).

Disadvantages

The performance is often en par and sometimes worse when compared to SQLite/ORM solutions. In general, do not blindly trust any benchmark. Check what it measures – and what it does not (is the benchmark open source?). If you have the time, do your own benchmark with a scenario that is important to your app.

No powerful query language like SQL

You have to ship an additional database binary with your app (for each CPU architecture) which will grow your APK size

It would have been interesting to discuss whether Realm delivers enough to justify dropping SQLite as a underlying database – especially when you can achieve comparable results with an ORM. But time was up.

NoSQL, Others

Only ~1-2% of the participants tried alternative approaches like Firebase. In general, mobile NoSQL approaches were not well known.

Summary

There is no commonly used silver bullet for persistence on Android. Using plain SQLite still seems to be the most popular approach, while it comes with a lot of boilerplate code. ORMs do most of the boilerplate code for the developer in the background. However, ORMs are lesser known among Android developers and require learning a new APIs. At greenrobot, we are convinced that using an ORM pays out quickly. Building your first data objects (entities) is usually done within minutes and quickly saves developers hundreds of lines of code. If you want to learn more about the fastest and easiest way to access SQLite, we invite you to check out greenDAO and its documentation. Also consider signing up to our newsletter: we’re working on something really awesome.