DEV Community: ObjectBox.io

Flutter Databases: 2023 review

ObjectBox.io — Mon, 05 Jun 2023 14:06:51 +0000

As Flutter is regarded as one of the most loved mobile frameworks of 2022, the Flutter database scene is thriving too. With an ever-growing market that does not seem to be slowing down, it might be difficult to decide on what database you should use. You can find anything you want from packages that provide plugins to familiar relational databases (Sqflite), to light-weight and high-performance NoSQL databases (ObjectBox).

What should you consider when choosing a Flutter database?

There are a number of factors that you should keep in mind when selecting a database for your flutter project. Although what factors are important to you might differ depending on your particular project, there are a few indicators that are invaluable no matter the app you are building.

Speed: Performance is a crucial factor when selecting a database. It not only makes sure you have data when you need it, it saves costs and avoids downtime. For example, a strong response rate on a website can go as far as sales: 70% of respondents in a study noting that page speed impacts their willingness to buy from an online retailer.
Ease-of-use: With constant pressure to deliver new apps and / or features, most developers care a lot about the eas-of-use. Depending on your skills or the team’s skill set, choosing a database that comes with native-language APIs that are intuitive to use, will save you a lot of time and nerves short-and longterm. While SQL is still a popular language, it is an additional skill needed, and inot a great match for object-oriented code.
Scalability: Even though a project may not have a lot of requirements at the moment, it can grow quickly. Having a database that ensures a capacity to grow with your data and user base can be vital to ensure long-term success.
Data Sync: Local databases are great, but sometimes you need your data to sync between systems that are far from each other. You also need to automate an update process that maintains consistency in order to meet your business needs. Almost every mobile application will need data synchronization, but it takes a lot of time as well as introduces a lot of risk. A database that comes with a Sync solution out of the box is a no-brainer in this regard.

{Aside: a word about data sync}

If data-synchronization is your priority, ObjectBox Sync is a next-gen solution equipped to manage data flows and harmonize data across devices, offline as well as online. Discover the easy to use alternative for syncing data – and simply rely on the data being available where you need it when you need it. Sync is a transactionally safe way of making the data sets you select reliably available in a highly efficient way.

What kind of databases exist?

Databases can be classified into various types. The most significant differentiations for our purposes include non-relational (NoSQL) versus relational (SQL) databases, cloud databases versus edge databases, and embedded versus in-memory databases. However, databases can also be distinguished based on additional criteria such as supported data types and scalability, although definitions may vary.

Is an ORM a database?

An Object Relational Mapper (ORM) is not a database itself but rather a layer that sits on top of a database, simplifying its usage. This is particularly relevant when working with relational databases (SQL) and object-oriented programming languages like Dart. It helps bridge the gap between the object-oriented nature of the programming language and the relational structure of the database.

Flutter database landscape in 2023

Let's introduce the key players in the current Flutter database market:

Sqflite serves as a wrapper around SQLite, a relational database that lacks direct support for Dart objects.
Drift (formerly known as Moor) is an ORM built on top of SQLite, which itself is a well-established lightweight relational (SQL) database.
Floor is another ORM that utilizes SQLite as its underlying database.
Isar is a fast and lightweight NoSQL database developed by the author of Hive.
Sembast is a NoSQL database.
Realm is a lightweight NoSQL database primarily written in Java, which was acquired by Mongo DB in 2019.
ObjectBox is a highly performant lightweight NoSQL database with integrated data synchronization capabilities.

Note: Since Hive is expected to be deprecated according to its author, we will focus on Isar as the recommended alternative in this discussion.

Package name	Package Description	Data Model	Data Sync	Language
sqflite	SQLite plugin for Flutter	relational	❌	SQL
Drift	ORM on top of SQLite	relational	❌	SQL
Floor	ORM on top of SQLite	relational	❌	SQL
Isar	Lightweight NoSQL database	NoSQL	❌	Dart
Sembast	NoSQL database, fully document-based	NoSQL	❌	Dart
Realm	NoSQL database	NoSQL	Yes, but MongoDB Atlas and Cloud are needed	Dart
ObjectBox	Lightweight NoSQL database + Sync	NoSQL	✅	Dart

How to choose the best Flutter database?

In conclusion, the Flutter database market is a dynamic and evolving landscape, with new options continually emerging. Choosing the best database option for a Flutter project requires careful consideration of specific project requirements and objectives. In this article, we have reviewed the top options currently available so that you can have a handy reference to the most important tech features. We encourage you to stay informed and check for updates on pub.dev, as well as contribute to the community.

Picking a Database for Embedded Systems

ObjectBox.io — Thu, 30 Jun 2022 12:46:00 +0000

Exploring Today's Embedded Database Marketplace

With the increasing demand for higher computing capabilities, embedded databases are becoming more important in today's technological landscape. The market for embedded systems is expected to grow from USD 100.33 billion in 2020 to USD 137.7 billion by 2028.

"Embedded" in the database world

The term "embedded" can have two different meanings when talking about databases:

"Embedded database" means that the database is deeply integrated into the software and does not require a server. Also known as an "embedded database management system”( or embedded DBMS for short)
A "database for embedded systems" is a database designed specifically for use in embedded systems. These are systems made up of tightly integrated hardware and software, such as electronic control units (ECUs), Internet of Things (IoT) devices, or smartphones. A database for such systems must be small and optimised to run on low-resource hardware (e.g. restricted CPU, memory, battery). In these use cases, a high-performance database is usually a top priority to get the most out of these restricted devices.

The fact that these terms are used interchangeably may cause some confusion. Not all embedded databases are appropriate for use in embedded systems, and databases used in embedded systems are not necessarily embedded in software. Maintaining a clear distinction between these terms is therefore important.

So, What is an Embedded System Exactly?

Embedded systems are ubiquitous today. They are used in most industries, ranging from manufacturing and healthcare, to automotive and consumer electronics. An embedded system is essentially a collection of hardware and software components that are designed to process and control the system's specific tasks. These components include processors, controllers, input-output devices, outer peripheral devices, and many others. Embedded systems are typically limited in terms of CPU, power, memory, and connectivity (WiFi, Bluetooth, ZigBee, and so on). The definition, however, is not linked to hardware constraints, and the landscape is generally heterogeneous.

Embedded systems are frequently components of larger systems, and each embedded system performs a limited number of specific functions within the larger system. Embedded systems, in essence, form a complex decentralised system. ECUs (in cars)smartphones, microcontrollers, cameras, smart watches, ATMs, robots, sensors and many more are examples of embedded systems.

Edge Databases: “Embedded Database” AND “Database for Embedded Systems”

Because embedded systems frequently have limited resources and are often found in decentralised systems with limited bandwidth, or intermittent or no connectivity , the efficiency and footprint of the local storage alongside smart and efficient data synchronisation are critical. These requirements spawned a new market for databases designed specifically for embedded systems. Embedded databases may often be useful in embedded systems due to their light weight and high performance.

Edge Databases are typically embedded databases optimised for resource efficiency on restricted decentralised devices (typically embedded devices) with limited resources. New Edge databases solve the challenge of an insanely growing number of decentralised embedded devices, both in the professional / industrial as well as the consumer world. Edge Databases solve data synchronisation out-of-the-box, making the data from these devices easily and efficiently accessible.

Why Would You Use an Edge Database in an Embedded System?

To begin with, local data storage enabled by embedded databases is a significant benefit for typical embedded systems that frequently face connectivity issues (due to device, use case, data protection needs, location, or costs) or operate in real-time scenarios (e.g., on the factory floor or in the car). Because of the limited connectivity or real-time requirements that these systems frequently face, they cannot always be relied on to retrieve data from the cloud. Instead, a clever solution is to keep data on the device locally and only sync it with other parts of the system when necessary and possible.

In addition to handling a lot of data, embedded systems frequently operate with erratic or intermittent connections. So, an effective synchronisation solution should not only sync data whenever a connection is available but empower the developers to choose which data to synchronise when and, moreover, do so as efficiently as possible (minimising data traversal, enhancing speed). For instance, differential sync is effective because it reduces network costs and unnecessary energy use (and thus CO2 emissions) by only sending changes to the server.

The two most important features of databases in embedded systems are performance and reliability. A database designed for use in embedded systems should perform well on devices with limited CPU and memory. This is why embedded databases may perform well in embedded systems; they are largely designed to function in such environments. Because some of them are truly tiny, they thrive in small applications. While improving performance helps to eliminate some risks, it does not help with unexpected power outages. Therefore, a good data recovery procedure is also important.

Let's have a look at the features of embedded databases that make them a great choice for embedded systems.

The Benefits of Embedded Databases

High performance: True embedded databases benefit from a simpler architecture because they don't require a separate server module. Although the client/server architecture benefits from the server's ability to be installed on a more powerful computer, there is an inherent risk that also rises. By removing the client/server communication layer, you can reduce complexity and improve performance.
Reliability: Because many embedded devices run on battery power, a power outage is a possibility. As a result, the data management solution should be designed to ensure that data is completely recovered in the event of a power outage. This is a popular feature of embedded databases designed specifically for embedded systems.
Ease of use and low maintenance: Another significant advantage of using an embedded database is its ease of implementation and small support requirements. Because designing embedded devices frequently necessitates working under time constraints, choosing an out-of-the-box data persistence solution is the best option for many projects. Because embedded databases are directly embedded in the application, they do not require administration and can manage themselves effectively.
Small footprint: Embedded databases aren't always small, but some are as small as 1 MB, making them ideal for mobile and IoT devices with limited memory.
Scalability: As the number of embedded devices grows, so does the volume of data. A good solution should be able to handle large amounts of data as well as adapt to new device features and easily change to meet the needs of a new device. Rigid database schemas fall short in this regard.

How to Choose an Embedded Database

The following are the most important factors to consider when selecting an embedded database: ACID (atomicity, consistency, isolation, durability) compliance, CRUD performance, footprint, and data sync.

An In-Depth Examination of the Embedded Database Market

Database solution	Primary model	Minimum footprint	Sync	Languages
Berkeley DB	NoSQL database; key-value store	<2MB	No	C++, C#, Java, Perl, PHP, Python, Ruby, Smalltalk and Tcl
Couchbase Lite	NoSQL DB; document store	1-5MB	Sync needs a Couchbase Server	Swift, Objective-C, Java (Android), Java (Non-Android), Kotlin, C#, JavaScript, C
extremeDB	In-memory relational DB, hybrid persistence	< 1 MB	No	C, C#, C++, Java, Lua, Python, Rust
LMDB	Key-value store	<1MB	No	C++, Java, Python, Lua, Go, Ruby, Objective C, Javascript, C#, Perl, PHP, etc
Mongo Realm	Object-oriented NoSQL database	5 MB+	Sync only via Mongo Cloud	Swift, Objective-C, Java, Kotlin, C#, and JavaScript
ObjectBox	Object-oriented NoSQL database	<1MB	Offline Sync, on-premise Sync, Cloud Sync, p2p Sync is planned	C,C++, Java, Kotlin, Swift, Go, Flutter / Dart, Python
RocksDB	Key-value store		No	C++, C, Java, Python, NodeJS, Go, PHP, Rust, and others
SQLite	Relational	<1MB	No	C/C++, Tcl, Python, Java, Go, MATLAB, PHP, and more
UnQLite	NoSQL; document & key-value store	~ 1.5 MB	No	C/C++, Python

Selecting an Embedded Database

Several factors must be considered when selecting a database for an embedded system. On highly restricted devices, even small changes in one of these parameters can have a big impact. Even minor variations in one of these parameters can have a significant impact on highly restricted devices. While developing your own solution with a specific device in mind may be feasible, the additional effort and tight deadlines usually do not justify this decision. This is why we recommend using a database, such as ObjectBox, which is designed for embedded system specifics with the added bonus of an efficient data sync solution.

There are several embedded databases that work well on embedded devices. Each has advantages and disadvantages, so you must decide which is best for your application. However, if you have a use case where performance is especially important, ObjectBox outperforms all competitors across all CRUD operations (Create, Read, Update, Delete). ObjectBox is a next-generation infrastructure software for Edge Computing. In addition to fast local data storage, it enables decentralised secure data flows and combines flexible data management with on-device security. You can assess it for yourself by looking at our GitHub profile and performance benchmarks.

Database for syncing cross platform

ObjectBox.io — Fri, 25 Mar 2022 12:10:14 +0000

How Data Sync works - quick video demo

ObjectBox Database + Data Sync is a Mobile and IoT solution for fast and effortless data access using Edge Computing. Our easy native APIs (Java, Kotlin, Flutter / Dart, C / C++, Swift, Golang) are built for cross platform development. The ObjectBox database can be set up in minutes, and is also free and easy to use.

This tutorial will show you how to set up ObjectBox Sync in C++, Go and Java, and then sync data between three instances of an example app. The app we are going to use is for managing a to-do list, its functionality is very simple. User can add tasks to the list and mark them as done, while ObjectBox takes care of syncing this data across platforms.

Note: if you haven't used ObjectBox DB yet, here are the docs for each language binding: Java/Kotlin, C/C++, Flutter/Dart, Go, Swift.

A couple of notes about the example

To follow this tutorial, you need to get your own copy of the Sync Server (available as an executable for Linux and as a Docker container). You can apply for a free Sync Trial here. You will only need to start the server once, but we included a step about it in for all three examples. Skip those if you already have a server running.
As this is just an example, we opted for no authentication to make things simple. This is not what you would use in production. We currently offer two authentication methods: shared secret and Google Sign-In. Here is the section about authentication options in the Sync docs.
If building your own solution, you will have to make sure that the UIDs in the model JSON file are the same across all of your apps. More details about UIDs in the Sync docs.

How to run the example apps

C++ example app

Example code repository

Video tutorial

Requirements

New to C++? Here is our tutorial covering the installation basics.

WSL Ubuntu
CMake
Git
C++
Clang

Step-by-step

Create CMakelists.txt:

include(FetchContent) 
FetchContent_Declare( 
objectbox 
GIT_REPOSITORY https://github.com/objectbox/objectbox-c.git 
GIT_TAG v0.15.2 
) 

FetchContent_MakeAvailable(objectbox) 

add_executable(myapp main.cpp) 
target_link_libraries(myapp objectbox-sync)

Configure and build the project using CMake: Configure (Clang), and then CMake: Build.
[if not running a server already] Start the ObjectBox Sync Server on Linux by running ./sync-server --model build/_deps/objectbox-src/examples/cpp-gen/objectbox-model.json --unsecured-no-authentication, where sync-server is the path to your sync server executable.
Now launch objectbox-c-examples-cpp-gen-sync, and the Sync Client will start automatically. You can see how it was implemented in main.cpp.
Add a new task (e.g. new task-cpp-1), and open the Admin UI to check if the tasks appears there. To do this, just type http://127.0.0.1:9980/ in any web browser.

Go example app

Example code repository

Video tutorial

Requirements

Go (see how to configure it for VS Code here)

Step-by-step

Clone the objectbox-go repository to your VS Code project. Make sure the current directory is objectbox-go.
This app is actually two examples in one: with sync and without. To run the one with sync, we need to enable the Task object for syncing: simply put // objectbox:"sync" on a new line in examples/tasks/internal/model/task.go.
Now we need to update the ObjectBox schema by running the generator: go generate examples/tasks/internal/model/task.go.
[if not running a server already] Now start the ObjectBox Sync Server: ./sync-server --model=examples/tasks/internal/model/objectbox-model.json --unsecured-no-authentication, where sync-server is the path to your sync server file.
Run go run examples/tasks/main.go.
Add a task (e.g. new task-go) and verify that it synced correctly with the server. Simply open http://127.0.0.1:9980/ in a web browser.

Java (Andorid) example app

Example code repository

Requirements

Java
Android Studio

Step-by-step

Open Android Studio and go to File → New → Project from Version Control to clone the objectbox-examples repository. Use this URL: https://github.com/objectbox/objectbox-examples.git
[if not running a server already] Start the ObjectBox Sync Server:
./sync-server --model android-app-sync/objectbox-models/default.json --unsecured-no-authentication, where sync-server is the path to your sync server file.
Run “android-app-sync” on a device of your choice.
Add a new task called, e.g. “task-java”. Open the Admin UI to check if the task appears there: http://127.0.0.1:9980/.

Next Steps

Now it's your turn. Build your own cross platform app using any combination of the supported languages. Don't forget to go the Sync docs when doing so. They cover all aspects that we've presented today in more detail.

We'd love to see what you've built with ObjectBox DB + Sync! Share your apps with us on Social Media by tagging @objectbox_io, or just send us an email on contact[at]objectbox.io.

How to get started with ObjectBox database in C++

ObjectBox.io — Thu, 03 Mar 2022 14:28:37 +0000

This tutorial is for anyone new to C++ who wants to get started with ObjectBox on Windows. It will help you install all the development tools needed to get going.

ObjectBox Database is a high-performant embedded database with integrated Data Sync to make it easy for app developers to store and sync data on and across embedded devices / edge devices in Mobile and IoT projects. By storing data systematically, you will always be able to access, manipulate and search for different entries in your app with ease.

We will start with setting up a Linux subsystem (WSL2) and installing some build tools, as well as CMake and Git. Then, we will compile ObjectBox and run a simple example app in Visual Studio Code.

Windows Subsystem for Linux (WSL2)

In this section, you will set up a simple Linux subsystem that you can use to build Objectbox in C++.

Install WSL (Note: this requires a reboot; it also configures a limited HyperV that may cause issues with e.g. VirtualBox).
Warning: to paste e.g. a password to the Ubuntu setup console window, right-click the title bar and select Edit → Paste. CTRL + V may not work.
(optional, but recommended) install Windows Terminal from Microsoft Store and use Ubuntu from there (does not have the copy/paste issue, also supports terminal apps better).
Choose Ubuntu from the dropdown menu in the Windows Terminal to open it in another tab.

Get the latest packages and upgrade:

sudo apt update
sudo apt upgrade

Install build tools:

sudo apt install build-essential git cmake ccache gdb
LLVM_VERSION=12
sudo apt install clang-$LLVM_VERSION clang-tools-$LLVM_VERSION clang-format-$LLVM_VERSION lldb-$LLVM_VERSION lld-$LLVM_VERSION clangd-$LLVM_VERSION
sudo update-alternatives --install /usr/bin/clang++ clang++ /usr/bin/clang++-$LLVM_VERSION 1000
sudo update-alternatives --install /usr/bin/c++ c++ /usr/bin/clang++ 1000
sudo update-alternatives --config c++
sudo update-alternatives --config clang++
sudo update-alternatives --install /usr/bin/clang clang /usr/bin/clang-$LLVM_VERSION 1000
sudo update-alternatives --install /usr/bin/cc cc /usr/bin/clang 1000
sudo update-alternatives --config cc
sudo update-alternatives --config clang
cc --version
c++ --version
sudo update-alternatives --install /usr/bin/clang-format clang-format /usr/bin/clang-format-$LLVM_VERSION 1000
sudo update-alternatives --install /usr/bin/scan-build scan-build /usr/bin/scan-build-$LLVM_VERSION 1000
sudo update-alternatives --install /usr/bin/ld ld /usr/bin/ld.lld-$LLVM_VERSION 50
sudo update-alternatives --install /usr/bin/ld ld /usr/bin/ld.bfd 10
sudo update-alternatives --config ld
ld --version

Install and compile ObjectBox C++ database using CMake

Now let's complete our setup by installing some useful extensions in Visual Studio Code. After this we can go straight into installing ObjectBox.

Within Ubuntu, make a new directory for our example and open it in Visual Studio Code:

mkdir objectbox-ex
cd objectbox-ex
code .

Install the following extensions:
Remote - WSL
C/C++
CMake Tools
Create CMakeLists.txt – a standard file for installing CMake projects. It is needed to get the ObjectBox source code from its Git repository and link the library to your project.

include(FetchContent) 
FetchContent_Declare( 
objectbox 
GIT_REPOSITORY https://github.com/objectbox/objectbox-c.git 
GIT_TAG v0.14.0 
) 
FetchContent_MakeAvailable(objectbox) 
add_executable(myapp main.cpp) 
target_link_libraries(myapp objectbox)

Create a main.cpp file with the following contents to verify the setup:

#include "objectbox.hpp"
int main() {
printf("Using ObjectBox version %s\n", obx_version_string());
}

Follow this guide for VS Code to select Clang as the compiler, configure and build ObjectBox. As a result, .vscode and build folders will be generated. This is how your directory should look like at this point:

Run the tasks-list example

Let's now run a standard ObjectBox example to see the database in action.

Click “Select target to launch” on the status bar and select myapp as the target. Then click “launch”: the app will output the correct ObjectBox version as shown in the screenshot.

Now you can run objectbox-c-examples-tasks-cpp-gen: a simple To-Do list app. Try exploring its functionality by looking at the source code to get a better idea of how ObjectBox database is used to store, get, and mark tasks as done. Here is what the output of the app looks like:

Done! Now you have everything you need to start working with ObjectBox. Check out the ObjectBox C/C++ API docs to find more about what you can do with this library. We'd love to see what you build, so don't be a stranger - share your projects and ideas with us via our Twitter and GitHub. You'd also help us a lot by sharing your opinion via this Feedback Form. Thanks!

Firebase / Firestore alternatives – solutions for data sync

ObjectBox.io — Thu, 11 Nov 2021 12:15:38 +0000

Syncing Data is hard. Every developer who has tried building their own solution knows this. Because of today’s growing data volumes, data sync is all the more relevant. Even with JSON / REST still being a good way to transfer data, the need for out-of-the-box solutions cannot be ignored. That's why this article will present you with the Data Sync solutions that might serve as good Firebase / Firestore alternatives.

Introduction
- What is Firebase?
- What is the difference between Firebase and Firestore?
A bit more about Firebase
- Firebase advantages
- Firebase disadvantages
Firebase alternatives
- List of alternatives
- Comparison matrix
ObjectBox Data Sync

Introduction to Firebase and Data Sync

While being one of the most popular solutions for data sync, Firebase has its own drawbacks. The biggest one is a lack of local data storage and offline access to it. This is where Edge Computing comes in, driving the shift from the cloud to the edge. We have already discussed the available edge database solutions that benefit from an offline-first approach. But what about syncing data on the edge? Right now, only a handful of Edge Data Sync solutions exist for Mobile and IoT developers. In this review of Firebase alternatives, we limit ourselves to a selection of the most well-known cloud-based Data Sync solutions. In addition, we include all the edge / offline Data Sync options that we know of.

What is Firebase?

Firebase is a development platform from Google that allows building mobile or web applications without needing to take care of the backend. Its backend cloud service, (M)BaaS, handles aspects like data synchronization, scalability, network, infrastructure challenges etc. The services offered on the platform go well beyond Data Sync (e.g. analytics, crashlytics), but we will look at Firebase from the Data Sync perspective only. Together with Parse and Couchbase, Firebase was one of the first three Data Sync solutions available on the market. All of them started in 2011. Three years later, in 2014, Firebase was acquired by Google and Parse was acquired by Facebook. Later, the Parse platform was open sourced and the server was shut down. All three are still in use today.

What is the difference between Firebase and Firestore?

Firebase is a development platform, and Cloud Firestore is one of the two cloud-based databases offered as a part of the platform, alongside their Realtime Database. So while Firebase stands for a wide collection of services, Firestore is a particular part of the offering.

A bit more about Firebase

Let us first have a look at the benefits and drawbacks of using Firebase. Then, we will compare Firebase with available alternatives, like Couchbase, Parse and ObjectBox, in a comprehensive matrix.

What are the Firebase advantages?

Google:
- large team that supports and maintains the product
- 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 Realtime Database has its own advantages:
- for pure online use cases rather fast
- great if you do not have a strong DB background
Pay as you go, price scales with usage

What are the 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 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
Cost insecurities, hard to impossible to predict
Less iOS support (stronger focus on Android)
Doesn’t work in countries that don’t allow Google
User privacy concerns¹

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

Most of the options for handling data synchronization as described here, are cloud-based backend services ((M)BaaS), platform services (PaaS) or database services (DBaaS). This usually means that Data Sync is not the primary product, but only one forms one part of a whole offering. However, we solely focus on that here.

What are the Firebase alternatives for data sync?

Cloudant Sync - a Cloud database based on CouchDB
Couchbase server & Sync Gateway - a NoSQL, document database
Mongo Realm Sync - Cloud DB and Cloud Sync
ObjectBox Sync - an object-oriented embedded NoSQL DB, offering offline and cloud sync
Parse - a cloud sync solution that works with a self-hosted server
Syncstudio - a relational database with a cloud-based sync
Zumero - a cloud-based replication of SQL data for Mobile

Data Sync solutions comparison matrix – Firebase and its alternatives

Solution name	Data Sync	Database	Cloud	License
Cloudant Sync	Two-way cloud data replication	Couch DB: NoSQL, distributed JSON document database	CouchDB <> cloud service	Proprietary (CouchDB is Apache 2.0)
Couchbase server & Sync Gateway	Sync needs a Couchbase Server	Edge: Couchbase Lite; Server: Couchbase. NoSQL, document database	Always needs Couchbase Server (originally Membase)	Apache 2.0, delayed open source
Firebase²	Cloud Sync via Google servers	Cloud: Firebase Realtime DB (document store); Edge: Caching only (Firestore)	hosted only	proprietary
Mongo Realm Sync	Sync (in Alpha); only via Mongo Cloud	Cloud: MongoDB (NoSQL document store), Edge: Mongo Realm (Embedded NoSQL)	hosted service	Server Side Public License (SSPL)
ObjectBox Sync	Offline Sync, on-premise Sync, Cloud Sync, p2p Sync is planned	Object-oriented embedded NoSQL DB	Self-hosted / on-premise; hosted service upon request only	Bindings - Apache 2.0, proprietary core
Parse	Cloud Sync, self-hosted or via a provider that offers Parse hosting	Can use MongoDB (NoSQL document store), or PostgreSQL³	Only Cloud, only self-hosted or via a provider that offers Parse hosting	open source, BSD
Syncstudio	Sync⁴	Edge: SQLite or MSSQL (including LocalDB or Express); Server: Microsoft SQL	SQL Server; Sync / replication works via cloud only	proprietary, 4 licenses available: Community/Free, Subscription, Perpetual and Royalty Free
Zumero	Sync	Edge: SQLite; Server: Microsoft SQL	SQL Server; Sync / replication works via cloud only	proprietary, annual license scaling with the number of devices

Check out a more detailed Firebase alternatives matrix, which also includes information about the supported platforms and programming languages of each solution.

Note: the term “Data Sync” is not standardized. Even though most developers know what it is and the term is used by a number of big companies, the reality is not that straightforward. If we have missed any other important solutions, let us know about them. Apart from that, if there are inaccuracies in our reasoning, please feel free to point them out. We appreciate your feedback.

Why you should choose ObjectBox as your Data Sync solution

ObjectBox is a high-performance NoSQL edge database that is fully ACID-compliant. It is built for efficient data on and across restricted and occasionally connected devices, taking care of keeping data in sync reliably. ObjectBox is optimized for economic resource use on edge devices running mobile, desktop, server, and IoT applications. Its developer tools are easy to use and quick to implement, because they were built with the developer experience in mind. You don’t need to take care of the boilerplate code for resilient connectivity, synchronizing data, and tedious DB optimizations. We strive to make the whole experience with us as seamless as possible: from implementation to maintenance, avoiding undesired problems, and data loss. This doesn’t only reduce stress, but also costs and time to market. We are dedicated to bringing joy and delight to Mobile and IoT application developers.

“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. ↩
There are many Cloud Sync alternatives to Firebase, we added the more prominent options and any service that also serves Edge Computing ↩
PostgreSQL vs Postgres ↩
Microsoft Sync Framework (renamed Sync Framework Toolkit at some point) is a legacy open source product which MS no longer supports ↩

Which Flutter database should you use?

ObjectBox.io — Fri, 05 Nov 2021 13:10:11 +0000

As Flutter continues to gain prominence, so does the need for efficient and reliable data management within Flutter applications. In May 2023, there are already over 1M Flutter apps published. This demand has given rise to a diverse range of Flutter database options, each offering unique features and capabilities. In this article, we delve into the landscape of Flutter databases, comparing the various options available.

Briefly about data persistence

When it comes to databases, the ones available for Flutter/Dart are just a small part of the overall database market. Before we jump into exploring the various Flutter database options, let's quickly refresh our understanding of databases to ensure we're all on the same page.

What is a database?

A database is a software for storing data long-term (data persistence) as opposed to short-term caching. This enables the systematic use of digital information. Data is stored continually unless deliberately deleted, in contrast to simple caching, where data is discarded regularly. Developers can manipulate the data stored in a database in different ways via an API: store, access, search, update, query, etc. Since these operations are done in the background, end users usually don’t see them. A large number of applications need to have a database in their technology stack. The most vital database operations are abbreviated as CRUD, which stands for Create, Read, Update, Delete.

What is an ORM?

Object relational Mapper (ORM) is a term that is often misused. It is not a database, but a layer that sits on top of it and makes the database easier to use. Typically, this is especially relevant for relational databases (SQL) when used with an object-oriented programming language like Dart.

What kind of databases are there?

Databases can be categorized in a number of different ways. For the purposes of this review, the most important distinctions are between:

cloud databases versus edge databases;
non-relational (NoSQL) versus relational databases (SQL);
embedded versus in-memory databases. Other criteria that databases can be distinguished by include supported data types and scalability – definitions can vary.

Flutter database options: SQLite, hive, ObjectBox, and Moor

The amount of databases available in the Flutter Dart data persistence landscape is still very limited. These are: Firebase Realtime DB, Hive, ObjectBox, sqflite, Moor. Please note that even though Moor is not a database, we included this ORM in our overview because the number of players on the market is so small that it is worth considering Moor as a separate player.

Shortly about the current Flutter database options:

Hive is a lightweight key-value database written in Dart for Flutter applications, inspired by Bitcask.
Floor is an object-oriented SQLite database wrapper for Flutter, inspired by Room, a similar library for Android.
Drift is a reactive persistence library for Flutter and Dart, built on top of sqlite.
ObjectBox Flutter DB is a high-performance lightweight NoSQL database that stores objects.
sqflite is an SQLite plugin for Flutter, which is a relational database without direct support for Dart objects.

What is the best Flutter database?

Determining the best Flutter database is subjective and varies for each individual. To assist you in making an informed decision, consider referring to the following comparison matrix as a starting point. However, it's important to note that due to the limited number of options available, comparing them can be akin to comparing different flavours of ice cream 🍦. Ultimately, the choice depends on your specific needs and preferences.

Name	ORM/Database	Storage Type	Data Model	Language
sqflite	SQLite plugin	SQLite	relational	SQL
Floor	ORM	SQLite	used on top of a relational DB	local
Drift	ORM	SQLite	used on top of a relational DB	Dart or SQL
ObjectBox	Database	File-Based	NoSQL	Dart
Hive	Database	File-based	NoSQL	Dart

Flutter Database performance benchmarks

As with any performance test, it is best to run Flutter Databases benchmarks yourself. Accurate results are very important for us and we take benchmarking very seriously. Please let us know if you note anything that does not even out in your opinion. We have been updating and improving our benchmarks for a long time 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.

CRUD Performance Results

Flutter Dart Database Benchmarks

Hive and ObjectBox clearly outperform sqflite across all CRUD operations. For create and update operations, the results show ObjectBox performing up to 70 times faster. When comparing Hive and ObjectBox, we can see the results varying 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.

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

The Flutter database landscape - Conclusion

Data persistence solutions for Flutter are becoming more important since Flutter grows so quickly as a developer platform. Only a few databases are now offered to the Flutter community on the market, so it will be interesting to see how this grows in the future. Through our comprehensive comparison, we have explored key criteria such as ORM support, storage type, data model, and the programming language used. By evaluating these factors and considering individual preferences, developers can make informed decisions to optimize data management and enhance the performance of their Flutter applications. Regularly staying updated with emerging options and community feedback will help you choose the most suitable Flutter database for future projects.

Flutter databases – sqflite, hive, ObjectBox, and Moor

ObjectBox.io — Wed, 03 Feb 2021 21:08:14 +0000

The post Flutter databases – sqflite, hive, ObjectBox, and Moor appeared first on ObjectBox.

ObjectBox Swift 1.0 Released

ObjectBox.io — Tue, 24 Sep 2019 12:53:04 +0000

ObjectBox Swift 1.0 is here! Since the first public alpha released 10 months ago, we’ve worked hard and made major changes to put Swift first, tune the performance, and iterate on the API. We hope you will love the result.

All of this, to bring you the features you expect from a database, but more importantly – the features that we think delight developers and sets ObjectBox apart from other databases out there. Let’s swiftly (cheap pun intended) dive into ObjectBox Swift 1.0:

Built with Swift in Mind

// objectbox: entity
class Olympian {
    var id: Id = 0
    ...
}

let store = try Store(directoryPath: dbURL.path)
let box = store.box(for: Olympian.self)
let olympians: [Olympian] = try box.all()
let goldMedalist: Olympian = try box.get(sarahHoefflinId)

ObjectBox isn’t just a database bolted onto Swift. Your database entities are regular Swift classes or structs that you devise. No need to subclass a particular class (as with CoreData’s NSManagedObject), nor to write tedious serialization code. 😊

All you need to do is add one property for the unique ID, build your project, and ObjectBox’s code generator will write a little bit of code for you, just like the Swift compiler does for Codable objects. All that’s left then, is to call a simple method like put() on the object to write it out:

try box.put(ruthJebet)

We’ve tried to keep this simplicity throughout the Swift binding, e.g. making it very easy to use any RawRepresentable enum without writing any conversion code.

Automatic Schema Migrations

A common chore with databases is schema migration. ObjectBox takes care of that. If you add a new property or class there are no additional migration steps required. Old objects will keep working, and new objects will be saved with the additional fields. Similarly, adding new classes will add them to the database without any error-prone migration steps.

Moreover, you do not need to maintain a dedicated schema, because your classes and structs are the schema in the first place.

Relations

class Author: Entity {
    var id: Id = 0
    var name: String
    var books: ToMany<Book> = nil

    ...
}

amandaPalmer.books.append(theArtOfAsking)
try amandaPalmer.books.applyToDb()

To ensure ObjectBox knows how to save object references, you use a wrapper class. Either ToOne or ToMany, instead of a straight reference or an array. This lets ObjectBox lazily load the related objects from the database, only when you’re actually accessing a related object.

The Swift 1.0 release brings you our complete set of relations: One-to-many, many-to-many, and their corresponding back-links. ToMany behaves just like any other Swift collection, you can add or remove objects as you please with your familiar methods like append().

Queries

let query = try box.query { Author.fname == "Jeaniene" }.build()
let results = try query.find() // All Authors matching query.
// All last names of the matching authors:
let names = try query.property(Author.lname)
                     .distinct().findStrings()

Of course ObjectBox lets you perform queries to collect data; either complete objects or individual properties (basic Swift data types).

But with ObjectBox you don’t mess around with query strings or unpack data from cursors. You simply write Swift expressions with function calls and operators you’re already used to.

Also, you get to keep the type-safety guarantees and compile-time checking. So you don’t have to spend hours figuring out why your query doesn’t return the proper results, just to discover you made a typo in a field name in a query string.

subscription = query.subscribe() { authors, error in
    if let error = error { self.reportError(error); return }
    self.authors = authors
    self.tableView.reloadData()
}

ObjectBox lets you then operate on these objects, watch a query for changes, retrieve the results, delete the objects matching a query etc. The source code even contains a file that adds Combine support so you can integrate with its pipelines to take advantage of Apple’s newest technology.

Open Source Swift Binding

If you’re curious how things work behind the scenes, feel free to check out the Swift source code. The source code for the Swift binding, as well as our code generator based on Sourcery, are available among other projects through our Github account.

How-to Get Started

It’s a matter of minutes to get started with ObjectBox. Check our setup instructions (based on CocoaPods) and jump right into code with the getting started guide.

Your Feedback. And what’s Next?

As always, we would love to hear your feedback! Do you like ObjectBox as much as we do? We put our hearts in this product and are excited to learn your thoughts: What features are you most excited about, what are we missing?

We haven’t written much about a topic very dear to us: performance. We will cover this in a follow up post. Also, look forward to our ObjectBox Swift 1.0 benchmarks, which we will release soon including the sources.

DEV Community: ObjectBox.io

Flutter Databases: 2023 review

What should you consider when choosing a Flutter database?

{Aside: a word about data sync}

What kind of databases exist?

Is an ORM a database?

Flutter database landscape in 2023

How to choose the best Flutter database?

Picking a Database for Embedded Systems

Exploring Today's Embedded Database Marketplace

"Embedded" in the database world

So, What is an Embedded System Exactly?

Edge Databases: “Embedded Database” AND “Database for Embedded Systems”

Why Would You Use an Edge Database in an Embedded System?

The Benefits of Embedded Databases

How to Choose an Embedded Database

An In-Depth Examination of the Embedded Database Market

Selecting an Embedded Database

Database for syncing cross platform

How Data Sync works - quick video demo

A couple of notes about the example

How to run the example apps

C++ example app

Video tutorial

Requirements

Step-by-step

Go example app

Video tutorial

Requirements

Step-by-step

Java (Andorid) example app

Requirements

Step-by-step

Next Steps

How to get started with ObjectBox database in C++

Windows Subsystem for Linux (WSL2)

Install and compile ObjectBox C++ database using CMake

Run the tasks-list example

Firebase / Firestore alternatives – solutions for data sync

Table Of Contents

Introduction to Firebase and Data Sync

What is Firebase?

What is the difference between Firebase and Firestore?

A bit more about Firebase

What are the Firebase advantages?

What are the Firebase disadvantages?

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

What are the Firebase alternatives for data sync?

Data Sync solutions comparison matrix – Firebase and its alternatives

Why you should choose ObjectBox as your Data Sync solution

Which Flutter database should you use?

Briefly about data persistence

What is a database?

What is an ORM?

What kind of databases are there?

Flutter database options: SQLite, hive, ObjectBox, and Moor

What is the best Flutter database?

Flutter Database performance benchmarks

Performance Benchmark Test Setup

CRUD Performance Results

Flutter Dart Database Benchmarks

The Flutter database landscape - Conclusion

Flutter databases – sqflite, hive, ObjectBox, and Moor

ObjectBox Swift 1.0 Released

Built with Swift in Mind

Automatic Schema Migrations

Relations

Queries

Open Source Swift Binding

How-to Get Started

Your Feedback. And what’s Next?