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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@Entity()
classPerson{
intid=0;
StringfirstName;
StringlastName;
Person(this.firstName,this.lastName);
}
// Open a Store once and keep it open to get type specific Boxes
finalstore=Store(getObjectBoxModel());
finalbox=store.box<Person>();
// let’s put a new Person in the database
varperson=Person("Marty","McFly");
finalid=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:
1
2
3
4
5
6
7
8
9
10
11
12
// find all people whose name starts with "Mc"; 1. Query variant
There are two new approaches to do async puts for asynchronous database writes: putAsync() returns a Future to check if the call was successful.
1
2
3
4
Future<int>idFuture=box.putAsync(person);
...
finalid=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:
1
2
3
4
5
6
for(inti=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.
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
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 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 DBis 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🍐.
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 🙂
Data Sync is one of the typical challenges a developer faces. Synchronizing data is not easy and while JSON / REST are great, building data sync yourself is challenging. Therefore, today, we take a look at the out-of-the-box data sync market. If you are rather interested learning about data sync in general, check out this article about why data sync technology is more necessary than ever.
As Firebase is one of the most well-known data sync solutions, we look at the market from a Firebase alternatives perspective. However, Firebase is purely cloud based and offers no support for local data storage and offline usage. With a huge shift happening in computing from the cloud to the edge, offline-first approaches and Edge Computing are getting more and more important. Reasons to move to the edge, include: Data Speed, Data Privacy/Security, Broadband Limitations, Network Costs, Cloud Costs, and User Experience. Therefore, we’ve recently taken a comprehensive look at mobile database and edge database offerings on the market, but what options do Mobile and IoT developers working on the edge have for out-of-the-box data synchronization solutions? Very few. As there is no lack of cloud-based offerings, we focus on the most prominent cloud services only, and add all edge / offline sync solutions, we are aware of, to our comprehensive comparison of data sync solutions.
Firebase
Firebase is a cloud backend service ((Mobile) Backend as a Service ((M)BaaS)) that enables developers to build mobile or web applications without needing to take care of the backend, which includes the data synchronization, scalability, network, infrastructure challenges etc. Firebase, today, offers many different services (e.g. analytics, crashlytics) and goes well beyond sync; we are looking at Firebase from the sync perspective only. Firebase was one of the first data sync solutions available on the market together with Parse and Couchbase, which all started in 2011 (Couchbase through a merger of CouchOne and Membase). In 2014, Firebase was acquired by Google, Parse was acquired by Facebook to be subsequently shut down, and Couchbase went on to raise funding. All three are still in use today.
Firebase Pros and Cons
In the following, we will look at the advantages and disadvantages of Firebase, and then compare Firebase with Firebase alternatives, like Couchbase, Parse and ObjectBox in a comprehensive matrix to give you a good overview of data sync options.
Firebase Advantages ++
Firebase Disadvantages —
Cloud based
Purely cloud based
Google: large team that supports and maintains it; very low risk of the company failing; however, Google has a reputation of discontinuing products / services, so there is no guarantee
Google: vendor lock-in (no migration tools prevents you from making your app portable), you cannot access your data as it is hosted on the Firebase server
Backend as a service (ease of use)
Less flexibility: You cannot optimize the backend to match your app’s needs
The Firebase Realtime Database has its own advantages:
hosted, powered by Google
for pure online use cases rather fast
great if you do not have a strong DB background
The Firebase Realtime Database has its own drawbacks:
the whole DB is a huge JSON file
limited querying capabilities
no way to efficiently filter data
Easily disorganized, hard to navigate and search
Pay as you go, price scales with usage
Cost insecurities, hard to impossible to predict
Less iOS support (stronger focus on Android)
Less iOS support (stronger focus on Android)
Doesn’t work in countries that don’t allow Google
User privacy concerns***
*** “Firebase has been claimed to be used by Google to track users without their knowledge. On July 14, 2020, a lawsuit was filed accusing Google of (…) logging what the users are looking at in many types of apps, despite the user following Google’s own instructions to turn off the web and app activity collected by the company.” (https://en.wikipedia.org/wiki/Firebase)anced settings.
Firebase Advantages ++
– Cloud based – Google: large team that supports and maintains it; very low risk of the company failing; however, Google has a reputation of discontinuing products / services, so there is no guarantee – Backend as a service (ease of use) – The Firebase Real-time Database has its own advantages: – Pay as you go, price scales with usage – Less iOS support (stronger focus on Android)
Firebase Disadvantages —
– Purely cloud based – Google: vendor lock-in (no migration tools prevents you from making your app portable), you cannot access your data as it is hosted on the Firebase server – Less flexibility: You cannot optimize the backend to match your app’s needs – The Firebase Real-time Database has its own drawbacks – the whole DB is a huge JSON file – limited querying capabilities – no way to efficiently filter data – Easily disorganized, hard to navigate and search – Cost insecurities, hard – impossible to predict – Less iOS support (stronger focus on Android) – Doesn’t work in the countries that don’t allow Google – User privacy concerns: “Firebase has been claimed to be used by Google to track users without their knowledge. On July 14, 2020, a lawsuit was filed accusing Google of (…) logging what the users are looking at in many types of apps, despite the user following Google’s own instructions to turn off the web and app activity collected by the company.” (https://en.wikipedia.org/wiki/Firebase)
Firebase alternatives: A look at out-of-the-box data sync solutions
The majority of offerings for developers that handle data synchronisation as defined here, are cloud-based and fall into the category of BaaS (can also be MBaaS (Mobile Backend as a Service) or PaaS (platform as a Service) or DBaaS (Database as a Service). Typically that measn that data synchronisation is only a small part of the offering. However, that is our sole focus here.
Data Sync Solution comparison matrix – Firebase and its alternatives
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.
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
@Entity()
classPerson{
intid;
StringfirstName;
StringlastName;
}
finalstore=Store(getObjectBoxModel());
finalbox=store.box<Person>();
varperson=Person()
..firstName="Joe"
..lastName="Green";
finalid=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'
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 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:
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.
According to the database of databases there are more than 700 databases as of 2021. However, that list does include hobby projects. DB-engines “only” lists databases that have significant traction and are well-maintained; they still count more than 300 databases as of 2021. However, only a handful of these databases are edge database.
What is an edge database?
An edge database is a database that runs directly on restricted devices locally. It is a local on-device database as opposed to a cloud database, resulting in significantly faster data. The term edge database is too young to have a Wikipedia article. However, we see it used in the IoT industry increasingly. In the field of IoT applications, it is especially important to distinguish databases that run locally on the device (“on the edge of the network”) and thus support Edge Computing from databases that run “in the cloud.” In our view, a mobile database is an edge database that runs on mobile devices, meaning the only difference between the terms edge database and mobile database is the operating system / device support they offer.
What is a mobile database?
While Wikipedia defines a mobile database as “Mobile computing devices (e.g., smartphones and PDAs) store and share data over a mobile network, or a database which is actually stored by the mobile device,” we solely refer to the latter ones as a mobile database. Meaning only databases that run on the mobile device (as the edge device) itself, locally, and store the data on the device. Therefore, we also refer to it as “on-device” database.
What is an edge device?
An edge device may be any device from a sensor, to an IoT gateway, to a car, to a Raspberry Pi, to a mobile phone (smartphone) to an on-premise server. Typically, the challenge arises when running on the smaller, more restricted devices. Generally, any database can run on a big on-premise server or cloud infrastructure with unlimited resources, but only few fit on a Raspberry Pi Zero. The other way around is no issue, meaning an edge databases can run well on a server. Therefore, in this comparison we look at databases that run on Raspberry Pi type size of devices (rule of thumb).
What are the advantages and disadvantages of working with SQLite?
SQLite is easily the most established edge database and probably the only “established” mobile database. SQLite is public domain and maintained by Richard Hipp. SQLite database has been around since the year 2000 and been embedded with iOS and Android since the beginning. SQLite is a relational database.
Advantages
Disadvantages
Toolchain, e.g. DB browser
No dependencies, is included with Android and iOS
Developers can define exactly the data schema they want
Developers have full control, e.g. handwritten SQL queries
SQL is a powerful and established query language, and SQLite supports most of it
Debuggable data: developers can grab the database file and analyze it
Rock-solid, widely used technology, established since the year 2000
Using SQLite means a lot of boilerplate code and thus inefficiencies (also in the long run with the app maintenance)
1 MB BLOB Limitation on Android
No compile time checks (e.g. SQL queries)
The performance of SQLite is unreliable
SQL is another language to master
SQL queries can get long and complicated
Testability (how to mock a database?)
Especially when database views are involved, maintainability may suffer with SQLite
What are SQLite alternatives?
There are plenty of alternatives to working with SQLite directly. If you simply want to avoid writing lots of SQL and boilerplate code, you can use an object abstraction on top of SQLite. This abstraction layer is usually an ORM (object/relational mapper), e.g. greenDAO. While an ORM makes it easy to use SQLite at the beginning, there typically comes a point “where you hit SQLite”; so even when using an abstraction layer you need to understand SQLite and SQL in the longrun.
However, if you rather seek a complete replacement for SQLite, there are a few alternative databases: Couchbase Lite, Interbase, LevelDB, ObjectBox, Oracle Berkeley DB (formerly Oracle’s mobile database was “Oracle Database Lite”), Realm (now Mongo Realm), SnappyDB, SQL Anywhere, and UnQLite.
Obviously, if your also looking for alternatives that run in the cloud, there are a lot of cloud / server options out there that you can use as a replacement like e.g. Firebase. Though, with these your app will not work offline, response rates will be slower than with an on-device database and cannot be guaranteed, and last not least you will have much higher networking / cloud costs. You can find out more about the benefits of Edge Computing.
To give you an overview, we have compiled a small comparison table:
Edge Database
Android / iOS*
Type of data stored
Sync Central
Sync P2P
Offline Sync
Data level encryption
License / business model
Short description
Minimum Footprint size
Company
Azure SQL Edge (in preview)
No
Relational DB
No
No
No
will provide encryption
Proprietary
Designed as a SQL database for the IoT edge; however, due to the footprint it is no edge database
If you are interested in an indication of the diffusion rate of databases and mobile databases, check out the following database popularity ranking: http://db-engines.com/en/ran.
Thanks for reading and sharing. Please let us know what you’re missing.
