In the previous post I discussed WHY would you like to use NoSQL database on Android. Now it’s time to discuss what possibilities there are for Android platform.

When talking about key-value storage, what Android Developer website suggests? SharedPreferences of course! I can’t omit this topic, because it’s actually not a bad idea.

Theoretically SharedPreferences don’t have a limit - they can contain the longest possible String in Java. BUT in practice - they are saved as XML files, so they are not efficient for bigger values. And as the whole file is read to memory, it’s memory that might limit you first. User „mani” from StackOverflow reports that he/she got memory exception when data saved in SharedPrefs exceeded 1428.51 kB which sounds reasonable.

In short - SharedPreferences can be totally used as basic storage, as long as stored data is relatively small. And easy to compact to basic data type such as String.

But let’s get to NoSQL libraries. Of course this list does not contain ALL possibilities, but should contain most libraries you could ever find looking for NoSQL on Android. Some evaluations are very superficial, because testing or reading into every library would be tedious and - to some extent - pointless. If there is some red flag, I just give up on this choice. There are so many possibilities that we can be pretty selective.

Your Android options for NoSQL:

  • WaspDB - not very popular but actually pretty simple, getting-job-done library. Uses Kryo for serialization, so there is no need for changes in model! Also supports encryption which is always a good thing. The only issue: it wasn’t updated since November 2016, but for such small library that might not be a bad sign - possibly it’s so simple that it just works without any fixes.
  • MapDB - very popular, written in Kotlin and wide range of functionalities. Maybe a bit too wide, but seems great for some specific applications. Very good performance. Guava as dependency is not terrible but pretty big dependency for mobile project. Impressive test suite. But… “It is now Java8 based. Java6 is still possible, but I see no reason. 95% of my customers are on Java8 and Android will support Java 8 soon.”
  • SimpleNoSQL - pretty popular, but it’s a bit weird to see in four years old project version 0.5.1. Also in Readme: “This project is still very new and under active development. The API is in a wildly fluctuating state”. So not worth the risk.
  • Nitrite - fresh project with unusual features: Kotlin extensions, its own data explorer (cool!), data replication, indices. So it’s pretty close to “normal” NoSQL, not just key-value store. Looks really interesting - for my personal use case is just too complicated, but I’ll observe this project, it has potential.
  • Couchbase-lite - Couchbase is respectable solution on server-side and its mobile counterpart is professional project, even though currently version 2.0 is still in beta phase. There is support for synchronization with server database and support for database views. If you have Couchbase on server and needs synchronization this might be no-brainer. Big drawback - you have to transform every model into key-value pairs manually, no automatic serialization. With so many features, it’s disappointing.
  • ForestDB - pretty popular, coming from authors of Couchbase-lite, unfortunately - as per this comment - “ForestDB is not under active development at the moment”. That’s a no.
  • Noodle - relatively unknown, but has every base covered. I really like how it solves the problem of object’s key in storage - field can be annotated, but also can be defined dynamically when storing, so it doesn’t influence model. It uses Gson by default, can be encrypted pretty easily and supports RxJava. Basic and simple, so great!
  • Paper - very popular, very cool. Simple library, the whole source code is several files, uses Kryo for serialization, works fast. There is also RxJava wrapper available. It’s based on assumption that “Datasets on mobile devices are small and usually don’t have relations in between” which is pretty good assumption. It’s key-value storage with possibility to store some keys in common place (called “book”). I don’t see any major drawback, but probably for some application Paper would be not enough functionality-rich.
  • Android-NoSql - appealing idea of creating structured data trees. For some use cases that might be just perfect. Unfortunately not very supported, looking at git history and how issues are handled. Interestingly, how it stores data might be substituted and there are available implementations for SharedPreferences and (already mentioned) Paper
  • Hawk - VERY popular. Simple key-value with support for encryption. Easy to use and - what’s really cool - easy to provide your own implementation for every step of storing data: encryption, serializing, storage etc. It probably would be my go-to solution, but with current number of issues of 77 - most without responses… Nope. Abandoned project.
  • Iron - this one is quick. Build is failing, it’s two years old and it didn’t even reach version 1.0. Next.
  • Firebase Database - elephant in the room. Probably should be placed at the top as “official” NoSQL solution on Android. But it’s not that simple - Firebase Database is great when you need something synched with the cloud. Then this is probably the best way. But otherwise? It seems like an overkill for simple storage. It has cool NoSQL-type tree structure (similar to Android-NoSql) and it writes data as JSON. There is a lot more to it, but official documentation is good, so I will not go into details.

Hopefully this list can help you when you need to choose right NoSQL library.

TL;DR

Noodle and Paper are cool, Nitrite might suit your use case and if you need synchronization with cloud, probably Firebase Database is your best bet.