In the Context of Embedded Systems, are all Embedded Databases Created Equal?

September 04, 2024

Blog

There is a tendency to conflate the terms embedded database and embedded system. That is a mistake.

First, what is an embedded database? Simply, it is a database system that is compiled and linked with an application, i.e. it is ‘embedded into’ an application. It is distinct from client/server database systems where the client and the server run in their own address space and often in entirely different computer hardware systems. An embedded database runs in the same address space as the application that uses it.

Embedded databases came into being in the late 70s/early 80s. Those of you with some grey (or no) hair should remember dBase (1978), Empress (1979), Btrieve (1982), c-tree (1984), SQLBase (1984) and db_VISTA (1984).

In the late 70s and early 80s, embedded systems were 8-bit and 16-bit systems that did not have enough addressable memory for a complex piece of software like a database management system, even a relatively ‘simple’ embedded database system (relative to client/server behemoths like Oracle, SQLServer, etc.).

It wasn’t until the late 90s that embedded systems began to use 32-bit processors that could address enough memory for an embedded database system.

But all the aforementioned embedded databases were written before that. They were intended for line-of-business applications running on Windows and various flavors of Unix (anyone remember SCO Unix?) and DEC VAX. What’s a so-called line-of-business application, you ask? It’s applications like inventory, payroll, accounts receivable/payable, etc. In a nutshell, it’s any application that a business uses to run its day-to-day operations.

With the ascension of embedded systems into the 32-bit arena, these platforms were able to host more complex systems. More complexity usually comes with more data, and more varied data, to manage. And that screams “I need a database system!” So, you’re a 1990s embedded systems software engineer, what do you do? You take one of the existing embedded databases and try to shoehorn it into your embedded system.

And this is where the problem started. Embedded systems, even 32-bit ones, are not like laptops, desktops, workstations, or server systems. Those are generally x86 systems with oodles of memory, big disks, and fast multi-core processors. Embedded systems typically have no more memory than necessary, may not have any persistent storage at all, and a processor that’s just fast enough to get the job done. And, that processor might be an ARM, MIPS, PowerPC or x86. Further, it’s probably not running Windows and maybe not Linux. It could be running an embedded/real-time operating system like embOS, VxWorks, INTEGRITY, QNX, FreeRTOS or one of so many more.

So, your first job as an embedded systems software engineer that needs a database system is to find one that you can get the source code for, and port it to your chosen processor, operating system and toolchain. Then, because you’ve got a resource-constrained system, start ripping out the stuff you don’t need to get the code size down to fit in your system. For example, maybe your device only has to read a preloaded database, and never needs to write to it. So, you don’t need all that code for inserting, updating and deleting records, and all the baggage that comes with that like concurrency control and ACID transactions.

Having faced this dilemma a few times, we realized the need for a database system that was written with embedded systems in mind in the first place, one that didn’t need radical surgery to fit into all sorts of resource-constrained embedded systems and their various processors, operating systems and toolchains.

So here we come to it, the difference between line-of-business embedded database systems and embedded database systems for embedded systems.

Characteristic	Line-of-business DBMS	embedded systems database system
Processor	Assumes x86. Assumes multi-gigahertz clock speed, multiple cores	Supports any 32-bit processor. Clock speed could be as low as 100mHz. Could be single-core or multi-core
Operating System	Linux or Windows	Any 32-bit processor, any decent C compiler
Memory	Lots	Code-size can be as little as 150K and typically not more than 500K
Persistent storage	Rotating disks or flash memory up to terabytes	Maybe none. Just enough EPROM to boot the system

An embedded database intended for embedded systems needs to not waste precious resources, like CPU clock cycles and memory. It needs to eliminate, or at least minimize, reliance on the C runtime library, and minimize, eliminate, or isolate dependencies on the operating system.

In conclusion, when looking for a suitable embedded database system for an embedded and/or real-time system, make sure that the candidates you are considering can at least claim to have been developed with embedded systems in mind. And then do your due diligence and peel off a few layers of that onion with the insights I’ve shared here to improve your confidence that, at the end of the day, your chosen embedded database solution is going to be up to the task.