is ObjectDB production ready?

Question

In this benchmark ObjectDB is far the fastest DB: http://www.jpab.org/All/All/All.html

But I cannot see any other benchmark results from ObjectDB. Is anyone using ObjectDB? Is it production ready? What are the experiences?

Answer 1

I've used it for a number of projects and products, both professionally and personally. I've used it for a little over 5 years now. These are my experiences of it:

Disclaimer: I own a server license and an OEM license, and over the years have got to know the creator(s). I have no other commercial relationship with the ObjectDB company - in other words, I gain nothing commercially if they sell more copies. I just like the product.

My usages:

1. personally: I used it as part of a commercial product that came out of my phd, to persist UML2/EMF models. these are complex things with many, many classes and ObjectDB was the only product i was able to find that could handle the complex linking with adequate performance. it has been a stellar performer in this environment.

2. work related: I work in an investment bank and we used ObjectDB to persist the workflow states and handle persistence in a large grid (>2000 nodes) environment. It worked very well in this environment as well.

I was also a consultant to Gentleware at one point back in 2007 or so, and we evaluated ObjectDB against db4o, hibernate etc. It outperformed any competition by close to an order of magnitude. This was my first commercial experience with it.

So, the bottom line is that I have found ObjectDB to be extremely fast, and rock solid. We tested it up to 10GB alone on the UML2 models and there were no problems there. I've never had a database die on me or get corrupted in all my time of using it. Furthermore, its footprint is pretty small. In short, it's a bit of an unsung hero in the space.

My experiences concur with the jpab benchmarks - they make uncomfortable reading for the owners of other products, but... perhaps i'm not completely unbiased in this though - i've had much contact with the creator(s) of ObjectDB over the years and pushed them to release the benchmarks. in particular, i felt they should make the graph linear rather than logarithmic - it shows the performance of ObjectDB is vastly better in most cases.

As an aside, the reason why you won't find many other benchmarks on this or any other JPA product is that none of the vendors can generally agree on a benchmark and tend to accuse others of bias. I've seen this first hand many times. Some people prefer polepos, but this is dominated by db4o and those people won't release the dn results for instance. Some database vendors won't allow results etc. It's a minefield and the creators of ObjectDB are no different here. Everyone likes to control their own benchmark ;-)

anyway, to cut a long story short, my honest experience is that ObjectDB is very quick, production ready (for a number of years back to 1.x) and well supported. It's a very good product.

Answer 2

I'd not trust that benchmark without independent verification. If you check the copyright information, the site is actually owned and operated by the owners of ObjectDB!

That said, I've no data to counter their claims, I'd just not take them at face value.

Answer 3

We have been using Object DB in our startup for a little over 5 months. We hesitated a long time before settling for objectDB after looking at different technologies (RDBMS, Graph db and object db). We are developing a web based business application and we had a set of requirements for our persistence layer. We considered amongst others : MySQL, PostgreSQL, Derby, Db4o, ObjectivityDB, Perst, Ozone, Neadatis ODB, Neo4j, OrientDB

Our requirements were:

• Mature product for stability
  ObjectDB is more than 6 years old – In version 2.2.9 as we speak
• Supported with a community
  We wanted to make sure there is someone to help if we have a problem and so far we are very happy with the speed at which we get answers to our questions. The community could be larger but is very active.
• Speed of development
  For agility and fast functionality turnaround an object database is incredibly easy and straight forward. We considered RDBMS + Hybernate but that was slow and a little convoluted
• Capable of withstanding heavy load
  Nothing scientific here but we wanted to feel comfortable that the system could handle a large number of concurrent requests. We tested up to 1000 concurrent requests, a mix of indexed queries, object updates, creations and deletions and collection updates to try and mimic load on our app. ObjectDB came out in the top 2
• Fast
  Same here we used the same type of queries and timed them, we also increased the load to what we think is going to be a reasonable guess of our post go live load and again ObjectDB was constantly in the top 2
• Capable of handling large amount of data
  We gradually increased the number of customers in our DB to 5 million customers (that’s a little optimistic) with 1 to 5 orders each and checked the performance. There was no significant performance decrease (with the right indexes in place!)
• Open source/cheap
  Small issue with not having access to the source as we are using GWT and it sometimes causes issues with serialisation of managed collections and dates (although a workaround exists)
• JPA support
  If possible we wanted JPA or JDO support to easily integrate with existing frameworks (Spring) and be reassured that worst comes to worst we can still go back to an old RDMS systems – although I have to say that object persistence is so easy and transparent that it is sometimes hard to stick to the JPA requirements.

All in all, ObjectDB was constantly in our top 2 contestants, sometimes first, sometimes second hence our choice. Also the frequency of bug fix and new feature releases is impressive.

I hope this helps, if I have sometime before our go live (early next year) to put our results in a presentable format I will try and post them here.

Answer 4

I have also have been using ObjectDB for many years (I think 7 years) in a commercial capacity. Our company has two products that use the database (both embedded version). One of our products displays information about the signals sent between mobile devices (ie mobile phones) and a simulated network. Although we in effect create a separate database for each test that we run we can often save up to 1GB of equivalent XML data into the database.

The speeds for saving the data are very quick (normally faster than asking Windows to make a copy the equivalent XML file). The retrieval speed is excellent allowing us to scroll through thousands (even tens of thousands) of graphically represented items as if scrolling through a Windows explorer file directory.

ObjectDB is an excellent product and one I hope to continue to work with. When we were developing our products we encountered the odd problem (although we've not had to report a single thing for as long as I can remember) but the speed with which we have had a resolution to every problem has been the best I've ever encountered.

To answer you question of "Is this production ready" well, in my opinion, it most certainly is.

Answer 5

I'm testing ObjectDB on a small project. Here are my remarks:

• There is not much of documentation/tutorial while working with JDO. You have much more documentation with JPA.
• Tutorials are too simple and far away from reality.
• I met 2 bugs in the DatabaseExplorer. But it was quickly fixed in the new version.
• The forum support is very good, I received an answer quickly.

Compared to Versant DB with the same project and ObjectDB is more straightforward for getting started.

Answer 6

I'd not trust that benchmark without independent verification. If you check the copyright information, the site is actually owned and operated by the owners of ObjectDB!

Even more importantly, data is one thing, explanations another one. And there really is an explanation missing as to why it should be faster by a magnitude. This, and the fact that the benchmarks shown on their website are VERY low in count and therefore only show a VERY small part of the entire picture, seems very strange to me.

My experience (in general, not with ObjectDB) is that, for example, hibernate depends on work load type, and, if you need to migrate a database, you need to explicitly adjust hibernate behavior to get a decent performance. Does ObjectDB support caching? Does it only excel in large throughput scenarios that trash caches?

Update

I just read http://www.objectdb.com/database/forum/259. The typical nemesis for speed is, guess what, consistency. It seems ObjectDB does not support any reasonable concurrency model at all. So, it's basically just a NoSQL store?

Answer 7

The standard industry benchmark is,

http://www.spec.org/jEnterprise2010/

which heavily uses JPA

Note, that it tests the entire Java EE server, not just JPA, but JPA is the most significant part of the benchmark. The main JPA products have submitted results through their respective application servers.

SpecJ is not as easy to compare products as the JPAB results, as most results are on different hardware, but the results are all peer reviewed, so can be more trusted. It is also a simulated real application, with multiple users, a large database, concurrency and isolation requirements and most results are on a cluster.

There are no ObjectDB results available, but in theory since ObjectDB supports JPA it should be possible to run SpecJ on it, and compare it to other products yourself.

Answer 8

I have used ObjectDb for 10 years and have been very happy with it.

Admittedly, my database is relatively small, but I went from constantly tripping over hibernate upgrade issues to just not having to worry about it, which has saved me tons of time over the years.