Embedded databases for embedded systems

While there are still embedded systems that need only a look-up table or a linked list, for many applications the data demands are such that only a database will work. Many people think they can write their own database system or use a database not designed from the ground up for embedded systems. Neither route is a good solution. Writing your own, whether for an RTOS, for graphics, communications stacks or databases, is never a good idea unless you really are an expert. Learning all the techniques and methods takes a lot of time and effort that could be better spent elsewhere on your project.

Developers often think they need to write their own as their problem is unique. When examined, it usually turns out that their problem is not unusual and resolving it is well-understood. Neither is it difficult to come up with a complex solution; the skill is designing a simple and elegant solution that handles the what-ifs. These two points illustrate that rolling your own is unlikely to be cost effective, once you have factored in the time to design, build and debug an embedded database. McObject, the supplier of the eXtremeDB in-memory database frequently finds that when examining the database schema and code of a new user, there is a simpler solution.

Once you have decided to buy in a database, you will find that not all databases are the same. Many are designed to run in an environment with disk drives, virtual memory and lots of ever expanding resources (let's call it a computer). There are also databases designed from the ground up to work in embedded systems. The most successful route is to use an In-Memory Database System (IMDBS). This is not the same as a cached system, as IMDBSs require a completely different way of working internally to a conventional DBS.

You should not start designing your database until you fully understand how an IMDBS works. For example you need to have a strategy for persistent and non-persistent data (and need to know what they are!). Another choice is of course how to talk to the database; the first thought is often SQL, a 1970s system that brings it own baggage. Like much in system development, adding a database is not easy, but with careful choice of database the overall system will be more powerful, secure and stable.

Image courtesy of Renjith Krishnan at FreeDigitalPhotos.net