May 21, 2011

Object-oriented database management systems (OODBMS)

There seems to be a fair amount of confusion about object-oriented database management systems (OODBMS). Let’s start with a working definition:

An object-oriented database management system (OODBMS, but sometimes just called “object database”) is a DBMS that stores data in a logical model that is closely aligned with an application program’s object model. Of course, an OODBMS will have a physical data model optimized for the kinds of logical data model it expects.

If you’re guessing from that definition that there can be difficulties drawing boundaries between the application, the application programming language, the data manipulation language, and/or the DBMS — you’re right. Those difficulties have been a big factor in relegating OODBMS to being a relatively niche technology to date.

Examples of what I would call OODBMS include: 

Arguably, OODBMS have all the benefits of document-model DBMS, but with different language bindings. And if you’re going to write in an object-oriented language anyway, those language bindings can seem pretty appealing. In particular, they might be preferable to fighting your way through object/relational mapping.

Other than the double-edged language sword, the main criticism of object-oriented DBMS is that they include a whole lot of pointers. Intersystems and others have shown that, even in a disk-centric world, OODBMS can have excellent performance in OLTP and tolerable performance in simple reporting. As RAM gets cheaper, memory-centric operation becomes ever more viable, making the pointers even less problematic.

Bottom line: If I were starting a SaaS project today, I’d give serious consideration to memory-centric OODBMS technology.


20 Responses to “Object-oriented database management systems (OODBMS)”

  1. RC on May 21st, 2011 8:00 am

    I think that many people want to know how you see the difference between a graph database like for example neo4j and an object database?

  2. Curt Monash on May 21st, 2011 9:12 am

    How about one stores objects, while one stores nodes and edges?

  3. Dan Koren on May 22nd, 2011 2:15 am


    The language bindings – or more accurately
    embeddings – that make OODBMS so attractive
    to developers for writing custom application,
    also proved to be a major obstacle to market
    penetration and were one of the reasons why
    OODBMS never delivered on their promise.

    Different programming languages represent complex
    data objects internally in different ways – even
    compilers for the same language, e.g. C++ may do
    this! The net result is that a Versant application
    program written in C++ for say, Sun and compiled
    with Sun’s C++ compiler will end up storing data
    in a Versant database in an internal format that
    is different, and therefore incompatible with say,
    IBM’s C++ compiler.

    Applications written for an OODBMS on platform X
    oftentimes are not compatible with the same app
    on platform Y! This is one of the factors that
    made OODBMS unattractive to commercial ISVs,
    and led to the marginalization of OODBMS in the
    broad commercial software market.

    Spoken from first hand experience, as I once
    worked at Versant!

    Dan Koren

  4. Curt Monash on May 22nd, 2011 4:33 am



    If the OODBMS runs in-memory, however, with persistent storage being used just for safety, then a lot of those objections could be lifted.

    Also, if you’re a SaaS vendor, you don’t need much platform portability anyway. 😉

  5. Joachim Wester on May 22nd, 2011 10:12 am


    You wrote that objects would end up different depending on the language used. This is true only if your database allows you to serialize/deserialize objects. Our Starcounter database does not allow that. The integrety of our graph tuples is not governed by the language and can thus be shared between any language including functional ones.

    Joachim Wester

  6. Joachim Wester on May 22nd, 2011 10:52 am

    I’m old enough to believe in the hype cycle (

    Consider the first wave of the PDA and smartphones of 1992. Then look at todays reincarnation as the iPad and iPhone.

    The hippest social network developers are just starting using JSON path expressions in C# and Java. Wake up the dead and ask them to say, I told you so.

    Just as the case with the PDA vs iPad. What is dead is:
    1. Serialization (bad idea)
    2. Tight coupling to the language (bad idea)
    3. The 90s implementations (most of them)
    4. Trends. You can’t call the iPhone a PDA.
    You can’t call CouchDB a slow ODBMS.

  7. Joachim Wester on May 22nd, 2011 11:40 am

    “Starcounter’s developers have consigned scale-out to the “too hard to bother with” category.”

    Be ensured that we are working on scale-out.

  8. Curt Monash on May 22nd, 2011 7:00 pm


    OK. NOW you’re beginning to sound like you’re actually building something better and new. 🙂

  9. Dan Koren on May 23rd, 2011 12:16 am

    to Joachim:

    I actually stated something more than you attribute: even objects created in the same language, e.g. C++, could be different as a
    result of different compilers being used!

    In Versant and other ODBMS of similar vintage, an object compiled with say, Sun’c C++ compiler would look different in storage than the same object compiled with IBM’s C++ compiler.

    This has nothing to do with serialization or
    deserialization. AFAIK Versant did not serialize/deserialize, storing all objects in their native formats as determined by the compiler. Versant provided language bindings and libraries for multiple platforms and multiple compilers.



  10. Dan Koren on May 23rd, 2011 12:19 am

    to Curt:

    Compiler dependency is irreducible and cannot be completely eliminated — run in memory or not.

    The only way I know of to relax the language dependency of ODBMS systems is to build the system on top of a common object system that is shared by several programming languages — such as Microsoft’s .NET/CLR.



  11. Andreas Renner on May 23rd, 2011 10:05 am

    As some of you have mentioned Versant and our products:

    Yes, we do have several ones: starting from embedded db4o over FastObjects to Versant Object Database. All of them serve different purposes, as we believe that different problems might need different solutions.

    Speaking for VOD in it’s current Version 8.0.1: we offer APIs for different programming languages like C++ or Java. And we have a client for .NET where you can use the programming language of your choice, as the implementation is based on the underlying IL code.

    All of our APIs use the same server implementation with the same underlying schema.

    Of course, you can use the same database from different flavored C++ clients like IBM, Sun, gcc or Microsoft simultaneously.

    Hope that helps,

    Andreas Renner

  12. Robert on May 23rd, 2011 10:43 am

    Probably worth mentioning that for Versant, not only can you use different flavors of C++ clients to the same database, but it is also possible to access that database with our Java bindings … even though the model is defined with C++, so there is some confusion here.

    Also, there are low level access API’s which enable dynamic types. Actually, that is how we’ve written all our database tooling in Java which accesses databases created and used by .NET, C++. Java applications. Though dynamic types exist in C++ as well.

    Sometimes it helps to make a distinction on what an object database delivers within the context of terms used to describe NoSQL technologies.

    Most of the latest emergence of databases used to help with today’s scale-out challenges are talked about as key-value stores. Even the “document stores” fall into this category as well, though they provide an extra layer of meta data extraction so you can query the values.

    The Versant object database can be thought of as going one step beyond key-value … key-graph.

    Versant allows you to partition keys ( any user decided root object )across an elastic cluster of database nodes. However, under those keys are full object graphs, not isolated blob documents or “values”.

    By doing so, there is no requirement to write layers of code to manage relations between types in the graphs in the way necessary using an ordinary key-value store or document store. Any object in the system can be the target of a query, it is not necessary to explicitly extract a meta data layer.

    Even further, these graphs are not isolated, they can have refences to other graph’s objects beneath other keys. In fact, objects in those graphs can reference any other object in the entire cluster and those references are automatically resolved for you at runtime. Updates to these graphs can be fully transactional if desired, not only accessed in a CAP manner.

    Hopefully this helps shed some light on the power of the object database.


  13. Joachim Wester on May 24th, 2011 5:26 pm


    “I actually stated something more than you attribute: even objects created in the same language, e.g. C++, could be different as a
    result of different compilers being used!”

    This might be true for some databases. In many modern NoSQL and OO databases your data is not affected by the language you use any more than it is in Oracle. I.e. if you use C, Java, C++, C#, Ruby or any other language of your choice has no relevance to how data is modelled or stored.

  14. NoSQL,RDBMS,何时,合适? | 数据仓库 on June 3rd, 2011 12:48 am

    […] 我建议SaaS供应商采用面向对象数据库技术 […]

  15. sridevi ramaraj on September 3rd, 2011 1:24 pm

    is it possible to include c++ template feature in oodbms?

  16. keerthu on March 14th, 2013 2:11 am

    Dear sir,
    i want to know about concurrency control in object oriented database.please send any material

  17. GeorgeZhu on July 8th, 2013 1:14 am

    Please let meknow your email and I will send you some docs for your reference.

  18. sumit kumar on July 16th, 2013 11:47 pm

    I am sumit kumar. Iwant to learn database manegment systm n want to know deepely about dbms.

  19. daniela on December 18th, 2013 11:04 am

    a oracle é um SBDOO?? qual o melhor SGBDOO PRA GRANDES EMPRESAS?

  20. 20th Century DBMS success and failure | Software Memories on July 16th, 2014 1:02 pm

    […] Object-oriented DBMS never got off the ground, Intersystems Cache’ eventually excepted. The core problems were: […]

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.