4.2 A Primer on Embedded Databases

  Previous section   Next section

Embedded databases run directly in the application or system that uses them. They do not require a separate database server, since all the data management logic is linked into the application's address space. They generally offer a carefully tuned function call or class method API that developers can use to store, fetch, and update records. Embedded databases do not, as a rule, include end-user query tools.

Fundamentally, an embedded database system is intended for use by a software developer building an application or server that needs fast, reliable data management. The only way to store and fetch records in an embedded database is to write code that calls the database APIs. Unlike client/server database systems, most embedded databases include no end-user query tools, graphical user interfaces, or report generators. The programmer must design and build into the application any query interfaces that the end user needs. In fact, most end users who run those applications have no idea that they are using a database at all. The end user focuses on the task at hand?sending e-mail, looking up information in a directory, or shopping on an e-commerce site?and the programmer decides what to store and how to find it again later.

The most significant advantage that an embedded database has over a client/server system is speed. Because all database operations happen inside the application process, an embedded database incurs none of the overhead that inter-process communication imposes. Since most computers can do many thousands of local function calls in the time that it takes to do a network operation, embedded databases exhibit far less latency. In addition, because no extra copying of the data occurs when it moves from one address space to another, throughput is much higher.

Also, because there is no separate server, embedded databases are typically easier for end users to install and administer. Embedded database systems require the programmer who develops the application to handle administrative tasks like backup and failure recovery, so the end user can ignore them, or can at least use tools and interfaces that are consistent with the application to handle them. Because no separate server process is required at runtime, there are fewer moving parts, reducing the likelihood of runtime problems because some component has failed separately from the others.

Of course, there are trade-offs. Embedded database systems are not generally suitable for applications that have to support ad hoc queries by end users. Embedded databases require developers to write more code, on average, than client/server databases. And embedded databases require developers to consider carefully, when they design their applications, the kind of data they need to manage and how they will store it and search for it. Embedded databases, as a rule, are harder for developers to use than client/server databases, but easier for end users. Since there are many more end users than developers in the world, favoring the end user makes sense.

Developers need not make trade-offs regarding scalability, reliability, or performance when they choose an embedded database. The techniques for handling large amounts of data and many concurrent users, for surviving system failures without losing data, and for providing fast data access work just as well in embedded products as they do in standalone database engines. Of course, the individual product offered by any particular vendor will behave differently, but scalability, reliability, and performance are features of a particular implementation and do not depend on where the actual machine code executes.

There are many applications in which embedded databases have been more successful than client/server relational databases over the past several years. Many of the services that underlie the Internet, including e-mail, naming and directory services, Web search, and shopping cart applications, need fast, reliable data storage but cannot afford the overhead of an SQL query to a remote database server for every operation. Those applications use embedded database systems for speed and reliability. Increasingly, devices like network routers and gateways, storage systems, and entertainment systems including personal video recorders and set-top boxes need to store and manage critical data, and rely on embedded database systems. At the low end, devices like cell phones and PDAs often need data storage and synchronization in a small-footprint package and take advantage of embedded database systems for that.


Part IV: Applications of XML