Object-Oriented Database Management Systems (OODBMS's) are databases that store their contents as objects. They map very well to the object models of the programs that use them.
Drawbacks include indexing (sometimes you have to write your own indexing code; often retrieval performance is bad) and interworking with non-OO company-wide systems. On the upside, the object persistence is easy to program, and complex data objects are surprisingly natural.
Price is also high at the time of this writing (Object Store(?) costs around three times what the already-exorbitantly-priced Oracle 8i does). Alternatively, see Open Source Object Oriented Database.
In the general sense, an OODB is a Navigational Database... with methods.
Many of them called OODBMS don't support methods.
Alternatives to an Object Oriented Database include a Prevalence Layer, a Relational Database (by using Object Relational Mapping), or a Hierarchical Database (e.g. a filesystem).
Why haven't Object Oriented Database 's become popular?
I think the reason is that Object Oriented Database is an oxymoron. A database, by definition, is a base of data - it allows you to query it, index it, and revert it (transactions). All of these properties depend on dead, static data (try indexing a true method) - data that is the same no matter how many times you look at it. Objects, on the other hand, do the exact opposite - they hide the data under behaviors, which can vary depending on hidden things (information hiding), hence precluding queries, indexes, and transactions. In order to hook up your objects to a database, you need to do 80% of the work of an Object Relational Mapper , anyway.
The remaining 20% benefit of an Object Oriented Database (as well as the syntactical improvements over SQL) isn't worth deviating from the relational/SQL standard.
Object Oriented Database is not an oxymoron, and what database actually is is defined by what it can do and what it contains, not by some arbitrary definition that focuses on popular aspects only. If database contains "dead static data" only, what about the stored procedures? Triggers? Database contains data, but it does not have to contain only data. A simple, common sense to think what Object Oriented Database is would be e.g. take Versant's approach: db stores objects and indexes them according by their public attributes. And you do not have to violate information hiding at all to get them: you could index on public attributes only, or on values returned by getters (like typical java getters). I don't see how finding accessing a public "x" attribute of live in-memory "new Foo()" object is not violation of information hiding, while searching for the Foo class objects in database and bringing them into memory from "hibernation" in Object Oriented Database and then accessing their public "x" attributes would supposedly be the case of violating information hiding. Whether you hold objects in memory or on disk seems orthogonal to me to the issue of information hiding in objects. That's "just" a performance consideration, not enscapsulation or representation issue.
On popularity issue: there's a number of concerns here. 1. there is no object query language that would be both *standardized* and reasonably small to be *implementable* (practical, in short). 2. reason 1 results in lack of people with Object Oriented Database querying skills => companies are unable to find people that would realize the benefits of Object Oriented Database and so they don't use OODBs. 3. premises 1 and 2 result in lack of good open source Object Oriented Database => there is no place to learn Object Oriented Database query language that would be widely applicable (that is, beyond one's personal interest) => premise 2 is reinforced.
It's also worth noting that OO DBAs are a lot harder to find than relational DBAs.
And Ruby Language programmers are a lot harder to find than Cobol Language programmers. It's a Self Fulfilling Prophecy - a function of market penetration, viz. Crossing The Chasm. (See also Crossing Chasms, a large pattern language that describes how to connect an object system to a Relational Database. )
Ruby is open source, it is widely available and it has Killer App (Ruby On Rails). Therefore, soon Ruby Language programmers will soon be more abundant than Cobol Language programmers. OODBs suffer for lack of equivalents of MySQL and PostgreSQL: it's chicken and egg dilemma, you don't use Object Oriented Database bc you haven't learned it and risk a lot if you learn vendor-specific OODB (skills unportable between employers), and since few people learn OODBs, they don't get used.
Is there an up to date list of Object Oriented Database vendors somewhere? (yes February 2014 www.service-architecture.com 
) Maybe on Wiki Wiki Web? A Google Search came up with the following (alphabetically):
AllegroStore
Cache (www.intersystems.com )
CommonSQL / UncommonSQL
db4o (Dee Bee Four Oh) www.db4o.com (open source)
GOODS (www.garret.ru )
Objectivity/DB (www.objectivity.com )
PLOB! (acronym for Persistent Lisp OBjects; see plob.sourceforge.net )
POET
Versant
Xanalys's CLOS SQL binding
XL2 (www.xl2.net )
(feel free to properly wikify these names if pages already exist for them, remove ones that are not relevant, and add ones that are missing).
Q. What are the differentiators for each of the vendors and their products?
A. The differentiators are probably the targeted use cases, scalability, product maturity, architectural philosophy, API, and of course, cost.
Is there a clear definition of what an OODBMS is? Or at least a list of guiding principles? Bertrand Meyer seems to suggest that OO is against the concept of DBMS's to begin with. There is talk that the concept of a database violates encapsulation. In this view OO is about behavior, not data, and you access data through behavior wrappers(methods). "Naked attributes" violates some definitions of encapsulation.
See www.odmg.org
It seems one has to buy a book in order to make a bulleted list of requirements. That smells.
What's smellier is that each book would probably result in a different list.
See also "The Object-Oriented Database System Manifesto" (at www-2.cs.cmu.edu ).
There is still no agreed-upon definition or clear characterization of an OODBMS. It's difficult to judge the merits of one without a stable definition or feature set.
Verb Divas
One of the problems with the idea of OODBMS is that the activities on objects and collections of objects is not standardized. In RDBMS and most prior databases you generally have a standard set of Database Verbs that all records and all tables respond to in the same fashion. It's a form of Interface Factoring. In OOP philosophy, each and every object is generally considered its own independent state machine with its own behavior. Any sharing of interface or behavior commonality is purely voluntary and thus inconsistent. This is against the idea that Interface Factoring is important and useful; it's essentially anti-database. Having a standard set of collection-oriented operations does not preclude additional custom behavior, I would note. Custom behavior is fine, but one should be discouraged from reinventing the wheel if there already is a "close enough" standard operation. -t
Wow. It's rare I agree with Top, but I agree with Top. Quick, somebody photograph this moment.
For court evidence :-)
See also Persistence Engine, Prevalence Layer, Modern Dinosaur, Object Relational Psychological Mismatch.
See original on c2.com