Mobile Database Archives

What is an Edge Database, and why do you need one?

by Vivien | Jun 23, 2021 | Edge Computing, Insights, IoT, Mobile Database

Edge Databases – from trends to use cases

With the megashift from Cloud Computing to the Edge, a lack of core technologies supporting the needs of the decentralized Edge Computing topology became apparent. Edge Databases are a new type of database addressing these need. To implement edge solutions, developers need fast local data persistence and decentralized data flows (Data Sync). Edge Databases solve these core edge functionalities out-of-the-box, making it easy for application developers to implement edge solutions quickly.

The trends driving the megashift to decentralized Edge Computing
Urgently needed: Software infrastructure for edge computing
What is an edge database?
When do you need an edge database?
Edge Database Use Case Example in Manufacturing
Edge Database Outlook

The trends driving the megashift to decentralized Edge Computing

By 2025, 30+ billion IoT devices will be creating ~4.6 trillion GB of data per day. The growing numbers of devices and data volume, variety, and velocity, as well as bandwidth infrastructure limitations, make it infeasible to store and process all data in a centralized cloud. On top, new use cases come with new requirements, a centralized cloud infrastructure cannot meet. For example, soft and hard response rate requirements, offline-functionality, and security and data protection regulations.

These trends accelerate the shift away from centralized cloud computing to a decentralized edge computing topology. Edge computing refers to decentralized data processing at the “edge” of the network. For example, in a car, on a machine, on a smartphone, or in a building. Hardware specifications do not capture the definition of an “edge device”. The crucial point is rather the decentralized use of data at, or as close as possible to, the data source.

Edge computing itself is not a technology but a topology, and according to McKinsey, one of the top growing trends in tech in 2021. The technologies needed to implement the edge computing topology are at this moment still inadequate. More specifically, there is a gap in basic “core” edge technologies, so-called “software infrastructure”. This gap is one of the main reasons for the failure of edge projects.

Needed: Software infrastructure for Edge Computing

With computing shifting to the edge of the network, the needs of this decentralized topology become clear:

Need for fast local data storage

→ i.e. a machine on the factory floor collects data on stiffness, friction, pressure points. There is limited space on the device, and typically no connection to the Internet. Even with an Internet connection, high data rates quickly push the available bandwidth, as well as associated networking / cloud costs, to the limit. To be able to use this data, it must be persisted in a structured manner at the edge, e.g. stored locally in a database.

Need for reliable on-device data flows

→ i.e. the car is an edge device consisting of many control units. Therefore, data must be stored on multiple control units. In order to access and use the data within several of the control units of the car, the data must be selectively synchronized between the devices. A centralized structure and thus a single point of failure is unthinkable.

Need for edge-to-edge-to-cloud data flows

→ i.e. in a manufacturing hall: Typically, you will find any number of diverse devices from sensors to brownfield to greenfield devices, and no internet connectivity. At the same time, there are diverse employee devices such as tablets or smartphones, as well as central PCs, and a cloud. To extract value from the data, it must be available in raw, aggregated, or summary form, in different places. This means it needs to be synchronized efficiently and selectively, with possible conflicts resolved.

Need for flexible edge data management

→ e.g. with the rise of IoT, time-series data have become common. However, time series data alone is usually not sufficient, and needs to be combined with other data structures (like objects) to add value. At the same time, a push to standardize data formats in industries (e.g. VSS in automotive or Umati in Industrial IoT) requires that the database supports flexible data structures.

Developing solutions without software infrastructure on an individual level is possible, but has many drawbacks:

Custom in-house implementations are cumbersome, slow, costly, and typically scale poorly. Oftentimes, applications or certain feature sets become unfeasible to deliver because of the lack of core software infrastructure. Legacy code and individual workarounds create problems over the lifetime of a product. Instead of a thriving ecosystem, only a few big players are able to implement edge solutions. Innovation and creativity are limited. An edge database is part of the solution and enables the entire edge ecosystem to build edge applications faster, cheaper and more efficiently.

What is an edge database?

An edge database is a new type of database specifically tailored to the unique requirements of the Edge Computing topology. An edge database has specific features that make it easy for application developers to focus on value creation. It remove the burden of implementing underlying functionalities for secure storage and the decentralized synchronization of data.

First, an edge database is optimized for resource efficiency (CPU, memory, …) and performance on resource-constrained devices (embedded devices, IoT, mobile). It has a small footprint of a few megabytes. Traditional databases such as MySQL or MongoDB are too large and cumbersome for typical edge devices, and unsuitable for computing at the edge.

An edge device without data flows to/from other devices is just a data island with very limited utility. Accordingly, an edge database must support the management of decentralized data flows. There is no more efficient way than at the database level. This includes a range of conflict resolution strategies due to the decentralized and multi-directional structure of the Edge.

Data security and protection is an increasingly important issue and can quickly become a showstopper for Edge projects. Edge database need to ensure that data is secured in every state (at rest, in transit, in use).

When do you need an edge database?

Most IoT applications need to store and synchronize data. An edge database is always useful when functions / applications are planned that:

should work offline and independent of an internet connection
need to guarantee fast response times
work with a lot of, possibly high-frequency data
need to serve many devices at the same time
need historical data

In addition, developers also often decide to use an edge database to save time and nerves, or to be able to react quickly and flexibly to future requirements.

Edge Database Use Case Example in Manufacturing

Today, you can find everything from low-frequency brownfield devices to high-frequency greenfield devices on a factory floor. As a rule, the machine controllers in use are not designed to store or transmit data. They usually lack not only the functionality, but also the resources to support this. Therefore, additional edge devices are often needed to collect, analyze and interpret the huge amounts of data that each machine produces on site. For such an edge device, rapid data persistence and ingestion, and efficient data flow from edge-to-edge and edge-to-cloud are at the heart of value creation. The clear separation of machine control and edge data processing unit ensures that there is no risk of unintentional interference with the machine controller. An edge device with a powerful edge database can support multiple use cases on the shop floor today:

1. Operational efficiency

Process optimization along the line to increase quality and reduce damage. When the first machine in a production line uses a new batch of material, i.e. in sheet metal processing, one of the first steps is to cut a sheet to the required size. At this stage, the machine can already detect the differences in the metal compared to a previous batch (deviations are allowed within the DIN standard). With an Edge device this data can be evaluated, and the relevant information passed on to the next machine. With this data machines further down the line can avoid damage / breakpoints of the material.

2. Condition monitoring

Continuous machine condition monitoring reduces downtime and increases maintenance efficiency. A constant stream of high-frequency machine data is compared against the fingerprint of the machine. Any slight deviation is immediately detected and reported. Catching deviations early reduces down-times and costly repairs.

3. Historical Data

Historical data is stored for learning and training to optimize the production line. With an edge database, the data is persisted and thus available in the event of faulty behavior. In case of an error, the data preceding the incident can be analyzed and used to find the causes and predict, or even avoid, such an error in the future. Chances are that “fuzzy expert knowledge” already available at the production site can be translated into deterministic rules when tested with these data sets.

Edge Database and the edge ecosystem – an outlook

Edge computing brings many advantages, and enables many applications and functionalities that can only be realized by computing on the edge. Up to now, however, only a few (usually large) players have been able to create value in edge computing projects, and thus gain competitive advantages. One reason is the lack of basic software for the edge. A thriving edge ecosystem requires edge software infrastructure that solves the basic recurring requirements of edge projects. Edge databases are an important building block on the way to such an ecosystem.

Check out the ObjectBox Edge Database on GitHub

Dart Flutter Database ObjectBox 1.0 Release

by Vivien | May 18, 2021 | Mobile Database, ObjectBox, Release

In 2019 we first introduced the ObjectBox database v0.1 for Flutter/Dart. Our team has loved the engagement and feedback we’ve received from the developer community since, and we’re thrilled to announce the first stable version 1.0 for ObjectBox Dart/Flutter today.

With this release we bring you the fast and easy to use ObjectBox database for Dart objects: optimized for high performance on mobile and desktop devices. ObjectBox persists your Dart objects (null safe, of course) and comes with relations, queries, transactions, and Data Sync. For a feature list and more, please also check the pub.dev page.

ObjectBox by Example

For those of you new to ObjectBox, here is how you can use it (or check the docs if you want to dive deep right away). By annotating a class with @Entity you tell ObjectBox that you want to persist its objects, which is done putting the object in a Box:

@Entity()
class Person {
  int id = 0;
 
  String firstName;
  String lastName;
 
  Person(this.firstName, this.lastName);
}
 
// Open a Store once and keep it open to get type specific Boxes
final store = Store(getObjectBoxModel());
final box = store.box<Person>();
 
// let’s put a new Person in the database
var person = Person("Marty", "McFly");
final id = box.put(person);

@Entity()

class Person {

int id = 0;

String firstName;

String lastName;

Person(this.firstName, this.lastName);

}

// Open a Store once and keep it open to get type specific Boxes

final store = Store(getObjectBoxModel());

final box = store.box<Person>();

// let’s put a new Person in the database

var person = Person("Marty", "McFly");

final id = box.put(person);

What’s new with the 1.0?

Version 1.0 delivers a stabilized API and adds new essential features like async writes and query streams. We’ve also extended support for Flutter desktop. Let’s look at queries and how they can be used depending on the use case:

 // find all people whose name starts with "Mc"; 1. Query variant
Query<Person> query = box.query(Person_.firstName.startsWith("Mc")).build();
List<Person> people = query.find();
 
// 2. variant: "watch" the DB for any changes in the entity, then rerun the query
Stream<Query<Person>> watchedQuery = query.watch();
// You can then .listen(), or for example add the query to a StreamBuilder to show on UI.
_controller.addStream(watchedQuery.map((Query<Person> q) => q.find()));
 
// 3. variant: stream data from (non-trivial) queries:
Stream<User> resultStream = box.query().build().stream();
await stream.forEach((Person person) => print(‘${person.firstName} ${person.lastName}’));

// find all people whose name starts with "Mc"; 1. Query variant

Query<Person> query = box.query(Person_.firstName.startsWith("Mc")).build();

List<Person> people = query.find();

// 2. variant: "watch" the DB for any changes in the entity, then rerun the query

Stream<Query<Person>> watchedQuery = query.watch();

// You can then .listen(), or for example add the query to a StreamBuilder to show on UI.

_controller.addStream(watchedQuery.map((Query<Person> q) => q.find()));

// 3. variant: stream data from (non-trivial) queries:

Stream<User> resultStream = box.query().build().stream();

await stream.forEach((Person person) => print(‘${person.firstName} ${person.lastName}’));

There are two new approaches to do async puts for asynchronous database writes: putAsync() returns a Future to check if the call was successful.

Future<int> idFuture = box.putAsync(person);
...
final id = await idFuture;
userBox.get(id); // after the Future completed, the object is stored in the database

Future<int> idFuture = box.putAsync(person);

...

final id = await idFuture;

userBox.get(id); // after the Future completed, the object is stored in the database

Or you can use a background queue if you don’t need individual Futures, the following code inserts 100 objects and only waits once:

for (int i = 0; i < 100; i++) {
  box.putQueued(Person(...));
}
store.awaitAsyncSubmitted();
// after `awaitAsync*`: objects are inserted
expect(box.count(), equals(100));

for (int i = 0; i < 100; i++) {

box.putQueued(Person(...));

}

store.awaitAsyncSubmitted();

// after `awaitAsync*`: objects are inserted

expect(box.count(), equals(100));

If you are interested in further improvements we made to 1.0, please check out the full changelog.

Dart Flutter Database Benchmarks

ObjectBox Dart v1.0 also comes with considerable optimizations bringing a new level of database performance to Flutter apps. ObjectBox enables data-heavy apps that were not possible on Flutter before. Consider this a first sneak-peek; stay tuned for detailed performance benchmarks to be released including queries (hint: they are really fast) along with updated benchmarking code.

What we tested

We looked at some two popular approaches: sqflite, a SQLite wrapper for Flutter (no Dart Native support), and Hive, a key-value store with Class-adapters which seems still popular although its creator abandoned it for architectural shortcomings (it has memory problems and does not support queries). In the previous benchmark we’ve also had a look at Firestore, but being an online-only database it was thousands of times slower than the rest so we’ve left it to rest this time around. Check our previous benchmark if you’re interested.

To get an overview of the databases, we tested CRUD operations (create, read, update, delete). Each test was run multiple times and executed manually outside of the measured time. Data preparation and evaluation were also done outside of the measured time.

ObjectBox, sqflite, Hive performance comparison across CRUD

Looking at the results, we can see ObjectBox performing significantly faster than sqflite across the board, with up to 100 time speed-up in case of create & update operations. Compared to Hive, the results are a little closer in some cases (read) though ObjectBox still comes out on top in all the metrics. Considering that Hive keeps all Dart objects in memory (!) while ObjectBox does not, should give you a good impression of how fast object persistence with ObjectBox is.

ObjectBox Database for Flutter/Dart Highlights

For those of you new to ObjectBox, here’s a quick summary of what our super-fast embedded database offers, out of the box:

automatic schema migration: adding new classes or fields just works
type-safe APIs, e.g. no interface{} arguments
embedded edge database – no server needed, store all data directly on the device
no ORM, no SQL
relations: to-one, to-many (eager and lazy fetching)
robust query support, including indexes for scalable lookups
Support for implicit (automatic) and explicit (user defined)
transactions: ACID compliant with superfast bulk/batch operations
low memory usage
runs across operating systems: 64-bit Linux, macOS, Windows, small 32-bit ARM-based Linux devices (e.g. Raspberry Pi)
Data Sync: an efficient and easy way to synchronize data between your app and the cloud

Getting Started with ObjectBox for Flutter/Dart Today

ObjectBox is free to use and you can get started right now via the docs, pub.dev or GitHub, or this getting-started video tutorial, or getting-started article.

We ❤️ your Feedback

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 – sqflite, hive, ObjectBox, and Moor

by Vivien | Feb 3, 2021 | Android, Mobile Database, ObjectBox, Open Source, SQlite, Sync

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

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

by Vivien | Feb 3, 2021 | Android, Mobile Database, ORM, Sync

Data Sync is one of the typical challenges a developer faces. Synchronizing data is hard. While JSON / REST are great tools, 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.

Introduction

Firebase is one of the most well-known data sync solutions. Therefore, 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. 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. Accordingly, we limit our review ofnthe cloud-based Data Sync offerings to the most prominent cloud services. However, we add all edge / offline Data Sync solutions we know of to the review.

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 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. The same year 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 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). Typically that means that data synchronisation is only a small part of the whole offering. However, we solely focus on that 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 & 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.

ObjectBox Dart/Flutter v0.11 Database: Performance & Relations

by Markus | Feb 2, 2021 | Benchmarks, Mobile Database, ObjectBox, Release | 4 comments

Flutter Databases are few. Therefore, we’re happy to take a big step towards 1.0 with this ObjectBox Dart v0.11 release, improving performance and bringing the much-desired relations support known from other ObjectBox DB language bindings to Dart/Flutter.

For those of you new to ObjectBox: ObjectBox is a superfast NoSQL object database for Flutter / Dart and here is how you can save data in your Dart / Flutter apps:

@Entity()
class Person {
  int id;

  String firstName;
  String lastName;
}

final store = Store(getObjectBoxModel());
final box = store.box<Person>();

var person = Person()
  ..firstName = "Joe"
  ..lastName = "Green";

final id = box.put(person);  // Create

person = box.get(id);        // Read

person.lastName = "Black";
box.put(person);             // Update

box.remove(person.id);       // Delete

// find all people whose name start with letter 'J'
final query = box.query(Person_.firstName.startsWith('J')).build();
final people = query.find();  // find() returns List<Person>

@Entity()

class Person {

int id;

String firstName;

String lastName;

}

final store = Store(getObjectBoxModel());

final box = store.box<Person>();

var person = Person()

..firstName = "Joe"

..lastName = "Green";

final id = box.put(person); // Create

person = box.get(id); // Read

person.lastName = "Black";

box.put(person); // Update

box.remove(person.id); // Delete

// find all people whose name start with letter 'J'

final query = box.query(Person_.firstName.startsWith('J')).build();

final people = query.find(); // find() returns List<Person>

To learn about more ObjectBox features, like relations, queries and data sync, check our ObjectBox pub.dev page.

How fast is ObjectBox Dart? Performance Benchmarks

Speed is important for data persistence solutions. Accordingly, we wanted to test how ObjectBox compares performance-wise to other Flutter Dart database options. Therefore, we looked for libraries with comparable levels of storage abstraction and feature set – so not just plain SQL/Key-value storage but also ORM-like features. There doesn’t seem to be that much choice…

We looked at some two popular approaches: sqflite a SQLite wrapper for Flutter (no Dart Native support), and Hive, a key-value store with Class-adapters which seems still popular although its technology is phased out (see below). As a third alternative we pulled in Firestore, which does not really fit as it is no local database, but would be fun to compare anyway.

What we tested

To get an overview of the databases, we tested CRUD operations (create, read, update, delete). Each test was run multiple times and executed manually outside of the measured time. Data preparation and evaluation was also done outside of the measured time.

We tried to keep the test implementations as close as possible to each other while picking the approaches recommended by the docs for each database. We open sourced the test code at https://github.com/objectbox/objectbox-dart-performance if you want to have a closer look.

Performance Benchmark Results

Looking at the results, we can see ObjectBox performing significantly faster than sqflite across the board, with up to 70 times speedup in case of create & update operations. Compared to Hive, the results are a little more varied, with Hive being faster at reading objects than ObjectBox (we come to that later in our outlook), and ObjectBox being faster at creating objects, about four times faster at updates and three times for deletes. As a mostly-online database, it becomes clear that Firestore’s performance is not really comparable.

Implementation notes

ObjectBox: This release largely boosted the performance. The remaining bottlenecks are due to Dart itself and how it allows to modify byte buffers. There’s potential to double the speed if we look at other languages supported by ObjectBox. And if that’s not happening soon, we’d still have the option to do some low-level hacks…

Sqflite: a wrapper around SQLite, which is a relational database without direct support for Dart objects. Each dart object field is mapped to a column in the database, as per sqflite docs, i.e. converting between the Dart class and a Map.

Hive: We’ve tested with the latest Hive release, which is technically discontinued. The author hit two architectural roadblocks (RAM usage and queries) and is currently in the process to do a rewrite from scratch.
Update: strictly speaking it’s not straightforward to directly compare e.g. ObjectBox vs. Hive. 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.

Firestore: This is totally apples and oranges, but we still decided to include Firebase/Firestore as it seems at least somewhat popular to “persist data”. It’s quite Cloud centric and thus offers limited offline features. For example, in order to use batches (“transactions”), an internet connection is required to “commit”. Also, due to its low performance, the test configuration was different: batches of 500 objects and only 10 runs.

Test setup

We ran the benchmarks as a Flutter app on a Android 10 device with a Kirin 980 CPU. The app executed all operations in batches of 10.000 objects, with each batch forming a single transaction. Each test was run 50 times, averaging the results over all the runs. This ensured the VM warmup (optimization) during the first run and garbage collections don’t affect the overall result significantly. (We care about accurate benchmarks; read more about our benchmarking best practices here.)

Outlook

With this latest release, we’re not far away from a stable API for a 1.0 release (🎉), so please share your thoughts and feedback. For the next release, we’ll add features like async operations, more relation types and some smaller improvements. We are also working on an ObjectBox variant for the Web platform that is planned close to the 1.0 release. And of course there is ObjectBox Data Sync for Flutter/Dart. If you want to be first in line to try, drop us a line, we can put you on the shortlist.

ObjectBox Swift 1.4 – In Relation to…

by Markus | Sep 8, 2020 | ObjectBox, Release, Swift

ObjectBox for Swift 1.4 makes object relations more natural and intuitive for Swift developers. For example, let’s take the teacher-student relation to Swift and how you store objects in the database. Let’s say “Teacher” is a Swift class that has a collection called “students”. Now let’s say we have a new teacher with new students and want to store them in the ObjectBox database. It’s done like this:

let yoda = Teacher(name: "Yoda") yoda.students.append(Student(name: "Luke")) yoda.students.append(Student(name: "Anakin")) try box.put(yoda)

This is pretty much standard Swift. A single put command is enough to store all three new objects in the database (sorry for the “try”, Yoda, but you know, IO…). Now let’s see how this works. The students’ property in the Teacher’s class is of type ToMany<Student> and works like any Swift collection. This is because ToMany implements the protocols RandomAccessCollection and RangeReplaceableCollection. Under the hood however, it tracks all changes. Thus, when ObjectBox is instructed to put Yoda in a box, it also knows that two students were added. It also knows that our two Jedi students are new and thus puts them in database too. If you supply students that have been already persisted, it won’t put them. You can also mix new and existing objects.

Version 1.4 does not only bring TooMany (sic) improvements, but also brings a couple of new features, e.g. a bulk-get and read-only stores. You also may have heard of Sync (some kind of teleportation for objects, my young padawan). We’re still working on that, but we started to expose the Sync API with this release. It doesn’t come with any (space consuming) implementation so it’s really about getting early awareness and feedback. A full changelog is available at the docs.

So, time to start your (cocoa) pod again and let us know what you think. May the for… um, OK, that’s getting too many references for one article. One to many.

« Older Entries

Edge Databases – from trends to use cases

Table of Contents

The trends driving the megashift to decentralized Edge Computing

Needed: Software infrastructure for Edge Computing

Need for fast local data storage

Need for reliable on-device data flows

Need for edge-to-edge-to-cloud data flows

Need for flexible edge data management

What is an edge database?

When do you need an edge database?

Edge Database Use Case Example in Manufacturing

1. Operational efficiency

2. Condition monitoring

3. Historical Data

Edge Database and the edge ecosystem – an outlook

ObjectBox by Example

What’s new with the 1.0?

Dart Flutter Database Benchmarks

What we tested

ObjectBox Database for Flutter/Dart Highlights

Getting Started with ObjectBox for Flutter/Dart Today

We ❤️ your Feedback

Flutter databases / Flutter Dart data persistence

What is a database?

What are the major types of databases?

What is an ORM?

The Flutter Dart data persistence landscape

What is the best Flutter Dart database?

Flutter Database performance benchmarks

Performance Benchmark Test Setup

Flutter Databases CRUD Performance Results

Summary of the Flutter Dart DB Benchmarks

Flutter and Data persistence landscape Conclusion

Introduction

Firebase

Firebase Pros and Cons

Firebase Advantages ++

Firebase Disadvantages —

Firebase Advantages ++

Firebase Disadvantages —

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

Data Sync Solution comparison matrix – Firebase and its alternatives

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

How fast is ObjectBox Dart? Performance Benchmarks

What we tested

Performance Benchmark Results

Implementation notes

Test setup

Outlook