Object-oriented Database Management Systems (ODBMS or OODBMS) offer persistent storage for object data, often with direct bindings to object-oriented programming languages. They distinguish themselves from relational databases (RDBMS) in the following key points:

Complex objects can be stored without segmentation:

RDBMS require data to be normalized to avoid redundancies. This means that the values belonging to one logical unit (the object) are often spread over several database relations. To access the whole object or its interrelationships with other objects several joins may be necessary. But joins are one of the most costly operation in the relational model and thus traversals of object structures consisting of thousands of objects become too slow for applications like e.g. CAD. Also, storing an object without segmenting it eases clustering of the database.

User definable abstract data types (the classes):

RDBMS only allow to model and store data, the logic for handling this data remains wholly in the applications using the database (this is not exactly true for active databases, though). ODBMS on the other hand allow to incorporate the behavioral aspects of the data into the database itself which can ease consistency maintenance and behavior updates, and allows additional transaction models.

Object identity is inherent in the data model:

RDBMS often introduce artificial keys into the database model to ensure different entities are represented as different even though all 'natural' values are the same (e.g. two points at (1,1) in a collection of geometric figures). The uniqueness and the referential integrity of these artificial keys have to be ensured explicitly by the database or the applications, which costs time. In ODBMS object identity is an inherent concept of the language.

No impedance mismatch between programming language and DBMS:

The relational query language SQL differs from normal programming language in some respects and therefore makes coupling difficult. For example relational databases handle collections of data as sets whereas most programming languages can handle only single data items. Also, SQL is not turing-complete, which requires any calculation of a transitive closure (e.g. all ancestors of a person) to be done in the programming language.

These differences also allow ODBMS to choose more efficient strategies in other areas: Transaction mechanism can take advantage of the enhanced knowledge about the semantics of operations on the data: E.g. two "increment a by n" operations are associative and can therefore be exchanged when serializing operations; two "Read a, Write a" operations can't. Also versioning and configuration management are simpler if objects remain unsegmented. Beginning in the mid 90ties the developers of RDBMS have reacted to some of these deficiencies and introduced object-oriented concepts into their databases leading to so called Object-Relational DBMS (ORDBMS).

A major architectural distinction of ODBMS is between page servers and object servers. In a page server architecture the database server handles all data with the minimum granularity of a (memory) page. The individual objects are retrieved from these pages only on the client side. In an object server architecture the database client and server communicate on the basis of individual objects. This has major consequences on how and where transaction management, recovery and method execution are implemented. In principle, page servers should be more efficient for direct object access whereas object servers should excel if queries can be split between client- and server-side.