While starting a new application, we often wonder which database to use, especially if the application is database intensive. Recently I came across Realm, which is really well-built and surprisingly very fast compared to SQLite. In this post, I aim at showing how Realm compares to SQLite.
Let’s start with looking at basic CRUD operations in Realm.
Now let’s look at the comparison between Realm and SQLite.
Realm does not use SQLite as its engine, rather it is a database built from scratch to run directly on phones, tablets and wearables. Realm is an object oriented database that uses C++ as its core. However, SQLite uses a transactional SQL database engine.
2. Easy to Use
Realm is easy to use as it uses objects for storing data. Realm data models are defined using normal Java classes that are a subclass of RealmObject. This class can define properties of primary keys, required fields etc. using simple annotations. Also, there is no requirement for converting the Realm query results into objects for further use, this conversion is handled automatically by Realm. Realm query results are returned in a generic RealmResults instance which is a collection of the model class. This RealmResults instance is iterable like a List. However, the SQLite query results are returned in a Cursor object.
3. Cross Platform
Realm stores its data in a native object format where the objects are stored in a universal table-based format using C++ as its core, rather than storing them as is in their language specific format. This makes Realm easy to use across multiple languages, platforms and queries.
Realm performance is faster than SQLite, almost 10x faster according to the benchmark results. An example of this is- data fetched by Realm queries have a better performance enhancement than the insert queries as compared to SQLite.
The data in Realm is never copied, it works on live objects. Using Realm queries, we get a list of object references thereby working on the original Realm data. Thus, any changes made to the queried data is reflected in the actual stored data as well after a simple commit. However, in SQLite, we get a copy of the data from the database through a query. Thus, using SQLite, any changes made on the queried data need to be persisted by writing them back to the database again.
Companies using Realm:
A few companies using Realm are Amazon, Google, Starbucks, Intel, Ebay, Adidas, Zynga, Nike, IBM, and CISCO.
Realm currently has a few limitations:
- Realm does not have support for auto-incrementing ID’s and composite keys.
- In order to maintain a balance between flexibility and performance, Realm imposes a certain limitations on various aspects of storing information in a Realm which include:
- The upper limit on the name of a class is 57 characters, which includes the _class prefix.
- The field names have an upper limit of 63 characters.
- There is no support for nested transactions.
- String and byte arrays cannot be greater than 16 MB.
- There is no support for final, transient, and volatile variables.
- Realm model classes can only extend the Realm object.
- Realm model class must include the default empty constructor.
- There is currently support for only ‘Latin Basic’, ‘Latin Supplement’, ‘Latin Extended A’, and ‘Latin Extended B’ (UTF-8 range 0-591) in sorting and case-insensitive string matches. Further, setting the case insensitive flag in queries when using equalTo(), contains(), endsWith() or beginsWith() will only work on characters from the English locale.
- Although Realm files can be handled concurrently by multiple threads, we cannot hand over Realms, Realm objects, queries, and results between threads.
- Realm files cannot be accessed by concurrent processes, they can only be accessed by one process at a time. Different processes should either copy Realm files or create their own.
- RealmObject are live objects, and might be updated by changes from other threads. Although two Realm objects returning true for RealmObject.equals() must have the same value for RealmObject.hashCode(), the value is not stable, and should neither be used as a key in HashMap nor saved in HashSet.
I hope this post was helpful in letting you decide which database to use for your next application.