In-Memory Database Use Cases

In-Memory Database Use Cases

ObjectBox was a purely disk-based database until now. Today, we added in-memory storage as a non-persistent alternative. This enables additional use cases requiring temporary in-process data. It’s also great for testing. 

ObjectBox In-Memory Database

Disk + In-memory: simply use the best of both worlds

When opening a new database, you can now choose if the database is stored on disk or in-memory. Because this is a per database option, it is possible to use both types in your application. It’s very simple to use: when opening the store, instead of providing an actual directory, provide an pseudo-directory as a string with the prefix “memory:”. After the prefix, you pick a name for the database to address it, e.g. “memory:myApp”.

Note: in-memory databases are kept after closing a store; they have to be explicitly deleted or are automatically deleted if the creating process exists.

So, what are typical in-memory database use cases?

Caching and temporary data

If data is short lived, it may not make sense involving the disk with persistent storage. Unlike programming language containers like maps and hash tables, caches built on in-memory databases have advanced querying capabilities and support complex object graphs. For example, databases allow lookups by more than one key (e.g. ID, name and URL). Or deleting certain entries using a query. As ObjectBox is closely integrated with programming languages, putting and getting an object are typically just “one liners” similar to map and hash table containers.

Bringing “online-only” and “offline-first” apps closer together

Let’s say you want to start simple by creating an application that always fetches the data from the cloud. You can put that data in an in-memory database (similar to the caching approach above). The data is available (“cached”) for all app components via a common Box-based API, which is already great. But let’s say later on, you want to go “offline-first” with your app to respond quicker to user requests and save cloud and/or mobile networking operator (MNO) costs. Since you are already using the Box-based API, you simply “turn on persistence” by using a disk-based database instead.

Performance and app speed

Shouldn’t this be the first point in the list? Well, ObjectBox did already operate at “in-memory speed” for mostly-read scenarios even though it used a disk-based approach. So, do not expect huge improvements for reads. Writes (Create, Update, Delete) are different though: to fully support ACID, a disk-based database must wait on the disk to fully complete the operation. Contrary to this, an in-memory database can immediately start the next transaction.

Diskless devices

Some small devices, e.g. sensors, may not have a disk or an accessible file system. This update makes it possible to run ObjectBox here too. This can be an interesting combination with ObjectBox Sync and automatically getting data from another device.

Testing

For example in unit tests, you can now spin up ObjectBox databases even faster than before, e.g. opening and closing a store in less than a millisecond.

“Transactional memory”

In concurrent (multi-threaded) scenarios, you may want to provide transactional consistent views (or “checkpoints”) of your data. Let’s say bringing the data from one consistent view to another is a rather complex operation involving the modification of several objects. In such cases locking may be a concern (complex or blocking), so having an in-memory database may be a nice alternative. It “naturally” offers transactions and thus transactional safe view on data. Thus, you can always read consistent data without worrying about data being modified at the same time. Also, you never have to wait for a modifying thread to finish.

What’s next?

This is only our first version of our in-memory store. Consider it as an starting point for more to come:

  • Performance: to ship early, we made rather big performance tradeoffs. At this point, starting a new write transaction will copy all data internally, which of course is not great for performance. A future version will be a lot smarter than that.
  • Persistence: While this version is purely in-memory without persistence, we want to add persistence gradually. This will include a write-ahead-log (WAL) and snapshots. This constellation may become even preferable over the default disk-base store for some scenarios.

We are currently rolling out the in-memory feature to all language supported by ObjectBox:

Let us know your thoughts

❤️

SQLite and SQLite alternatives – a comprehensive overview

SQLite and SQLite alternatives – a comprehensive overview

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

Overview of SQLite and SQLite alternatives as part of the mobile / edge database market with a comprehensive comparison matrix (updated summer 2023)

Digitalization is still on the rise, as is the number of connected devices (from 13 billion connected IoT devices + 15 billion mobile devices operating in 2021 already). Data volumes are growing accordingly ( 3.5 quintillion bytes of data is produced daily in 2023), and centralised (typically cloud-based) computing can no longer support the current needs. This has led to new challenges in computing and subsequently to a shift from the cloud to the edge.

Therefore, there is a new need for on-device (local) databases like SQLite and SQLite alternatives to persist data on the edge. On top, due to the growing number of edge / connected devices, there is a need to manage data flows to / from and between edge devices. This can be done with Edge Databases (SQLite and SQLite alternatives) that provide a Data Sync functionality. In the following we’ll have a look at these.

Databases for the Edge

 While being quite an established market with many players, the database market is still growing consistently and significantly. The reason is that databases are at the core of almost any digital solution, and directly impact business value and therefore never going out of fashion. With the rapid evolvements in the tech industry, however, databases need to evolve too. This, in turn, yields new database types and categories. We have seen the rise of NoSQL databases in the last 20 years, and more recently some novel database technologies, like graph databases and time-series databases, and only this year: vector databases. Both, the shift back from a centralised towards a decentralised paradigm, and the growing number of restricted devices call for an “old / new” type of database. SQLite has been around for more than 20 years and for good reason, but the current market shift back to decentralized computing happens in a new environment with new requirements. Hence, the need for a “new” database type, based on a well-established database type: “Edge databases”. Accordingly, a need for SQLite alternatives (depending on the use case of course; after all SQLite is a great database).

vector-databases-market-creation-edge
What is an Edge Database?

Edge databases are a type of databases that are optimised for local data storage on restricted devices, like embedded devices, Mobile, and IoT. Because they run on-device, they need to be especially resource-efficient (e.g. with regards to battery use, CPU consumption, memory, and footprint). The term “edge database” is becoming more widely-used every year, especially in the IoT industry. In IoT, the difference between cloud-based databases and ones that run locally (and therefore support Edge Computing) is crucial.

What is a Mobile Database?

We look at mobile databases as a subset of edge databases that run on mobile devices. The difference between the two terms lies mainly in the supported operating systems / types of devices. Unless Android and iOS are supported, an edge database is not really suited for the mobile device / smartphone market. In this article, we will use the term “mobile database” only as “database that runs locally on a mobile (edge) device and stores data on the device”. Therefore, we also refer to it as an “on-device” database.

What are the advantages and disadvantages of working with SQLite?

SQLite is a relational database that is clearly the most established database suitable to run on edge devices. Moreover, it is probably the only “established” mobile database. It was designed in 2000 by Richard Hipp and has been embedded with iOS and Android since the beginning. Now let’s have a quick look at its main advantages and disadvantages:

Advantages  Disadvantages
  • 20+ years old (should be stable ;))
  • Toolchain, e.g. DB browser
  • No dependencies, is included with Android and iOS
  • Developers can define exactly the data schema they want
  • 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 analyse it
  • 20+ years old ( less state-of-the-art tech)
  • Using SQLite means a lot of boilerplate code and thus inefficiencies ( maintaining long running apps can be quite painful)
  • No compile time checks (e.g. SQL queries)
  • SQL is another language to master, and can impact your app’s efficiency / performance significantly…
  • The performance of SQLite is unreliable
  • 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 the SQLite alternatives?

There are a bunch of options for making your life easier, if you want to use SQLite. You can use an object abstraction on top of it, an object-Relational-Mapper (ORM), for instance greenDAO, to avoid writing lots of SQL. However, you will typically still need to learn SQL and SQLite at some point. So what you really want is a full blown database alternative, like any of these: Couchbase Lite, Interbase, LevelDB, ObjectBox, Oracle Berkeley DB, Mongo Realm, SnappyDB, SQL Anywhere, or UnQLite.

While SQLite really is designed for small devices, people do run it on the server / cloud too. However, for server / cloud databases, there are a lot of alternatives you can use as a replacement like e.g. MySQL, MongoDB, or Cloud Firestore.

Bear in mind that, if you are looking to host your database centrally with apps running on small distributed devices (e.g. mobile apps, IoT apps, any apps on embedded devices etc.), there are some difficulties. Firstly, this will result in higher latency, i.e. slow response-rates. Secondly, the offline capabilities will be highly limited or absent. As a result, you might have to deal with increased networking costs, which is not only reflected in dollars, but also CO2 emissions. On top, it means all the data from all the different app users is stored in one central place. This means that any kind of data breach will affect all your and your users’ data. Most importantly, you will likely be giving your cloud / database provider rights to that data. (Consider reading the general terms diligently). If you care about privacy and data ownership, you might therefore want to consider a local database option, as in an Edge Database. This way you can decide, possibly limit, what data you sync to a central instance (like the cloud).

SQLite alternatives Comparison Matrix

To give you an overview, we have compiled a comparison table including SQLite and SQLite alternatives. In this matrix we look at databases that we believe are apt to run on edge devices. Our rule of thumb is the databases’ ability to run on Raspberry Pi type size devices. If you’re on mobile, click here to view the full matrix.

Edge Database Short description License / business model Android / iOS* Type of data stored Central Data Sync P2P Data Sync Offline Sync (Edge) Data level encryption Flutter support Vector (AI) support  Minimum Footprint size Company
SQLite C programming library; probably still 90% market share in the small devices space (personal assumption) Public domain embedded on iOS and Android Relational No No No No, but option to use SQLCipher to encrypt SQLite Flutter plugins (ORMs) for SQLite, but nothing from Hwaci No, but various unofficial extensions are available < 1 MB Hwaci
Couchbase Mobile Embedded / portable database with P2P and central synchronization (sync) support; pricing upon request; some restrictions apply for the free version. Secure SSL. Partly proprietary, partly open-source, Couchbase Lite is BSL 1.1 Android / iOS JSON Documents / NoSQL db Yes Yes No Database encryption with SQLCipher (256-bit AES) Unofficial Flutter plugin for Couchbase Lite Community Edition No < 3,5 MB Couchbase
InterBase ToGo / IBLite Embeddable SQL database. Proprietary Android / iOS Relational No No No 256 bit AES strength encryption No No < 1 MB Embarcadero
LevelDB Portable lightweight key-value store, NoSQL, no index support; benchmarks from 2011 have been removed unfortunately New BSD Android / iOS Key-value pairs / NoSQL db No No No No Unofficial client that is very badly rated No < 1 MB LevelDB Team
LiteDB A .Net embedded NoSQL database MIT license Android / iOS (with Xamarin only) NoSQL document store, fully wirtten in .Net No No No Salted AES No No < 1 MB LiteDB team
Mongo Realm / Realm DB (acquired by Mongo in 2019) Embedded object database Mongo Realm is Apache 2.0, Mongo DB is SSPL, Mongo Atlas (?) Android / iOS Object Database Yes (Mongo Atlas), tied to using Mongo DB No No Yes Officially released a Flutter binding in spring 2023 (See Flutter databases) No 5 MB+ MongoDB Inc.
ObjectBox High-performance NoSQL Edge Database with out-of-the-box Data Sync for Mobile and IoT; fully ACID compliant; benchmarks available. Apache 2.0 and Proprietary 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 Yes Yes, vector support already available, more AI support coming < 1 MB ObjectBox
Oracle Database Lite Portable with P2P and central sync support as well as support for sync with SQLite Proprietary Android / iOS Relational Yes Yes No 128-bit AES Standard encrytion No No < 1 MB Oracle Corporation
SQL Anywhere Embedded / portable database with central snyc support with a stationary database, pricing now available here Proprietary Android / iOS Relational Yes, tied to using other SAP tech though (we believe) No No AES-FIPS cipher encryption for full database or selected tables No No   SAP (originally Sybase)
UnQLite Portable lightweight embedded db; self-contained C library without dependency. 2-Clause BSD Android / iOS Key-value pairs / JSON store / NoSQL db No No No 128-bit or 256-bit AES standard encryption not yet; might be coming though; there was a 0.0.1 released some time ago No ~ 1.5 MB Symisc systems
extremeDB Embedded relational database Proprietary iOS In-memory relational DB, hybrid persistence No No No AES encryption No Yes, vector support available, nothing more yet < 1 MB McObject LLC
redis DB High-performance in-memory Key Value store with optional durability Three clause BSD license, RSAL and Proprietary No K/V in-memory store, typically used as cache No No No TLS/SSL-based encryption can be enabled for data in motion. Unofficial redis Dart client available Yes An empty instance uses ~ 3MB of memory redislabs (the original author of redis left in 2020)
Azure SQL Edge  Designed as a SQL database for the IoT edge; however, due to the footprint it is no Edge Database Proprietary No Relational DB for IoT No No No will provide encryption No   500 MB+ Microsoft

Star this matrix on GitHub. If you are interested in an indication of the diffusion rate of databases, check out the following database popularity ranking: http://db-engines.com/en/ran. If you are interested to learn more about SQLite, there is a great Podcast interview with Richard Hipp that is worthwhile listening to.

Is there anything we’ve missed? What do you agree and disagree with? Please share your thoughts with us via Twitter or email us on contact[at]objectbox.io. 

Make sure to check out the ObjectBox Database & try out ObjectBox Sync. You can get started in minutes and it’s perfect if you are using an object-oriented programming language, as it empowers you to work with your objects within the database. More than 1,000,000 developers already use this Edge Database designed specifically for high performance on small, connected, embedded devices.

ObjectBox Database Java 3.1 – Flex type

ObjectBox Database Java 3.1 – Flex type

We are happy to announce version 3.1 of ObjectBox for Java and Kotlin. The major feature of this version is the new Flex type. For a long time, ObjectBox worked on rigid data schemas, and we think that this is a good thing. Knowing what your data looks like is a feature – similar to programming languages that are statically typed. Fixed schemas make data handling more predictable and robust. Nevertheless, sometimes there are use cases which require flexible data structures. ObjectBox 3.1 allows exactly this.

Flex properties

Expanding on the string and flexible map support in 3.0.0, this release adds support for Flex properties where the type must not be known at compile time. To add a Flex property to an entity use Object in Java and Any? in Kotlin. Then at runtime store any of the supported types.

For example, assume a customer entity with a tag property:

Then set a String tag on one customer, and an Integer tag on another customer and just put them:

When getting the customer from its box the original type is restored. For simplicity the below example just casts the tag to the expected type:

A Flex property can be not justString or Integer. Supported types are all integers (Byte, Short, Integer, Long), floating point numbers (Float, Double), String and byte arrays.

It can also hold a List<Object> or a Map<String, Object> of those types. Lists and maps can be nested.

Behind the scenes Flex properties use a FlexBuffer converter to store the property value, so some limitations apply. See the FlexObjectConverter class documentation for details.

Query for map keys and values

If the Flex property contains integers or strings, or a list or map of those types, it’s also possible to do queries. For example, take this customer entity with a properties String to String map:

Why is properties not of type Object? ObjectBox supports using Map<String, String> (or Map<String, Object>) directly and will still create a Flex property behind the scenes.

Then put a customer with a premium property:

To query for any customers that have a premium key in their properties map, use the containsElement condition:

Or to only match customers where the map key has a specific value, here a specific premium tier, use the containsKeyValue condition:

What’s next?

ObjectBox database is free to use. Check out our docs and this video tutorial to get started today.

We strive to bring joy to mobile developers and appreciate all kinds feedback, both positive and negative. You can always raise an issue on GitHub or post a question on Stackoverflow. Otherwise, star the ObjectBox  Java database GitHub repo and up-vote the features you’d like to see in the next release.

 

ObjectBox Database Java / Kotlin 3.0 + CRUD Benchmarks

ObjectBox Database Java / Kotlin 3.0 + CRUD Benchmarks

The Android database for superfast Java / Kotlin data persistence goes 3.0. Since our first 1.0-release in 2017 (Android-first, Java), we have released C/C++, Go, Flutter/Dart, Swift bindings, as well as Data Sync and we’re thrilled that ObjectBox has been used by over 800,000 developers.

We love our Java / Kotlin community ❤️ who have been with us since day one. So, with today’s post, we’re excited to share a feature-packed new major release for Java Database alongside CRUD performance benchmarks for MongoDB Realm, Room (SQLite) and ObjectBox.

What is ObjectBox?

ObjectBox is a high performance database and an alternative to SQLite and Room. ObjectBox empowers developers to persist objects locally on Mobile and IoT devices. It’s a NoSQL ACID-compliant object database with an out-of-the-box Data Sync providing fast and easy access to decentralized edge data (Early Access).

New Query API

A new Query API is available that works similar to our existing Dart/Flutter Query API and makes it easier to create nested conditions:

In Kotlin, the condition methods are also available as infix functions. This can help make queries easier to read:

Unique on conflict replace strategy

One unique property in an @Entity can now be configured to replace the object in case of a conflict (“onConflict”) when putting a new object.

This can be helpful when updating existing data with a unique ID different from the ObjectBox ID. E.g. assume an app that downloads a list of playlists where each has a modifiable title (e.g. “My Jam”) and a unique String ID (“playlist-1”). When downloading an updated version of the playlists, e.g. if the title of “playlist-1” has changed to “Old Jam”, it is now possible to just do a single put with the new data. The existing object for “playlist-1” is then deleted and replaced by the new version.

Built-in string array and map support

String array or string map properties are now supported as property types out-of-the-box. For string array properties it is now also possible to find objects where the array contains a specific item using the new containsElement condition.

Kotlin Flow, Android 12 and more

Kotlin extension functions were added to obtain a Flow from a BoxStore or Query:

Data Browser has added support for apps targeting Android 12.

For details on all changes, please check the ObjectBox for Java changelog.

Room (SQLite), Realm & ObjectBox CRUD performance benchmarks

We compared against the Android databases, MongoDB Realm and Room (on top of SQLite) and are happy to share that ObjectBox is still faster across all four major database operations: Create, Read, Update, Delete.

Android database comparative benchmarks for ObjectBox, Realm, and Room

We benchmarked ObjectBox along with Room 2.3.0 using SQLite 3.22.0 and MongoDB Realm 10.6.1 on an Samsung Galaxy S9+ (Exynos) mobile phone with Android 10. All benchmarks were run 10+ times and no outliers were discovered, so we used the average for the results graph above. Find our open source benchmarking code on GitHub and as always: feel free to check them out yourself. More to come soon, follow us on Twitter or sign up to our newsletter to stay tuned (no spam ever!).

Using a fast on-device database matters

A fast local database is more than just a “nice-to-have.” It saves device resources, so you have more resources (CPU, Memory, battery) left for other resource-heavy operations. Also, a faster database allows you to keep more data locally with the device and user, thus improving privacy and data ownership by design. Keeping data locally and reducing data transferal volumes also has a significant impact on sustainability.

Sustainable Data Sync

Some data, however, you might want or need to synchronize to a backend. Reducing overhead and synchronizing data selectively, differentially, and efficiently reduces bandwidth strain, resource consumption, and cloud / Mobile Network usage – lowering the CO2 emissions too. Check out ObjectBox Data Sync, if you are interested in an out-of-the-box solution.

Get Started with ObjectBox for Java / Kotlin Today

ObjectBox is free to use and you can get started right now via this getting-started article, or follow this video.

Already an ObjectBox Android database user and ready to take your application to the next level? Check out ObjectBox Data Sync, which solves data synchronization for edge devices, out-of-the-box. It’s incredibly efficient and (you guessed it) superfast 😎

We ❤️ your Feedback

We believe, ObjectBox is super easy to use. We are on a mission to make developers’ lives better, by building developer tools that are intuitive and fun to code with. Now it’s your turn: let us know what you love, what you don’t, what do you want to see next? Share your feedback with us, or check out GitHub and up-vote the features you’d like to see next in ObjectBox.

Flutter databases –  hive, ObjectBox, sqflite (+ Drift, floor)

Flutter databases – hive, ObjectBox, sqflite (+ Drift, floor)

Flutter, the renowned cross-platform mobile framework, has been gaining immense popularity among developers worldwide. As the Flutter community expands, the demand for efficient Flutter databases is also increasing. Developers now have access to a range of Flutter database options that cater to various needs and preferences.

In this article, we’ll focus specifically on local storage solutions, as these are essential for enabling offline functionality, improving performance, ensuring data persistence, enhancing data privacy and security, and supporting edge computing capabilities. Furthermore, local data storage is needed to promote sustainability. Let’s dive into the current local database landscape for Flutter and compare the most popular options.

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. 

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 local data persistence landscape

There are several Flutter databases that provide offline support, offering the ability to store and access data locally even without an internet connection. Here are some of the notable options:

  • 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 with an integrated Data Sync. It stores objects.
  • sqflite is a wrapper around SQLite, which is a relational database without direct support for Dart objects. 
  • Drift is a reactive persistence library for Flutter and Dart, built ontop of SQLite. 
  • Floor is another ORM on top of SQLite.

 

What is the best offline 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 like comparing apples 🍎 and pears 🍐.

Name Description Primary Model Language License Data Sync
Hive Lightweight key-value database NoSQL Dart Apache 2.0
ObjectBox Lightweight NoSQL database with integrated Data Sync NoSQL Dart Bindings are Apache 2.0
Drift ORM on top of SQLite relational SQL SQLite is public domain, Drift is MIT
Floor ORM on top of SQLite relational SQL SQLite is public domain, Floor is Apache 2.0
sqflite SQLite plugin for Flutter relational SQL SQLite is public domain, sqflite lib is MIT
<p>Diese Seite verwendet Frames. Frames werden von Ihrem Browser aber nicht unterstützt.</p>

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

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.

Drift and Floor were not part of the benchmarking as they are ORMs. However, it is very likely they will perform similarly to sqflite, reflecting primarily the performance of SQLite.

Flutter Data persistence – Conclusion

Recently, the Flutter database landscape has experienced significant growth and diversification. With Flutter’s increasing popularity, developers now have a number of database options available. In this article, we focused on the best local databases, comparing their features in a comprehensive matrix, and showcasing performance benchmarks. In the end, the best choice depends on the specific needs of each project. The Flutter database landscape in 2023 is a thriving ecosystem, continuously evolving to meet the changing needs of Flutter app development. One upcoming change that we can see is the rise of vector databases for AI. So, we encourage you to keep an eye on the lively market of Flutter databases not to miss any important updates.

If you want to get started learning how to use a database, we suggest you check out this video tutorial series that teaches you how to build a Flutter app with ObjectBox from scratch.

 

Firebase alternatives for Data Storage and Data Sync

Firebase alternatives for Data Storage and Data Sync

Data Sync is a typical recurring and typically non-trivial developer challenge. Synchronizing data in offline/online settings, like for example across eventually connected devices, is simply hard. While JSON / REST is great, building Data Sync yourself is time-consuming, risky, and typically considered no fun. 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.

Introduction

One of the most well-known Data Sync solutions is Firebase. However, Firebase is purely cloud based and offers no support for local data storage ( as in “data persistence above caching”) and therefore 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. 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 Sync solutions? Very few. While there are more and more cloud-based Firebase alternatives springing up nearly daily (e.g. appwrite and supabase) forcing the user into a centralized cloud setup, there is almost nothing that supports offline Data Sync and / or persistent local data storage. As our focus is on offline / edge Data Sync and local storage, in the following we add all edge / offline Data Sync solutions we know of, but spare you the wealth of cloud options only adding the established ones.

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. This includes the data synchronization, scalability, network, infrastructure challenges etc. Indeed, Firebase, today, offers many different services (e.g. analytics, crashlytics) and goes well beyond Data Sync. We are looking at Firebase from the Data 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. Incidentally, the same year Parse was acquired by Facebook to be subsequently shut down, and Couchbase raised significant funding. All three are still in use today. 

Firebase Pros and Cons

In the following, we will first look at the advantages and disadvantages of Firebase. Then, we will compare Firebase with Firebase alternatives like Couchbase, Parse and ObjectBox in a comprehensive matrix.  

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 Sync 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). This means that data synchronisation is only a specific part of the whole offering. 

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

👉 Want to save this info for later? Watch the Firebase alternatives matrix on GitHub to find it easily wherever you need it.

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.