Much discussion of database systems concentrates on the services that such systems provide. For example, most database systems support transactions and multiple concurrent users. All database systems have some mechanism for storing and retrieving data. All database systems have an underlying data model, which defines the data types that they can store and the operations that are supported on those types. Examples include relational databases, object-oriented databases, and XML databases. All of these details are important, of course. You must understand the services your database provides if you are to choose the right one.
The huge success of relational database systems like Oracle and IBM's DB2 has created a general perception that a database system is a heavyweight, standalone engine with complicated user interface tools of its own. These database systems are installed and maintained by professional database administrators. Programmers and end users interact with them by typing SQL queries.
In fact, there is a fast-growing market for embedded database engines that are different from the relational products that dominate public perception. Embedded databases are intended for use by professional software developers, rather than by end users or database administrators. They provide the same data management services, including transactions, recovery, and concurrency, but in a very different package. Embedded databases have carved out a comfortable niche among certain users, and their success in managing general-purpose data suggests that they will also be important in the XML database market. For example, content management systems, reliable message queues, Web services registries, and user preference and authentication repositories are all services that should naturally be delivered using XML, and that need to store and maintain XML data internally. No direct end-user access to the backing store is required. An embedded XML database is a natural way to store the XML data for systems like these.