JSONDB – NoSQL DB for your mobile apps!

Transparent gear shapes

Editor’s Note: This was re-blogged with permission from IRL Gaming.

If you’ve spent any time building data driven applications on the Titanium Appcelerator platform you’ve probably had to deal with SQLite.

SQL databases (and particularly SQLite) are a great solution, but they can become a real pain when you’re prototyping or rapidly iterating the design of your application. Maintaining complicated databases schemas, figuring out indexes, and writing ugly embedded SQL queries can really slow down the pace your team works at and make your code difficult to maintain.

During the development of Zombie Hood this became a major issue for us as a team. SQLite proved to be unsuitable for a number of reasons:

  • It was slow and difficult to constantly modify, re-index and deploy a new schema every time we changed the application or added a new feature
  • Migrating data between versions of the app became very difficult
  • Our data wasn’t secure – users with jail broken phones could basically change whatever they wanted whenever they wanted (and they did)
  • Translating between tabular data and objects in JavaScript turned out to be fairly inefficient even with our own custom ORM libraries
  • Moving data between our MongoDB driven API and our SQLite driven application was clunky and error prone
  • Maintaining large embedded SQL queries turned out to be a maintenance nightmare in JavaScript

After version 1.2 of the app went live it became clear that SQLite was a bad fit for us. After researching better solutions we finally decided to build our own NoSQL data management solution. It works great, we love it, and now it’s available on the Open Mobile Marketplace for iOS developers.

Checkout this screencast to see the module in action:


If you’re comfortable working with JSON, and you’ve had a quick look at MongoDB then you’re already up to speed on how this module works. We designed the system from the ground up to be:

  • Secure – all data committed to and read from disk is signed so that it can’t be tampered with by users
  • File Based – we didn’t want to run a server on the handset, so all data committed to storage is encoded as JSON and stored in flat files. This also means that all your data is portable
  • MongoDB Compatible – we constantly shift data between our API and the user’s handset so JSONDB generates unique BSON Object Ids and MongoDate objects in accordance with the specification.
  • Flexible – JSONDB had to allow us to combine query expressions, conditional expressions and mutation expressions in any order. We also implemented the DBRef spec to allow references to objects between collections along with dynamic object reference resolution.
  • Single Context – single execution context apps are the only way to go in Appcelerator, so while JSONDB isn’t thread safe it runs in the same execution context as the app. This makes it lightning fast to perform queries and updates.
  • Light Weight – the entire NoSQL engine comes in at 600 lines of JavaScript code
  • Simple – we wanted to get rid of ugly SQL queries and make everything object based, very similar to the way MongoDBqueries work
  • Easy – no schema, no indexes, no complicated SQL. Just objects. That’s how JavaScript should be.
  • Geo-spatial Query Support – we needed to be able to perform geo-spatial queries on our data-set on the handset

So, let’s imagine an application where the user can add contacts to an address book, along with cartesian coordinates so that the records can be displayed on a map. A contact record might have a nickname, a full name, an email address, a phone number, and an address. We’ll also include some cartesian coordinates.

We could create a contacts collection and add a record as follows:

This creates a new contacts collection (or loads an existing one), creates a new record and commits it to storage. You would plug this into your contact management GUI so users can add contacts. Let’s imagine that your user has added a couple of hundred contacts to their collection and want to search through them to find John Smith based on his name:

This will return the first object with a name property matching “smith” ordered by creation date from oldest to newest. This is a pretty simple example, so what if the user wanted to retrieve a list of all contacts near them within a 1km radius ordered by nickname alphabetically?

Another example might be the user wanting to update all of John Smith’s records to set the phone number to 9090909 if the records were added less than a week ago:

Finally, if the user wanted to remove all records from their contact list that didn’t have phone numbers:

These are really just a few very simple examples of just how powerful this module is. If you’d like to know more check out theproduct page on the Open Mobile Marketplace or drop us a line at ohlo@irlgaming.net.


  1. My collection commits work, but when I try and display any data via the DEBUG I get nothing?

    It just stops dead in its tracks:

    [INFO] (

  2. @Marco – check out our product FAQ for answers to your questions about performance (http://bit.ly/v0OOvV)

    @Shealan – check my response on twitter. It looks like the new version of Titanium Studio is truncating console output when it encounters newline characters. For a quick fix use:


  3. I’m currently looking at implementing a glossary application which currently exists as a website with a MySQL backend as a mobile app.

    We have just under 4000 records consisting of terms and definitions with the definitions containing hyperlinks to other terms.

    The usage is mainly searching for words and phrases and displaying relevant lists of terms.

    We are thinking of targeting a minimum spec device of iPhone 3Gs.

    Do you think the JSONDB library would be an appropriate choice for an app with this many records?



  4. Hey Bill,

    It’s tough for me to answer your question accurately without knowing more about the design of your application.

    To be perfectly honest I think 4000 records might be pushing the limits of what the iPhone 3Gs can handle in terms of memory when using JSONDB (depending on the size of the definitions for your terms and complexity of the way you want to query the data).

    Technically I would probably structure the objects for the collection as follows:

    “definition:”here is a definition for foo, a related term is {$id:bsonobjectidgoeshere, term:bar}”,
    “links”: {
    “bar”: { $ref:”terms”, $id:”bsonobjectidgoeshere”},
    “oof”: { $ref:”terms”, $id:”bsonobjectidgoeshere”}

    The data between braces within the definition string would be parsed by your application and a “link” to the relevant term would be inserted.

    Drop me a line at dan [at] irlgaming [dot] net and we can chat about your requirements and see if JSONDB is a good fit.

  5. Hi all,

    This may be a stupid question but can i send my app to the app store with data already loaded into the database or do i have to load it when the user first opens the app. If it’s possible to ship with the data loaded how do you do this?


  6. Hey James – you can ship JSONDB collections with your app and copy them to the location you want to use them from the first time you boot the app. Alternatively you can write some code to insert whatever data you need from JSON/CSV/web services the first time the app is booted. Our flagship app, Zombie Hood, uses the second approach.

  7. I really like this. Is it actively supported?

    How hard is it to sync with an upstream nosql solution ?

  8. @Jonas – it should be, depending on where you choose to store your collection data on the handset

    @Michael – Yup, it is actively supported. You can sync with the MongoLab REST API out of the box, or roll your own connector.

Comments are closed.