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.


  • 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.


  • 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:

  • greenDAO: robust (around since 2011), the fastest ORM
  • DbFlow: feature rich
  • ORMLite: the very first ORM on Android, in decline lately (no new versions released, slowish)
  • Requery: quite new, still in beta, RX support
  • Older ORMs like SugarORM, ActiveAndroid, etc. are not really common nor recommended anymore.

In comparison to plain SQLite, the audience pointed out the following traits.


  • Getting rid of boilerplate code
  • Not reinventing the wheel (ORM is a tool doing much of the work already)
  • Compile time checks (Java APIs)
  • No SQL required (but you usually can use it along the ORM)


  • Another lib you have to learn
  • Potentially performance decrease (depends on the ORM)


~ 4% of the audience tried out Realm. Realm is an alternative mobile database (no SQL/SQLite involved), which is shipped inside your app’s APK.


  • 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).


  • 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.


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.


Spread the love
Posted in Android and tagged , , , , , , , , .