Flutter databases –  sqflite, hive, ObjectBox, and Moor

Flutter databases – sqflite, hive, ObjectBox, and Moor

Flutter is becoming a serious developer platform and with it grows a need for Flutter databases. A quick note on Flutter and Dart: As it is pretty young and you might either be looking for a Flutter database, a Dart database or truly a Flutter Dart database. Flutter is an open-source UI software development kit created by Google. Dart is the programming language in which developers code Flutter apps. Dart is an object-oriented programming language. 

Flutter databases / Flutter Dart data persistence

While the database market is huge and dynamic,  there are only few options to choose from if you are a Flutter / Dart app developer. Before we dive into the Flutter database options, advantages and disadvantages, we’re taking a very quick look at databases to make sure, we share a common ground. Accordingly, we’ll not get theoretical and extensive, but focus on what we mean here. 

What is a database?

A database is a piece of software that allows the storage and systematic use of digital information, in other words: data persistence. As opposed to mere caching, data is reliably stored and available to work with unless actively deleted. A database typically allows developers to store, access, search, update, query, and otherwise manipulate data in the database via a developer language or API. These types of operations are done within an application, in the background, typically hidden from end users. Many applications need a database as part of their technology stack. The most typical database operations are CRUD: Create, Read, Update, Delete.

What are the major types of databases?

There are many types of databases. For our purpose, the most important differentiations are non-relational (NoSQL) versus relational databases (SQL), cloud databases versus edge databases, and maybe embedded versus in-memory. However, databases can be further distinguished by additional criteria e.g. the data types they support, or the way they scale – and definitions can vary.

What is an ORM?

An Object relational Mapper (ORM) is not a database. We’re bringing this up mainly, because we see it confused often. It is a layer that sits on top of a database and makes it easier to use. This is typically especially relevant when the database is a relational database (SQL) and the programming language used is object-oriented. As noted above, Dart is an object-oriuented programming language.

The Flutter Dart data persistence landscape

At this point in time, the database landscape for Flutter Dart is still very limited. So, let us quickly introduce the current market players. Note: We are adding in Moor, because with that few player it is just one more option available and therefore, at this moment in time, should be part of the Flutter Dart data persistence landscapes, in our minds.

  • Firebase Realtime DB is a cloud-hosted database. It stores data as JSON and synchronizes it to connected clients.
  • Hive is a lightweight key-value database written in Dart for Flutter applications, inspired by Bitcask.
  • ObjectBox DB is a highly performant lightweight NoSQL database. It stores objects.
  • sqflite is a wrapper around SQLite, which is a relational database without direct support for Dart objects. 
  • Moor is a reactive persistence library for Flutter and Dart, built ontop of sqlite. 

 

What is the best Flutter Dart database?

This of course depends… Make up your own mind with the following comparison matrix as a starting point. Note: With very few options to choose from, the following overview is sometimes a bit comparing apples🍎 and pears🍐.

 

Data persistence Description Primary Model Location of data Language License Fun Fact
Firebase Realtime Database Mobile Backend as a Service (MBaaS) NoSQL Google Cloud Dart Proprietary acquired by Google in 2014
hive Light key-value DB for Flutter NoSQL local Dart Apache 2.0 Munich brew
ObjectBox High-performance Flutter DB NoSQL local, self-hosted server / cloud Dart Bindings are Apache 2.0 Munich-brew out-of-the-box data sync solution
sqflite SQLite plugin for Flutter relational local SQL SQLite is public domain, sqflite lib is MIT good old SQLite
Moor ORM for SQLite used on top of a relational DB local Dart SQLite is public domain, Moor lib is MIT Room spelled backwards

 

<body> <p>Diese Seite verwendet Frames. Frames werden von Ihrem Browser aber nicht unterstützt.</p> </body>

Flutter Database performance benchmarks

As with any benchmark, you need to take a look at the details. We take benchmarking very serious and strive to get accurate results. Therefore, we also always open source the benchmarking code and encourage you to check it out. If you note anything that does not even out in your oppinion, do let us know. We have a long history of updating and improving our benchmarks continually and are happy to take any recommendations.

Performance Benchmark Test Setup

We used an Android 10 device with a Kirin 980 CPU to run the benchmarks as a Flutter app. The app executed all operations (ops) in batches of 10.000 objects. Each batch formed a single transaction. We ran each test 50 times. The results you see in the diagram are averages across all runs. We set it up that way to ensure that neither the Virtual Machine warmup during the first run nor the garbage collections affect the overall result significantly. 

Flutter Databases CRUD Performance Results

Flutter Database Performance Benchmarks

Summary of the Flutter Dart DB Benchmarks

Hive and ObjectBox clearly outperform sqflite across all CRUD operations. The results show ObjectBox performing with up to 70 times the speedup for create and update operations. With regards to comparing Hive and ObjectBox, the results vary more. Hive can be faster at reading objects than ObjectBox. However, strictly speaking it’s not a fair comparison, because in Hive, the high read numbers result from Dart objects already cached in memory. If the objects are fetched using the async API from disk, the numbers drop by factor 1000.

As a cloud-based online database, Firebase is not really comparable. Local data persistence, an edge database, will typically always beat a cloud-based solutions with regards to response times. But of course cloud-based solutions have their own advantages and there may be reasons why you would choose to use Firebase over an edge database. It still may be a great option for you, depending on the use case.

Moor was not part of the benchmarking as it is an ORM. However, it is very likely it will perform similarly as sqflite, reflecting primarily the performance of SQLite.

Flutter and Data persistence landscape Conclusion

Flutter is becoming a serious developer platform and developers need a data persistence solution. There are currently only few databases supporting the Flutter community and 2021 will be an interesting year to watch where this is going. If you are interested to learn more about the database space, DB-engines and the database of databases are great starting points. Otherwise, go, check out ObjectBox Dart for Flutter Dart and share your thoughts with us – it’s not too late yet; we are shortly before releasing 1.0 and your feedback counts 🙂

Firebase, Firebase alternatives – a look at data sync solutions

Firebase, Firebase alternatives – a look at data sync solutions

Data Sync is one of the typical challenges a developer faces. Synchronizing data is not easy and while JSON / REST are great, building data sync yourself is challenging. Therefore, today, we take a look at the out-of-the-box data sync market. If you are rather interested learning about data sync in general, check out this article about why data sync technology is more necessary than ever.

As Firebase is one of the most well-known data sync solutions, we look at the market from a Firebase alternatives perspective. However, Firebase is purely cloud based and offers no support for local data storage and offline usage. With a huge shift happening in computing from the cloud to the edge, offline-first approaches and Edge Computing are getting more and more important. Reasons to move to the edge, include: Data Speed, Data Privacy/Security, Broadband Limitations, Network Costs, Cloud Costs, and User Experience. Therefore, we’ve recently taken a comprehensive look at mobile database and edge database offerings on the market, but what options do Mobile and IoT developers working on the edge have for out-of-the-box data synchronization solutions? Very few. As there is no lack of cloud-based offerings, we focus on the most prominent cloud services only, and add all edge / offline sync solutions, we are aware of, to our comprehensive comparison of data sync solutions. 

Firebase

Firebase is a cloud backend service ((Mobile) Backend as a Service ((M)BaaS)) that enables developers to build mobile or web applications without needing to take care of the backend, which includes the data synchronization, scalability, network, infrastructure challenges etc. Firebase, today, offers many different services (e.g. analytics, crashlytics) and goes well beyond sync; we are looking at Firebase from the sync perspective only. Firebase was one of the first data sync solutions available on the market together with Parse and Couchbase, which all started in 2011 (Couchbase through a merger of CouchOne and Membase). In 2014, Firebase was acquired by Google, Parse was acquired by Facebook to be subsequently shut down, and Couchbase went on to raise funding. All three are still in use today. 

Firebase Pros and Cons

In the following, we will look at the advantages and disadvantages of Firebase, and then compare Firebase with Firebase alternatives, like Couchbase, Parse and ObjectBox in a comprehensive matrix to give you a good overview of data sync options. 

Firebase Advantages ++ Firebase Disadvantages —
Cloud based Purely cloud based
Google: large team that supports and maintains it; very low risk of the company failing; however, Google has a reputation of discontinuing products / services, so there is no guarantee Google: vendor lock-in (no migration tools prevents you from making your app portable), you cannot access your data as it is hosted on the Firebase server
Backend as a service (ease of use) Less flexibility: You cannot optimize the backend to match your app’s needs

The Firebase Realtime Database has its own advantages:

  • hosted, powered by Google
  • for pure online use cases rather fast
  • great if you do not have a strong DB background

The Firebase Realtime Database has its own drawbacks:

  • the whole DB is a huge JSON file
  • limited querying capabilities
  • no way to efficiently filter data
  • Easily disorganized, hard to navigate and search
Pay as you go, price scales with usage Cost insecurities, hard to impossible to predict
Less iOS support (stronger focus on Android) Less iOS support (stronger focus on Android)
Doesn’t work in countries that don’t allow Google
User privacy concerns***

 

*** “Firebase has been claimed to be used by Google to track users without their knowledge. On July 14, 2020, a lawsuit was filed accusing Google of (…) logging what the users are looking at in many types of apps, despite the user following Google’s own instructions to turn off the web and app activity collected by the company.” (https://en.wikipedia.org/wiki/Firebase)anced settings.

Firebase Advantages ++ 

Cloud based
– Google: large team that supports and maintains it; very low risk of the company failing; however, Google has a reputation of discontinuing products / services, so there is no guarantee
– Backend as a service (ease of use)
– The Firebase Real-time Database has its own advantages:
– Pay as you go, price scales with usage
– Less iOS support (stronger focus on Android)

Firebase Disadvantages —

– Purely cloud based
Google: vendor lock-in (no migration tools prevents you from making your app portable), you cannot access your data as it is hosted on the Firebase server
– Less flexibility: You cannot optimize the backend to match your app’s needs
The Firebase Real-time Database has its own drawbacks
    –
the whole DB is a huge JSON file
    –
limited querying capabilities
    –
no way to efficiently filter data
    –
Easily disorganized, hard to navigate and search
– Cost insecurities, hard – impossible to predict
– Less iOS support (stronger focus on Android)
– Doesn’t work in the countries that don’t allow Google
User privacy concerns: “Firebase has been claimed to be used by Google to track users without their knowledge. On July 14, 2020, a lawsuit was filed accusing Google of (…) logging what the users are looking at in many types of apps, despite the user following Google’s own instructions to turn off the web and app activity collected by the company.” (https://en.wikipedia.org/wiki/Firebase)

Firebase alternatives: A look at out-of-the-box data sync solutions

The majority of offerings for developers that handle data synchronisation as defined here, are cloud-based and fall into the category of BaaS (can also be MBaaS (Mobile Backend as a Service) or PaaS (platform as a Service) or DBaaS (Database as a Service). Typically that measn that data synchronisation is only a small part of the offering. However, that is our sole focus here.

Data Sync Solution comparison matrix – Firebase and its alternatives

Solution name Company Category Data Sync IoT / Mobile Database Type of DB Cloud OS / Platforms Languages License
Cloudant Sync IBM (Cloudant was acquired in 2014) DBaaS
(Cloud DB and Cloud Sync)
Two-way
cloud data replication (called “sync”)
IoT
& Mobile
Cloud
database based on Couch DB
NoSQL;
distributed JSON document database
Cloud-based
replication to and from on-device data (CouchDB <> cloud service)
hosted
service
C#,
Java, JavaScript, Objective-C, PHP, Ruby
Proprietary
(CouchDB is Apache 2.0 and they integrate with several open source libraries)
Couchbase server and Couchbase Sync Gateway Couchbase (a merger of Couch One and Membase) Cloud
DB and Cloud Sync
Sync
needs a Couchbase Server
IoT
& Mobile
Edge:
Couchbase Lite; Server: Couchbase
NoSQL;
document database
Always
needs Couchbase Server (originally Membase)
mainly
used as hosted service;
iOS, Android, .NET (Desktop/Server), .NET UWP, Xamarin
Swift,
Objective-C, Java (Android), Java (Non-Android), Kotlin, C#, JavaScript, C
Apache
2.0, delayed open source
Firebase** Google (Firebase was acquired by Google in 2014) BaaS
(Cloud)
Cloud
Sync via Google servers
Mobile Cloud:
Firebase Realtime Database; Edge: Caching only (Firestore)
Document
store
hosted
only
APIS
for iOS & Android
JavaScript API
RESTful HTTP API
Java
JavaScript
Objective-C
proprietory
Mongo Realm Sync MongoDB
(Realm was acquired in 2019)
Cloud
DB and Cloud Sync
Sync
(in Alpha); only via Mongo Cloud
IoT
& Mobile
Cloud:
MongoDB, Edge: Mongo Realm
MongoDB:
NoSQL document store; RealmDB: Embedded NoSQL DB
hosted
service
MongoDB:
Linux, OS X, Solaris, Windows
Mongo Realm DB:
Android, iOS
20+
languages, e.g. Java, C, C#, C++
Mongo
DB changed its license from open source (GNU) to MongoDB Inc.’s Server Side
Public License (SSPL) in 2018.
ObjectBox
Sync
ObjectBox DB
and Sync

Offline
Sync, on-premise Sync, Cloud Sync

p2p Sync is planned

IoT
& Mobile
ObjectBox Object-oriented
embedded NoSQL DB
Self-hosted
/ on-premise; hosted service upon request only
iOS,
Android, Linux, Windows, MacOS, any POSIX-system
C,
C++
Java
Kotlin
Swift
Go
Flutter / Dart
Python
DB:
Open source bindings, Apache 2.0, proprietary core
Parse Originally
Parse, acquired by Facebook, closed down and open sourced, unmaintained
MBaaS
(Cloud)
Cloud
Sync, self-hosted or via a provider that offers Parse hosting
Mobile Both,
PostgreSQL* and MongoDB, can be used as a database for Parse
MongoDB:
NoSQL document store; PostgreSQL:
Only
Cloud, only self-hosted or via a provider that offers Parse hosting
Server: REST
API lets you interact with Parse Server from anything that can send an HTTP
request
open
source, BSD
Syncstudio HandApps Cloud-based
sync between SQLite and MS SQL Server based in the MS Sync Framework
Sync Mobile Edge:
SQLite or MSSQL (including LocalDB or Express); Server:
Microsoft SQL
relational
/ SQL
SQL
Server; Sync / replication works via cloud only
Android
Java, Basic4Android, Windows Forms, UWP, Windows Mobile, Xamarin
proprietory,
4 licenses available: Community/Free, Subscription, Perpetual and Royalty
Free
Zumero Zumero
LLC
Cloud-based
replication of SQL data for Mobile
Sync Mobile Edge:
SQLite; Server: Microsoft SQL
relational
/ SQL
SQL
Server; Sync / replication works via cloud only
Mobile
only (iOS, Android, Xamarin, PhoneGap)

proprietory,
annual license scaling with the number of devices

 

 

 

 

Notes: Microsoft Sync Framework (renamed Sync Framework Toolkit at some point) is a legacy open source product which MS no longer supports

* PostgreSQL vs Postgres
** There are many Cloud Sync alternatives to Firebase, we added the more prominent options and any service that also serves Edge Computing

Data Sync is no standardized term and though it seems to be in use by many big companies and most dvelopers will have a notion of what it is, the devil is in the details. So, we might have missed an important solution or taken an angle someone else would not agree with. Please feel free to let us know what to improve.

ObjectBox DB and Sync – designed to keep data up to date across time and space

ObjectBox is a high performance NoSQL fully ACID-compliant edge database built from scratch for efficient data on and across restricted and occasionally connected devices, taking care of keeping data in sync reliably. ObjectBox developer tools are easy to use, quick to implement, and optimized for high-performance and frugal resource-use on edge devices running mobile, desktop, server, and IoT applications. ObjectBox helps developers to focus on what they love and build great applications without needing to take care of the boilerplate code for resilient connectivity, synchronizing data, and tedious DB optimizations. This cuts down initial implementation efforts, ongoing maintenance efforts, undesired problems, and data loss – therefore reducing costs and time to market tremendously. We are dedicated to bring joy and delight to Mobile and IoT application developers.

Edge Database Comparison: SQLite and SQLite alternatives

Edge Database Comparison: SQLite and SQLite alternatives

SQLite and SQLite alternatives - databases for the Mobile and IoT edge

Updated comparison of mobile databases / edge databases

Note: This is an updated version of an earlier Mobile Database Comparison. Last Update: 2021.

According to the database of databases there are more than 700 databases as of 2021. However, that list does include hobby projects. DB-engines “only” lists databases that have significant traction and are well-maintained; they still count more than 300 databases as of 2021. However, only a handful of these databases are edge database.

What is an edge database?

An edge database is a database that runs directly on restricted devices locally. It is a local on-device database as opposed to a cloud database, resulting in significantly faster data. The term edge database is too young to have a Wikipedia article. However, we see it used in the IoT industry increasingly. In the field of IoT applications, it is especially important to distinguish databases that run locally on the device (“on the edge of the network”) and thus support Edge Computing from databases that run “in the cloud.” In our view, a mobile database is an edge database that runs on mobile devices, meaning the only difference between the terms edge database and mobile database is the operating system / device support they offer.

What is a mobile database?

While Wikipedia defines a mobile database as “Mobile computing devices (e.g., smartphones and PDAs) store and share data over a mobile network, or a database which is actually stored by the mobile device,” we solely refer to the latter ones as a mobile database. Meaning only databases that run on the mobile device (as the edge device) itself, locally, and store the data on the device. Therefore, we also refer to it as “on-device” database.

What is an edge device?

An edge device may be any device from a sensor, to an IoT gateway, to a car, to a Raspberry Pi, to a mobile phone (smartphone) to an on-premise server. Typically, the challenge arises when running on the smaller, more restricted devices. Generally, any database can run on a big on-premise server or cloud infrastructure with unlimited resources, but only few fit on a Raspberry Pi Zero. The other way around is no issue, meaning an edge databases can run well on a server. Therefore, in this comparison we look at databases that run on Raspberry Pi type size of devices (rule of thumb).

Edge Devices to run mobile /edge databases on

What are the advantages and disadvantages of working with SQLite?

SQLite is easily the most established edge database and probably the only “established” mobile database. SQLite is public domain and maintained by Richard Hipp. SQLite database has been around since the year 2000 and been embedded with iOS and Android since the beginning. SQLite is a relational database.

Advantages  Disadvantages
  • Toolchain, e.g. DB browser
  • No dependencies, is included with Android and iOS
  • Developers can define exactly the data schema they want
  • Developers have full control, e.g. handwritten SQL queries
  • SQL is a powerful and established query language, and SQLite supports most of it
  • Debuggable data: developers can grab the database file and analyze it
  • Rock-solid, widely used technology, established since the year 2000
  • Using SQLite means a lot of boilerplate code and thus inefficiencies (also in the long run with the app maintenance)
  • 1 MB BLOB Limitation on Android
  • No compile time checks (e.g. SQL queries)
  • The performance of SQLite is unreliable
  • SQL is another language to master
  • SQL queries can get long and complicated
  • Testability (how to mock a database?)
  • Especially when database views are involved, maintainability may suffer with SQLite

 

 

What are SQLite alternatives?

There are plenty of alternatives to working with SQLite directly. If you simply want to avoid writing lots of SQL and boilerplate code, you can use an object abstraction on top of SQLite. This abstraction layer is usually an ORM (object/relational mapper), e.g. greenDAO. While an ORM makes it easy to use SQLite at the beginning, there typically comes a point “where you hit SQLite”; so even when using an abstraction layer you need to understand SQLite and SQL in the longrun.

However, if you rather seek a complete replacement for SQLite, there are a few alternative databases: Couchbase Lite, Interbase, LevelDB, ObjectBox, Oracle Berkeley DB (formerly Oracle’s mobile database was “Oracle Database Lite”), Realm (now Mongo Realm), SnappyDB, SQL Anywhere, and UnQLite.

Obviously, if your also looking for alternatives that run in the cloud, there are a lot of cloud / server options out there that you can use as a replacement like e.g. Firebase. Though, with these your app will not work offline, response rates will be slower than with an on-device database and cannot be guaranteed, and last not least you will have much higher networking / cloud costs. You can find out more about the benefits of Edge Computing.

To give you an overview, we have compiled a small comparison table:

Edge Database Android / iOS* Type of data stored Sync Central Sync P2P Offline Sync Data level encryption License / business model Short description Minimum Footprint size Company
Azure SQL Edge (in preview) No Relational DB No No No will provide encryption Proprietary Designed as a SQL database for the IoT edge; however, due to the footprint it is no edge database 500 MB+ Microsoft
Couchbase Mobile (prior Couchbase Lite) Android / iOS JSON Documents / NoSQL db Yes Yes No Database encryption with SQLCipher (256-bit AES) Apache 2.0 Embedded / portable database with P2P and central synchronization (sync) support. Secure SSL. < 3,5 MB Couchbase
extremeDB iOS In-memory relational DB, hybrid persistence No No No AES encryption Proprietary Embedded relational database 200kB McObject LLC
ForestDB Android / iOS Key-value pairs / NoSQL db No No No No Apache 2.0 Portable lightweight key-value store, NoSQL database    
InterBase ToGo / IBLite Android / iOS Relational No No No 256 bit AES strength encryption Proprietary Embeddable SQL database. 400 KB Embarcadero
LevelDB Android / iOS Key-value pairs / NoSQL db No No No No New BSD Portable lightweight key-value store, NoSQL, no index support; benchmarks from 2011 have been removed unfortunately. 350kB LevelDB
Team
LiteDB Android / iOS (with Xamarin only) NoSQL document store No No No Salted AES MIT license A .Net embedded NoSQL database 350kb  
Mongo Realm (acquired in 2019) Android / iOS Object Database Yes No   Yes Proprietary with Apache 2.0 License APIs Embedded object database 5 MB+ Realm Inc
ObjectBox Android / iOS / Linux / Windows / any POSIX Object-oriented NoSQL edge database for high-performance on edge devices in Mobile and IoT Yes WIP Yes transport encryption; additional encryption upon request Apache 2.0 and Proprietary Embedded object-oriented NoSQL high-performance edge database with out-of-the-box data synchronization; fully ACID compliant; benchmarks available. < 1 MB ObjectBox
Oracle Database Lite Android / iOS Relational Yes Yes No 128-bit AES Standard encrytion Proprietary Portable with P2P and central sync support as well as support for sync with SQLite < 1 MB Oracle Corporation
redis DB No K/V in-memory store, typically used as cache No No No TLS/SSL-based encryption can be enabled for data in motion. Three clause BSD license, RSAL and Proprietary High-performance in-memory Key Value store with optional durability An empty instance uses ~ 3MB of memory. redislabs (the original author of redis left in 2020)
Snappy DB Android Key-value pairs / NoSQL db No No   No Apache 2.0 Portable lightweight key-value store, NoSQL database based on LevelDB   Nabil HACHICHA 
SQL Anywhere Android / iOS Relational Dependent No   AES-FIPS cipher encryption for full database or selected tables Proprietary Embedded / portable database with central snyc support with a stationary database   Sybase iAnywhere
SQLite embedded on iOS and Android Relational No No   No, Use SQLCipher to encrypt SQLite Public domain C programming library; probably 90% market share (very personal assumption, 2016) 500KiB Hwaci
SQL Server Compact Android / iOS Relational No No   Yes Proprietary Small-footprint embedded / portable database for Microsoft Windows mobile devices and desktops, supports synchronization with Microsoft SQL Server 2 MB Microsoft
UnQLite Android / iOS Key-value pairs / document store / NoSQL db No No     2-Clause BSD Portable lightweight embedded db; self-contained C library without dependency.   Symisc systems

If you are interested in an indication of the diffusion rate of databases and mobile databases, check out the following database popularity ranking: http://db-engines.com/en/ran.

Thanks for reading and sharing. Please let us know what you’re missing.

MoodSpace Mobile App Use Case

MoodSpace Mobile App Use Case

Ian Alexander

Co-founder, MoodSpace

We speak with Ian Alexander, founder and lead developer at MoodSpace, a beautiful app making mental health exercises accessible to everyone. MoodSpace was released in 2019, and has over 150k+ downloads. The COVID-crises highlights the importance of digital support for wellbeing and saw MoodSpace surge. After trying several databases, Ian settled on ObjectBox because of its high performance and ease of use.

Alyssa: Hi Ian, thank you so much for joining me and for using ObjectBox. Let’s start with the basics about MoodSpace and your role there.

Ian: Hi, Alyssa, thanks for having me. I’m the software developer, founder, and runner of the company – a jack of all trades. MoodSpace is an app that teaches concepts from mental health. There is a massive problem with accessibility to mental health. In the UK, for example, you have something like 1 in 4 people that have some sort of mental health problem, but only 1 in 113 go through therapy and complete it. So our essential goal is to take concepts from therapy and bring them closer to people, teaching them techniques that they can do on an ongoing basis. There’s no end date like in therapy, no waiting list, and it’s a lot easier to use it in places where you wouldn’t necessarily have access to a therapist. In the western world it is much easier to access therapy, still difficult in some ways, but much of the world doesn’t have that benefit. So that’s the goal we’re trying to reach. We started last year, we released the MoodSpace MVP in September, and now we’re going through the next stage of trying to raise our next round of funding – it’s quite exciting.

A: That’s great, congratulations! Can you tell me a bit more about your team?

I: We’re based in the UK, and in terms of the technical side, it’s just me. We also have various other roles: designer, copywriter, and another co-founder who handles much of the business side. But in terms of technical, it is just me for now. Hopefully after we get funding, we’ll be able to expand the technical team..

A: What’s your background, what did you do before MoodSpace?

I: Actually, I was originally a chemical engineer – I worked in oil & gas for a couple of years, but then I taught myself to develop and for the last 5-6 years, I’ve worked across a lot of startups, for example the dating app Once, when they were just starting up, also ITV, and then started on MoodSpace last year. Moodspace has actually existed for quite some time, it started as a hobby project of mine about 5 years ago.

Moodspace Mobile App Use Case

A: There are other mental health apps out there, what makes MoodSpace special?

I: If you look at apps in the space, they’re generally fairly small and limited – they’ll have maybe 4 or 5 exercises. Versus the realm of therapy, which has literally thousands of exercises. Any app that exists at the moment takes just a fraction of a percent of therapy and tries to teach it. Our USP is that we are a very technically minded team, and with new technologies which have come out along with our internal processes, we can make a much bigger app, building something far bigger than what currently exists, much cheaper and far faster. Our USP is strangely, less about the app, and more about our process and the technology that we use to make the app. The tech we will be using is Kotlin Multiplatform, which is a cross platform framework which lets us maintain a single codebase which enables us to build fully native apps with full access to native APIs. 

A: It sounds like the app is quite comprehensive – who is your target audience?

I: At the moment, we haven’t hit the product-market-fit stage. We’re still figuring out who the typical user is. We find that the unique art style of our app has helped our growth so far, we often find a lot of people sharing screenshots of the app on social media. So we seem to have hit a niche, but we’re still figuring out what that niche is!

A: Do you have any direct interaction with your users?

I: Mid-last year, I put a survey in the app, so after using it for a certain time users get the survey. There are some questions like who you are, why you are using it, and they gave us way more knowledge about who is using it and what they use it for, which was very helpful. Apart from that though, it is very difficult to know.

Moodspace Mobile App Use Case
Moodspace Mobile App Use Case
Moodspace Mobile App Use Case

A: Yes, it can be very challenging, we’re familiar with that struggle at ObjectBox as well. Switching gears a bit – I’d love to hear a bit more about how and why you ObjectBox.

I: As I mentioned, MoodSpace is about 5 years old, so it’s gone through several databases. One of them was really time consuming to make – it wasn’t ORM based, so you had to write a lot of stuff yourself. Then the next was an ORM called Sugar, but it stopped being developed – it was a side project by someone, so maybe I shouldn’t have used it in the first place (laughs).

I: So then we switched to ObjectBox, and actually the reason we switched was essentially to skip asynchronous code – I’ve always been a frontend developer and what I’ve come across is that asynchronous code makes things very complex, and it means app development takes much longer. Because we had a lot of time constraints and we wanted to develop as much as quickly as possible, I actually wanted to completely skip asynchronous code – which I wouldn’t recommend – but essentially ObjectBox let us do that because it’s very fast. You’d have to have a ton of data in the app, before it would visibly slow it down – and I did a lot of testing around that and it would have needed several years of data before noticeably slowing down the app. So, that was our original reason, perhaps a bit of a strange reason. And we’ve since changed the app so it’s asynchronous, so it won’t slow down any longer, no matter how much data you add in the app. Overall, I like ObjectBox a lot – it’s just simple, very easy to use.

A: What features in your app use the database?

I: Actually everything is in the app, as we don’t have a backend. So we need it to store all the data in the app.

A: Okay, sure. Keeping everything in the app is also practical from a data privacy standpoint. How did you actually find ObjectBox? 

I: It was someone I used to work with at Once – they used greenDAO and mentioned that ObjectBox (by the same people) was coming out. I looked into it a little bit and wanted to use it for a while, but it wasn’t I started developing MoodSpace again that I had a chance to. 

ObjectBox is very fast, it would have needed several years of data before noticeably slowing down the app. Overall, I like ObjectBox a lot – it’s just simple, very easy to use.

Moodspace Mobile App Use Case

A: Are there any other developer tools that you’re excited about and would want to share with the community? 

I: Yes, Kotlin Multiplatform. Having been an Android developer, having used Kotlin for quite some time and having tried cross-platform tools before, I think Kotlin Multiplatform will change the way you make cross platform apps, because it lets you share so much of the code base without sacrificing the native experience. It has the potential of leading to massive cost savings in app development. Maybe in the next year or two I can see it having a huge impact on frontend development across mobile, web, and desktop.

A: What are your big picture goals for MoodSpace? Upcoming milestones? Does ObjectBox help with those at all?

I: Actually, it potentially will, with regards to ObjectBox Sync, which is part of my plan for that app. The app right now is only available on Android, and providing we get our next round of funding, we are going to be adding iOS – where we’ll need some sort of backend. We want to avoid, again, spending much money, and one of ObjectBox Sync, Realm Cloud or Firestore can help us do that – obviously as ObjectBox Sync is nearly ready, we’d want to use that. The main point around that is cost saving because it solves a lot of problems that otherwise we would have to solve ourselves – things like offline access and syncing with an API, that would otherwise be very time intensive.

A: Ian, thank you for your time and sharing more about MoodSpace and working with ObjectBox. We wish you the best of luck with your fundraising round!

How to benchmark database performance – and ObjectBox

How to benchmark database performance – and ObjectBox

Benchmarking the performance of databases is a science in and of itself and it’s hard to get reliable and comparable results. Therefore, we decided to note down some standard patterns and pitfalls when doing database benchmarks we learned about over the years. We are including specific notes and things to consider when benchmarking ObjectBox.

database benchmark

Designing a benchmarking test

Phrase your research question

When you want to benchmark databases, you will usually have a specific use case in mind and want to answer questions regarding that case. Therefore, before writing your first line of code, have a look at what it is you want to benchmark, why, and what statement you want to be able to make at the end. Just writing down a simple question like “Is X faster than Y doing A?” can help you verify that the finished benchmark actually measures what you want it to.

Start documenting

Whatever you do, document each step diligently. Benchmarks that are not properly documented are challenging to reproduce, and thus of limited worth. So, the mantra in benchmarking really is: Document, document, document. That way it is also easier to go back later and make adjustments if needed. 

Select the sample

If you have a clear use case and goal in mind, this probably determines the type of databases you are going to consider for your benchmark. Generally speaking, benchmarks should compare databases of similar type and not mix approaches that are too different. A database might be designed to run on a cluster of servers and not, like ObjectBox, on a constrained device (e.g. a smartphone, Raspberry Pi or IoT device). Or data may be stored as documents (e.g. NoSQL) and not in a relational table-like structure (e.g. SQL); or on disk and not in-memory. Consistency guarantees can also make a difference (ACID-compliance vs. not transactionally safe). Document why you chose these databases for comparison. 

Become an expert

Once you have decided on what databases and features to compare, familiarize yourself with the APIs of the products, e.g. by reading the documentation or looking at code examples. Making wrong assumptions about how a feature works can skew your results and make a product appear much faster or slower than it actually is. If the code is open source, it can also help to dive into the code to see how things actually work. For example: an insert function runs asynchronously so the function call returns immediately, but the actual insert still executes in the background. To correctly measure the actual time it takes to complete the insert, you need to do some additional work.

Things to watch out for when coding benchmarks

database benchmark

Let’s move on to some specific coding tips. A benchmark is only as good as its time measurement. Check what APIs your test platform offers to get the time; they might be affected by how and from which thread they are called. Make sure, you find an accurate way to measure the time that does not skew up your results. For example, on Android there are numerous possibilities beyond using currentTimeMillis(). 

If a measured code block executes so fast it is near the available precision of your clock (e.g. time is in milliseconds, but code takes microseconds), consider running it multiple times and measure the total time of all runs. 

Next, before starting each measurement, make sure to free up memory and clear references no longer in use by the previous measurement or setup code. If the environment your benchmark is written for uses a garbage collector, check if it can be triggered manually to free memory (e.g. System.gc() in Java). Otherwise each consecutive measurement might be skewed due to less and less memory being available or a garbage collector halting execution to free memory. In your benchmarking results, you should look out for strange results like a continual decrease in performance from run to run.

Furthermore, take into account that some runtime environments, for example the Java Virtual Machine, do just-in-time compilation. This can cause a delay the first time code is executed, but provide better performance on subsequent executions. The effect of this on the final result can however be minimized by proper testing procedure, e.g. by running a code block multiple times instead of once and measuring the total execution time.

Then something obvious, but easily overlooked, is to ensure that between the start and end of a measurement only the functionality that you actually want to compare is executed. So avoid or turn off logging (a seemingly innocent string concatenation can skew results) and construct test data outside of a measured code block.

To be absolutely sure that your code is doing what you intended it to, use a profiler to inspect resource usage during a trial run. IDEs like Android Studio and Xcode come with an embedded profiler, and there are also several standalone profilers to choose from.

Optimizing benchmarks for meaningful results – with ObjectBox examples

Before benchmarking the chosen databases, make sure you understand their differences and default settings to adjust all settings to be comparable. In the following section, we will go through the most important differences and settings you need to look out for based on ObjectBox as an example.

Transactions, Durability, Consistency, ACID – how to make your benchmarks comparable

First, be aware of the impact the use of transactions or lack thereof can have. For databases, committing a transaction is an expensive operation as it requires waiting until the disk has safely stored the data. If possible, group multiple operations into a single transaction. For example, in the ObjectBox code snippet below, there is a notable speed-up when wrapping multiple box operations into a transaction block.

Speaking of transactions, also check if using bulk operations is possible. These also use transactions to speed up execution. E.g. instead of performing a put on each entity in a list, put the whole list.

The ObjectBox transactions docs provide more details and are available for Java, Swift or Go – though the basic principle is the same across languages. 

Second, and closely related to transactions, are durability guarantees when writing data. This is about the “D” in the popular ACID acronym (Atomic, Consistent, Isolated and Durable). ObjectBox transactions and standard (non-async) operations are fully ACID-compliant.

Thus, pay close attention to what durability modes other tested databases guarantee, or respectively, which durability mode you want to measure. Most NoSQL databases don’t give hard durability guarantees. Some provide an extra command or special mode to enforce durability. Therefore, if your use case needs to ensure data is actually stored safely after a write operation, you would need to enable this durability for other databases when comparing to ObjectBox.

On the other hand, if you are interested in scenarios that emphasize performance over durability, you should look into the OjectBox async APIs. Those don’t come with durability guarantees unless you define “checkpoints” in your code to wait for async operations.

Indexing – how to make your database queries efficient

Third, when measuring query operations, see if you can use indexes, another typical database optimization. If the database has an index on a property that is used in a query condition, it can find matches much faster. 

An index makes queries “scalable” – the more objects are stored, the more an index makes sense. Without an index, a database has to do a “full scan” over all potential results. 

Number of objects and the disk bottleneck – how to measure the database and not the disk

And lastly, keep an eye on the number of objects you operate on. For example, if you put a single object, something like 99.99% percent will be spent on disk I/O. Thus, if you test this on several databases, the chance of getting about the same results on all databases is quite high. The limiting factor is always the disk. So if you want to measure the efficiency of converting objects into their persisted counterparts instead, you should look at much higher object counts to factor the disk out of the equation. Depending on the disk and device speed, a bulk “put” of 10K, 100K or 1 million objects will make more sense to measure in this context.

Multi threaded tests – how to set writers and readers

ObjectBox is build upon a multiversion concurrency control foundation, and thus is ready for multi threaded access. Each thread will have a consistent transactional view of the data. ObjectBox differentiates between “readers” (a thread currently in a read transaction) and “writers” (a thread currently in a write transaction). Readers never block; no matter what goes on in other threads. However, a writer will block other writers when using standard transactions. Writers are sequential; only a single writer can be run at any time. Thus, if your load is write-heavy in multiple threads, you may want to look at the asynchronous APIs of ObjectBox. These handle write operations very efficiently; no matter how many threads are involved.

Extending the database size limit – size matters

By default, ObjectBox limits the database size to 1 GB to avoid filling up the disk by accident (e.g. your code has a bug in a data insertion loop). So if you use large data sets to benchmark, we recommended increasing the maximum database size when building the box store.

Preparing the benchmarks: devices and platforms

Once your benchmark code is ready, it’s time to set up the test device(s). The first step is to ensure other apps or processes are not doing (too much) work while your measurements run. Ideally, you would use a clean device with no apps installed or services configured. This is especially true for mobile devices: once you connect them and they start charging, the operating system might wake numerous apps to perform background work or network updates. You can somewhat avoid this by switching on airplane mode. And to be safe, wait a few seconds after connecting the device. 

Also ensure, this is again important for mobile devices, that your device does not enter a low power mode which reduces performance. For example on Android, keeping the screen on typically prevents that. When running on a laptop, check whether the power supply is plugged in and which power mode your operating system is set to. You may explicitly want to test in a certain power state or with the default behavior.

And just to mention it, make sure to turn off any profiling or monitoring tools that you used during building your benchmark. They can significantly skew your results.

When running on multiple devices, pay attention to the differences in hardware, like available memory and processor model, but also in software, like the operating system version. Different hardware and software might have different optimizations that can skew your results. Again, do not forget to document your device and software setup, so results can be properly interpreted and reproduced.

Running the database benchmark and collecting results

When it is time to run the benchmark it’s good to run it not once, not twice, but many times. This minimizes the impact of the various side effects we discussed above. Output the results of each run into a comma separated (CSV) or tabulator separated (TSV) format, that can easily be imported in a spreadsheet application for analysis. You can look at how the ObjectBox benchmark does it.

Once you have collected some data, verify its quality. You might have already spotted outliers while perusing the results. Alternatively, calculate the average of all measurements and see if it deviates a lot from their median value. If you are familiar with it, look for a high variance value instead. Too many outliers or a high variance might hint at side effects of your benchmark code or device setup you have not considered. Better double check to be sure.

Also coming soon ObjectBox time series which will provide users an intuitive dashboard to see patterns behind the data. It will further help users to track thousands of data points/second in real-time.

How to publish meaningful database performance benchmarks

The final step is to share your results with the world (or just your team). Make sure it’s clear what exactly you have measured and how you have arrived at those results. So include which device and software was used, how they were configured, what you did before running the benchmark and how the benchmark was run.

If possible, share the generated raw data so others can verify that your calculations, and remember to lead to the published results. Even better, publish the source code as well, so others can run it on other devices or help you spot and fix issues.

Last not least: Be careful to draw conclusions. Rather let the data speak for itself. Respond to questions and feedback. Be honest, if you learn your benchmarks may be skewed and update them. In the end, everyone wins by getting more meaningful results.

billiger.de Mobile App Case Study

billiger.de Mobile App Case Study

Arne Jans

Arne Jans

Software Developer, solute

Vivien: Hi Arne, great to talk with you today. Let’s get started by learning more about you and billiger.de.

Arne: Hi Vivien. I’ve been doing software development for more than 10 years, and API design for the last 5 years. I am currently responsible for mobile development for billiger.de, the most widely used and award-winning price comparison portal in Germany. We’re especially proud of our data security, which was just recently awarded too.

The company behind billiger.de is solute GmbH, which is based in Karlsruhe. They also have a few other brands: shopping.de, an online shopping platform for men and women, and friends communication, an online marketing agency. At billiger.de we’re about 150 employees.

Some of our stats:

300,000+

active daily users on billiger.de

500,000+

app downloads

70 Million

prices in the database

22,500 Shops

comparing 1M products

So clearly, the database and its performance on the server side is very important. Companies update their prices all the time, and on top there are all kinds of vouchers that can be applied. All of these are changing frequently – and you never know who updates their prices when. So, you can see the challenges – from a technical standpoint but also for consumers. It is hard to get the best price.

V: Tell me more about the billiger.de app – why did you decide to go for a native app?

A: Well, to be honest there was an existing native app when I came into the company. But aside from that, it’s essential for UX. We also need some offline capability for features like the notepad function or when users are in the store without an Internet connection and scan barcodes. Once they are online again, the query goes to the cloud – and the user gets his result.

V: So are most of your users on the app? Or rather web?

A: We definitely still have more web users, but user numbers are shifting to mobile more and more. Also, our web users are often one time users only. Our loyalty rate is much higher with app users, so we are trying to increase app installs. We’re seeing that – even on the web – the majority of users are coming from mobile devices. Therefore, we relaunched the website a couple of years ago to be responsive and mobile optimized. So we are focusing more and more on mobile, on both the website and through the app. 

V: Why did you need to implement a local database? How is it implemented in your solution?

A: We need data persistence mainly for certain features. We’re still using SQLite, but it’s too much boilerplate code and too little fun. We have been using an ORM on top of SQLite until recently, but it didn’t work well in combination with Proguard on some Android versions anymore. So it resulted in lost data. We’re currently using ObjectBox in the billiger.de Pro version and in a fun new project called PricePretzel, which gives users the best price actively and tracks savings. In these projects, ObjectBox has proven its worth, so we want to migrate the billiger.de app too. 

V: Yes, SQLite with an ORM can get very messy. So, why did you choose ObjectBox as the alternative?

A: I looked at several SQLite alternatives and ObjectBox looked interesting. The main decision factors were: ease of integration, stability, and performance. But ease of use and integration were really the most important factors. Stability and enough performance were rather basic necessities. We found ObjectBox really easy to use – we did the migration and everything and because ObjectBox handles that automatically, it was really simple.

We found ObjectBox really easy to use – we did the migration and everything and because ObjectBox handles that automatically, it was really simple.

ObjectBox database mobile app case study
mobile app database case study
mobile app database case study

V: So did performance matter to you at all?

A: For our needs, performance was secondary. Obviously the performance needs to be good enough, but we do not have super high requirements regarding performance.

V: Do you do any sort of synchronization

A: Synchronization obviously is a super interesting feature and we are keeping an eye on it once it is publicly released. From the setup we have, we would need to do it with a connector to our existing database. Currently the web data and app data are separated and we are working on integrating them. So, this needs synchronization. 

V: Which other tools do you use in your solution/are you excited about?

A: Retrofit from Square, a networking library, we recommend it to everyone and it works super well with ObjectBox. Both libraries work well together with our business objects. Retrofit fetches the fresh data from our servers and deserializes it into our business objects, which are then persisted with ObjectBox without any additional boilerplate code.

V: billiger.de has over 500.000 downloads and about 4 stars on average – how many daily users does the billiger.de app have? Do you have peak times?

A: Obviously holidays like Christmas and Easter are busier. During the day, early evenings get the most traffic – about 1000-2000 daily active users in the billiger.de app, 200 in our Pro-app, and iOS is similar. As I shared before, we get about 300k daily users on the website.

V: Thanks for sharing, and for talking with me today. Any last words?

A: Thank you for having me! I am looking forward to do more with ObjectBox and am very excited about what comes next!