Be Sure That’s What You Need: Differentiating Embedded Database from Non-Embedded (Client/Server) Database Systems
July 30, 2024
Blog
There’s been an explosion of database systems since the late 90s. Whereas there were relatively few choices back in the day, now there are hundreds of choices of database systems that span different architectures, APIs, models, and more. This article will compare and contrast two database system architectures, embedded and client/server.
Within each of these architectures, you can find database systems of every type:
- Relational/SQL
- Hierarchical
- Network model (a superset of hierarchical)
- Graph databases (a superset of network model)
- NoSQL
- NewSQL
- Columnar
- In-Memory/Persistent/Hybrid
- Etc.
Heck, even NoSQL encompasses a range of models, document, key/value, wide column, etc.
The key differentiator of embedded database systems is that they are tightly integrated with an application, providing local data storage without relying on a separate database server. In other words, the database functionality is compiled and linked with the application code, such that the application makes calls directly to the database system, in the same manner it calls standard functions of the host language library (e.g. the standard C library). This eliminates inter-process communication from the execution path, and all the latency that that entails.
Eliminating the client/server baggage also reduces the code size and resource consumption needs of the database system. The result is a smaller and faster database system. This makes embedded database systems more suitable for resource-constrained embedded systems. Note, however, that the term ‘embedded database’ is wholly unrelated to the term ‘embedded system’.
Embedded database systems have been around since at least the early 80s, long before embedded systems had enough processing power to utilize any type of database system. 8-bit and 16-bit embedded systems could not address enough memory, so it wasn’t until the late 90s when embedded systems based on 32-bit processors became common that embedded database systems began to be used in embedded systems.
So, embedded database systems were borne out of the need to have database support for a line of business applications on Windows, Unix, and Unix-like systems.
The embedded nature of embedded database systems limits the scalability of them. But, given the use cases, that’s not really an issue. Because there is no inter-process communication, all the concurrent tasks that are sharing the database exist in a single system, and there’s an inherent limit to the number of processes and/or threads that can be spun up on a single system, even a relatively large Linux system with dozens of cores and hundreds or thousands of gigabytes of memory.
In contrast, a client/server database system hosted on a beefy server can have 10s, 100s, or 1000s of other systems that connect to the database server and request CRUD (create, read, update, delete) services of the database system. These systems need to be able to scale up to a much greater degree than embedded database systems.
The separation of the client and server can also improve the safety/reliability of the overall system. Because an embedded database is linked with the application, they share the same address space. This makes it possible for an errant application to corrupt either the database or the embedded database system run-time, or both.
With separate client and server processes, the operating system can fence off the database server from rogue applications. The client processes might also be running in wholly separate systems, further isolating them from the database server. “Security: A database engine that uses a server can, in some instances, provide better protection from bugs in the client application than a serverless database like SQLite. For example, stray pointers in a client cannot corrupt memory on the server.”
Embedded databases are easier to deploy and to maintain than their client/server counterparts. An embedded database system is just along for the ride during the application installation process. A client/server database system must be installed separately, often on a separate server. It must also be configured to facilitate greater scalability. This generally necessitates the engagement of a database administrator (DBA).
Embedded database vendors like to brag that their systems do not require a DBA. “If you have demanding performance requirements, limited resources, and/or simply want to develop a faster embedded system that absolutely, positively must run un-attended (i.e. “zero administration”) then carefully consider your choice of embedded database system.”
There’s a myth that client/server databases excel at complex operations/transactions, but there is nothing inherent in embedded database systems, generally, that precludes them from performing equally complex operations. Of course, there are differences in the completeness of coverage of the SQL language, as well as the quality of the SQL engines’ optimizers, but this is true of both client/server and embedded database systems. And embedded database systems that offer only a native, nonSQL, API make it difficult and/or impractical to implement the equivalent of a multi-table join with sorting, filtering, and aggregation on columns of different tables.
In summary, choose an embedded database for simplicity, resource efficiency, and local data storage. Opt for client/server systems where scalability and centralized management are essential.
