SQLite and SQLite alternatives – a comprehensive overview

by Vivien | Sep 1, 2020 | Android, Edge Database, IoT, Mobile Database | 2 comments

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

Updated in March 2022: comparison of mobile databases / edge databases

Digitalization is still on the rise, and so is the number of digital devices (from 15 billion mobile devices operating + 13 billion connected IoT devices in 2021 already). Due to this, data volumes grow accordingly (estimated 79 zettabytes of data created in 2021), and centralised computing can no longer support the current needs. This has led to new challenges in computing and subsequently is leading to a shift from the cloud to the edge.

Consequently, the Edge Computing market is expected to grow by 14.8% in 2022 and the years to come (IDC 2022). Hence, there is an increased need for data persistence on the edge. Data flows to / from and between edge devices can be done with Edge Databases and Data Sync. For this reason, we have a look at the edge database market in the following review.

Databases

While being quite established and somewhat saturated, the database market is still growing consistently and significantly. The reason is that databases are at the core of almost any digital solution, and therefore never out of fashion. With the rapid evolvements in the tech industry, however, databases need to evolve too. This, in turn, yields new database types and categories. We have seen the rise of NoSQL databases in the last 20 years, and more recently some novel database technologies, like graph databases and time-series databases. Both the shift from a centralised towards a decentralised paradigm and the growing number of restricted devices call for a new type of database. Thus, we expect Edge databases to become more prominent in the coming years.

What is an Edge Database?

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

What is a Mobile Database?

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

What are the advantages and disadvantages of working with SQLite?

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

Advantages

Disadvantages

20+ years old (should be stable ;))
Toolchain, e.g. DB browser
No dependencies, is included with Android and iOS
Developers can define exactly the data schema they want
Full control, e.g. handwritten SQL queries
SQL is a powerful and established query language, and SQLite supports most of it
Debuggable data: developers can grab the database file and analyse it

20+ years old ( less state-of-the-art tech)
Using SQLite means a lot of boilerplate code and thus inefficiencies ( maintaining long running apps can be quite painful)
No compile time checks (e.g. SQL queries)
SQL is another language to master, and can impact your app’s efficiency / performance significantly…
The performance of SQLite is unreliable
SQL queries can get long and complicated
Testability (how to mock a database?)
Especially when database views are involved, maintainability may suffer with SQLite

What are the SQLite alternatives?

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

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

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

SQLite alternatives Comparison Matrix

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

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

Star this matrix on GitHub. 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.

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

Make sure to check out the ObjectBox Database & try out ObjectBox Sync. You can get started in minutes. More than 1,000,000 developers already use this Edge Database designed specifically for high performance on embedded devices.

Start Using an Edge DB now

What Drives Edge Computing?

by Vivien | Aug 20, 2020 | Edge Computing, Insights, IoT

Data is exploding in every respect: in data volume, data velocity, and data variety (the 3 v’s). One driver of this phenomenon is the growing number of Mobile and IoT devices and thus, data sources. Making this data useful is one of the driving forces behind the adoption of Edge Computing. New use cases don’t only rely on using this data, but also upon the usability and speed of usability of this ever growing data. There are several practical challenges with this growing data volume that drive the adoption of Edge Computing:

New Use Cases Drive Edge Computing

Bandwidth Limitations

The existing network infrastructure cannot support sending all the data to the cloud. Particularly in urban areas there is a concentration of devices and data overburdens existing infrastructure. While 5G promises some relief, it is no hailbringer. First of all, if you want to implement your IoT project now, 5G is not yet available and many questions about 5G remain, e.g. pricing. But moreover, as the number of devices and data is growing ever faster, it is already clear that data volumes will outpace what 5G can support. Edge Computing will be an important technology alongside 5G to enable IoT.

Fast Data Requirements

Response time requirements are growing at the same time as data volumes are increasing. Sending data to the cloud for computation and storage means applications’ response times have a higher latency and depend on the network, which cannot guarantee response rates. Edge computing guarentees significantly faster data. Use cases that need speedy response times or guaranteed responses cannot rely on cloud computing. For example, in driver assistance, where every millisecond counts or in factory floors, where downtimes are too costly.

Sustainability

Sending data to the cloud and storing it there is inefficient and therefore costly – not only in plain €, but with regards to CO2 emissions too. The distance the data needs to travel needs hardware, connectivity and electric power. Therefore, sending data unnecessarily back and forth is wasteful beaviour and burdens the environment unnecessarily. With growing data volumes, that burden is growing. In fact, analysts predict that cloud computing data centers will consume as much as 21% of the total global energy by 2030. [1]

To scale your prototype, you need to move to the edge

At the start of IoT projects, quick prototyping, testing and piloting on early iterations of an application’s functionalities, can effectively be done in the cloud. However, in productive environments when applications scale it is often hard or impossible to keep cloud costs at scale, making the business not viable. Then it is time to move to the edge.

At the same time, decreasing hardware costs and hardware sizes are enabling more complex local computing, meaning there is less need for additional cloud usage. E.g. increasingly AI and ML is done at the edge, including model training.

data-volume-edge-computing-solution-iot-mobile

Data accessibility and Smart Syncing

Today’s successful businesses require a smarter approach to data management and integration. Data synchronization increases operational efficiencies, saving time and resources by eliminating redundant data transfer. With data synchronization, only predefined, useful parts of a data set are sent to a central instance. This means that while large volumes of data can be collected and analyzed locally, not all of this data is sent to and saved in the cloud. This reduces the impact on bandwidth, utilizes the local hardware resources for fast guaranteed response times, and keeps project cloud costs low – ultimately creating a more sustainable and efficient model of data architecture, enabling long term project scalability.

ObjectBox’ current database technology is enabling companies to persist and use data on edge devices, faster than any alternative on the market. It enables networks of edge devices working without a central instance, enabling even more new use cases.

[1] https://www.nature.com/articles/d41586-018-06610-y

Time Series & Objects: Using Data on the Edge

by Vivien | Jun 30, 2020 | Edge Computing, Insights, IoT, Release, Time Series

Many IoT projects collect, both time series data and other types of data. Typically, this means they will run two databases: A time-series database and a traditional database or key/value store. This creates fracture and overhead, which is why ObjectBox TS brings together the best of both worlds in one database (DB). ObjectBox TS is a hybrid database: an extremely fast object-oriented DB plus a time-series extension, specially optimized for time series data. In combination with its tiny footprint, ObjectBox is a perfect match for IoT applications running on the edge. The out-of-the-box synchronization takes care of synchronizing selected data sets super efficiently and it works offline and online, on-premise, in the cloud.

What is time series data?

There are a lot of different types of data that are used in IoT applications. Time-series is one of the most common data types in analytics, high-frequency inspections, and maintenance applications for IIoT / Industry 4.0 and smart mobility. Time series tracks data points over time, most often taken at equally spaced intervals. Typical data sources are sensor data, events, clicks, temperature – anything that changes over time.

Why use time series data on the edge?

Time-series data sets are usually collected from a lot of sensors, which sample at a high rate – which means that a lot of data is being collected.

For example, if a Raspberry Pi gateway collects 20 data points/second, typically that would mean 1200 entries a minute measuring e.g. 32 degrees. As temperatures rarely change significantly in short time frames, does all of this data need to go to the cloud? Unless you need to know the exact temperature in a central location every millisecond, the answer is no. Sending all data to the cloud is a waste of resources, causing high cloud costs without providing immediate, real-time insights.

The Best of Both Worlds: time series + object oriented data persistence

With ObjectBox you aren’t limited to only using time series data. ObjectBox TS is optimized for time series data, but ObjectBox is a robust object oriented database solution that can store any data type. With ObjectBox, model your world in objects and combine this with the power of time-series data to identify patterns in your data, on the device, in real time. By combining time series data with more complex data types, ObjectBox empowers new use cases on the edge based on a fast and easy all-in-one data persistence solution.

Bring together different data streams for a fusion of data; mix and match sensor data with the ObjectBox time series dashboard and find patterns in your data. On top, ObjectBox takes care of synchronizing selected data between devices (cloud / on-premise) efficiently for you.

time-series-data-visualization-dashboard

Get a complete picture of your data in one place

Use Case: Automotive (Process Optimization)

Most manufacturers, whether they’re producing cars, the food industry, or utilities, have already been optimizing production for a long period of time. However, there are still many cases and reasons why costly manual processes prevail. One such example is automotive varnish. In some cases, while the inspection is automatic and intelligent, a lot of cars need to be touched up by hand, because the factors leading to the errors in the paint are not yet discovered. While there is a lot of internal expert know-how available from the factory workers, their gut feel is typically not enough to adapt production processes.

How can this be improved using time series and object data?

The cars (objects) are typically already persisted including all the mass customization and model information. If now, all data, including sensor data, of the manufacturing site like temperature, humidity, spray speed (all time-series data) is persisted and added to each car object, any kind of correlations between production site variables, individual car properties and varnish quality can be detected. Over time, patterns will emerge. The gut feel of the factory workers would provide a great starting point for analyzing the data to discover Quick Wins before longterm patterns can be detected. Over time, AI and automatic learning kicks in to optimize the factory setup best possible to reduce the need for paint touch ups as much as possible.

Use Case: Smart Grids

Utility grid loads shift continually throughout the day, effecting grid efficiency, pricing, and energy delivery. Using Smart Grids, utilities companies can increase efficiency and reliability in real time. In order to get insights from Smart Grids, companies need to collect a large volume of data from existing systems. A huge portion of this data is time series, e.g. usage and load statistics. On top, they incorporate other forms of data, e.g. asset relationship data, weather conditions, and customer profiles. Using visualization and analytical tools, these data types can be brought together to generate business insights and actionable operative goals.

ObjectBox TS: time series with objects

Storing and processing both time series data and objects on the edge, developers can gather complex data sets and get real time insight, even when offline. Combining these data types gives a fuller understanding and context for data – not only what happens over time, but what other factors could be influencing results. Using a fast hybrid edge database allows developers to save resources, while maintaining speed and efficiency. By synchronizing useful data to the cloud, real time data can be used for both immediate action, and post-event analysis.

Get in touch with our team to get a virtual demo of ObjectBox TS, or check out the sample GitHub repo to see more about the code.

Go to ObjectBox TS

What is Edge Computing?

by Vivien | May 23, 2020 | Edge Computing, Insights, IoT

Today, over 90 percent of enterprise data is sent to the cloud. In the next years, this number will drop to just 25 percent according to Gartner. The rest of the data is not going anywhere. It is being stored and used locally, on the device it was created on – e.g. cars, trains, phones, machines, cameras. This is Edge Computing – and since the Corona outbreak it is more relevant than ever. Edge Computing is a topology rather than technology and spans devices as well as industries.

Obviously, this is cutting the discussion short. With edge consortia springing up like mushrooms, there is no lack of overlapping definitions around the terms Edge Computing and Fog Computing.

Benefits of Edge Computing put simply

The benefits of edge computing stem from its underlying paradigm: Edge Computing is a decentralized computing architecture as opposed to a centralized computing model (today typically cloud computing).

Data ownership / privacy: With Edge Computing data can stay where it is produced, used and where it belongs (with the user / on the edge devices)
Networking costs / Cloud costs: Reducing data transferrals and central storage reduces networking and cloud costs significantly
Bandwidth constrains: Bandwidth is limited and the data volumes are growing much faster than the bandwidth can be expanded (e.g. with 5G networks); it therefore puts a hard stop on many applications that can be overcome by building on the edge
Application / Data speed: Processing on the device – instead of sending data to the cloud and waiting for an answer – is way faster (latency)
Offline-capability: With Edge Computing, devices operate independent from a network / cloud connection, so the application always works and data parts that are needed centrally can be synced when convenient, needed, connected
The decentralized edge: Edge devices can communicate between each other directly. This decentralized Edge Computing approach more efficient (usually translating to speed) due to the short distances and because the power and information of several devices can be combined (for more info see: ultra low latency networks, peer-2-peer, M2M actions). On top, it adds resilience.
Security: A central instance with millions of data is more attractive to hack; also the data transferral adds an additional vulnaribility.

From mist to fog to edge to cloud – a short overview

To bring some light into the terminology mess: The terms “mist computing” and “cloud computing” constitute the ends of a continuum. In our definition, the edge covers everything from cloud to any end device, however tiny and limited it may be. In this definition, there really is only the cloud and the edge.

However, some authors additionally use the terms fog computing and mist computing.

Mist covers the computing area that takes place on really tiny, distributed, and outspread devices, e.g. humidity or temperature sensors. To make it a bit more tangible: These devices generally are too small to run an operating system locally. They just generate data and send that data to the network.

As opposed to mist computing, the cloud refers to huge centralized data centers. The terms “fog” and “edge” fall within this continuum and – depending on whose definition you follow – can be used interchangeably.

From edge to cloud and back: History repeating itself

If these terms seem familiar to you, that is probably because edge computing is just another cycle in a series of computing developments.

Computing has seen constant turns between centralized and distributed computing over the decades, and with recent developments in hardware capacity, we’re again entering into a decentralized cycle.

Edge Computing has been around for 20 years, see a quick history here:

Cloud or edge? – one to rule them all?

Neither the cloud nor the edge is a solution for all cases. As always: It depends. There are cases, where the edge makes more sense than the cloud and vice versa. Most cases however, do need both. If you can, putting the bulk of your computational workload on the edge does make sense though from an economic as well as environmental perspective.

Interested in learning more? Read why Android developers should care about Edge Computing or discover Edge IoT use cases.

A last word on “edge consortia”

There is no lack of consortia defining terms around edge computing – it’s a lot like the Judean People’s Front against the People’s Front of Judea. After a year of battle, the most prominent edge consortium emerging currently seem to be EdgeX under the umbrella of the Linux Foundation – fully open source, while also largely supported and driven by Dell, who initiated it. Other notable players trying to get a foothold in this space is the Deutsche Telekom with MobiledgeX and HPE with Edge Worx. A European counterpart, ECCE, formed in spring 2019 and might be worthwhile watching, as it is supported by many industry players like e.g. KUKA, Intel, and Huawei.

Add an Edge to Your Project Today

Car Tolling – A case for Edge Computing

by Vivien | Sep 11, 2019 | Case Study, Insights, IoT

Governments often face tight budgets on infrastructure development; car tolling is increasingly seen as the answer for raising funds¹, making it more and more prevalent. From 2008 to 2018 the total length of tolled roads in Europe increased by 23%² and tolling revenue in Europe increased by 37%³ to €31.3 bn. per year; similarly, from 2010 to 2015 the United States experienced a 63% increase in transponders and 52% more tolling revenue, resulting in $13.8 bn. in 2015⁴. On top, despite car sharing efforts, car ownership and traffic is still increasing in many countries, e.g. Germany⁵ ⁶, France⁷ and India⁸. Increasing amounts of traffic, devices, and data points bring current tolling solutions to their limits. Taking data to the edge in new and existing tolling solutions by adding a data persistence layer and synchronizing parts of the data can make tolling more efficient and reliable.

Setting the stage: a typical car tolling situation

A national infrastructure company has deployed several hundred car tolling stations all over the country. These stations automatically recognize passing cars by detecting licence plates, using visual recognition or wirelessly, e.g. by receiving data from an RFID transponder in the car. In order to ensure that only eligible cars are passing through the tolling station and violators are fined, it is necessary for the tolling station software to look up the gathered vehicle information – among millions of entries – as fast as possible. If the data look-up is not fast enough, or the data on the roadsides/tolling stations isn’t up to date and in sync with the central data, the tolling station loses money.

“The importance of mobile apps is increasing for Kapsch TrafficCom so that we see ObjectBox’ edge computing database solution as an interesting future base technology for all types of mobility apps.”

Peter Ummenhofer

Executive VP Solution Management, Kapsch TrafficCom

Why edge computing and fast lookups are key to today’s car tolling systems

In general, modern nationwide tolling infrastructure consists of three systems: tolling stations operated by the respective agencies, central open road, also called mobile tolling⁹, and central transaction clearing houses. Within this infrastructure, all data related to violators and other operational information needs to be synchronized between these three systems in a consistent way, with as little delay as possible. If this is not the case, together with other problems, car tolling system operators are faced with high monetary losses every day.

Challenges of today’s car tolling systems

Today’s car tolling systems are based on the fundamental idea that cars do not need to stop to be checked or charged. Thus, as the cars move quickly through the scanning area, the main challenge relates to the amount of data that needs to be searched within a very short time frame. To be successful, the license plate needs to be read and looked up in a database in near real-time.

Near-realtime requirements

From a development perspective, this challenge is rooted in:

accessing data from a remote location (speed of communication, speed of network)
keeping data in synchronization with car tolling stations that are closer to the drivers and/or roadside units
database speed on remote servers
database speed on roadside units (car tolling edge devices)
limitations of existing hardware as some systems are quite old, and rolling out new hardware is expensive

Strict uptime quarantees

Furthermore, it is possible that stations shut down from time to time, due to the weather, power outages, vandalism or simply technical failures. However, tolling providers generally need to provide strict uptime guarantees and thus service level agreements often include penalty fees in case of excessive downtime. Such events cost the providers substantial amounts of money – and data loss, i.e. undetected violators, even more so.

Privacy and legal regulations

Adding to this, privacy and legal requirements differ from country to country and increase the complexity of the systems and timings. For example, in Austria the pictures and derived license plate information may only be used for checking, but in case no violation was detected, they need to be removed in an unrecoverable manner.¹⁰ On the other hand, the data of potential violators may be stored for the sole purpose of toll collection or prosecution, but only for a maximum of three years.

Edge Computing

Edge computing (local data storage and data sync) can help solve these challenges. Deploying local persistence on every type of tolling station, i.e. open and static stations, as well as on the central server allows to meet the near-realtime requirements, heighten uptimes (offline, flaky networks), and last not least meet privacy regulations. From a technical point of view, a solution that supports all platforms and operating systems, is the most efficient approach to ensure edge persistence and data harmony across devices.

Edge database and Sync are the center piece for efficient car tolling solutions

There are a couple of edge databases out there, but out-of-the-box data synchronization solutions are very rare. A fast edge database that reliably persists the needed data and supports fast lookups is essential. Data synchronization guarantees that the vehicle data in the internal stations’ memory is always up-to-date with the central server, so the station will make a decision based on the most accurate data every time. Additionally, the other systems involved in the tolling infrastructure consistently receive the most recent information with no further effort required.

Deploying such an edge persistence and data sync solution mitigates the losses of station shutdowns and Internet connection issues are not a problem anymore. The stations’ operating company also no longer looses violator’s information due to technical reasons.

Summary – Car tolling is moving to the edge

As this case study shows, the use of edge computing is a perfect fit for modern infrastructure. In the context of car tolling, speed, reliable data storage and synchronization are indispensable, resulting in ObjectBox being an effective solution for today’s and future technological advancements.

If you are interested in learning more, feel free to get in touch with us! We appreciate any kind of feedback.

Discover more IoT Use Cases