ObjectDB is a powerful object oriented database management system (ODBMS). It is compact, reliable, easy to use and extremely fast. ObjectDB provides all the standard database management services (storage and retrieval, transactions, lock management, query processing, etc.) but in a way that makes development easier and applications faster.

Not having a platform/language neutral on-disk format is a huge mistake. Databases tends to live forever, and languages and platforms don't. What if I want to access the data from a .net app, or c++ or whatever? Or migrate the entire app some day?

But the most important - it is the only object database with built in support of JPA! You can pull your data from ObjectDB easily as JPA entity objects and transfer them anywhere using Hibernate, EclipseLink, OpenJPA, etc. Which other Object Database offers such an easy migration?

Use ObjectDB for ease of use and extremely high performance, and if necessary, keep your data also in a relational database, using the same JPA source code.

That logic is flawed. It can't be both cross platform AND depend on a JVM. I don't care what Derby, etc does. Anyway, for jvm fanboys, this is a nice product. I'm just saying... for a long-term mission critical database backend, I'm rather dubious.

I can see your concern on JVM- dependence... Still a?nything which replaces ORM tools and relational dbms is to be welcomed! Dependence on Java is excusable... If ObjectDB can serve as a general purpose dbms for simple to medium sized Java applications, then it will be a great leap forward!

ObjectDB is the only Object Oriented Database with built in support of JPA 2.

Java Persistence API (JPA)

Most features of JPA 2 are already supported.

Support of additional JPA 2 new features is in progress.

I'm actually excited about the built-in JPA 2 support. I'm doing a book on Spring, and haven't decided which database or implementation I'm going to use in the section that discusses Spring and JPA 2.0. I'm thinking ObjectDB might be a nice choice. But I'm a bit nervous about the whole "Most Features Supported" thing...

Congratulations on the release Ilan! I know the large amount of hard work that went into it.

I'm actually excited about the built-in JPA 2 support. I'm doing a book on Spring, and haven't decided which database or implementation I'm going to use in the section that discusses Spring

Just to offer a simple datapoint in ObjectDb's favour if it helps. I've used ObjectDb1.x fairly extensively over the last few years to persist EMF models for my phd, and migrated to ObjectDb2.alpha/beta at one point. It's one of the most robust, impressive pieces of software I've yet used. The quality and performance is phenomenal. If you used ObjectDb, I doubt you'd be disappointed.

and JPA 2.0. I'm thinking ObjectDB might be a nice choice. But I'm a bit nervous about the whole "Most Features Supported" thing...

JDO has lots of optional features. Most implementations only support a subset of them. I was very pleasantly surprised by the extensive coverage of the optional features of JDO1.x in ObjectDb1.x. I'm guessing it is the same with JPA in this case.

Andrew

p.s. disclaimer -- i have no ties to objectdb apart from being a satisfied user.

there is no need to point, and say they too do the same thing. the question asked here is what did u do any different? u r simply depending on jvm thats all.. all this jpa stuff is bs..

there are many aspects to portability. one is data portability between platforms. another very important aspect is source code portability. JPA, as a mature spec, is very important for the latter. JDO is in the same boat, but with less industry buy-in. i've personally migrated between objectdb and datanucleus using H2 which was possible because both support JDO.

i did my face-off about 3 or 4 years ago, but when i directly compared odb and db4o, I found:

1. objectdb supported jdo out of the box. db4o had a proprietary interface. datanucleus subsequently has started supporting db4o.

2. db4o didn't have transparent activation. i believe it has subsequently added it.

3. for my use case (storing large UML models with the Eclipse EMF infrastructure, >10gb), objectdb resulted in smaller databases which were 4x-10x faster on retrieval.

4. the client/server mode of objectdb was far more robust.

5. the licensing fees of objectdb were more reasonable and the team behind odb seemed far more willing to consider size of projects etc when looking at licensing fees. db4o at the time were asking for something like 10% of the cost price of my product.

6. jar sizes for objectdb were comparable with db4o.

As i've said before, i have no commercial affiliation with either database vendor. I have previously used a range of objectdatabases from versant through objectstore in telecomms and finance. I'd rate objectdb over all of them.

Dumbest thing I've read today. It's the IMPLEMENTATION that needs a large community, not the interface specifications...

a multi-vendor spec with wide community support is very important, and if you believe this you are either inexperienced or being disingenuous. if you use JPA and target objectdb, then moving to datanucleus (another excellent product) is straight fwd.

if you use db4o's interface directly, however, nothing will save you (not even the implementation community) if you need to use another product. and if you are not using GPL, it is a commercial product. you are stuck with the vendor.

anyway, i've given my views -- i've used many of these object databases over the years, and i can say, hand on heart, that objectdb is possibly the best and most impressive i've used. it's fast and an impressive product. i wish my stuff was this good. i stand on record as stating that i have no commercial affiliation with objectdb apart from being a satisfied customer (I will provide the receipt email from plimus via email if you contact me via my javalobby address). i want to see the product do well, because it deserves the success.

however, you've done nothing but complain and dissemble. how about giving us some (any) technical substance for your arguments? have you used these systems? do you have any insights? or are you just trying to confuse people about an excellent product because you are argumentative?

whoops, should have been: "a multi-vendor spec with wide community support is very important, and if you don't believe this you are either inexperienced or being disingenuous"

But I am experienced and ingenious and thus know that the community of an actual implementation is infinitely more important. ObjectDB has about 5 postings on their forum, most of which are by the company itself. Not exactly a "tried and true" product I'd trust my precious data with in a hostile, fault-infested and highly concurrent environment.

But I am experienced and ingenious and thus know that the community of an actual implementation is infinitely more important.

your inflated opinion of yourself counts for little. you clearly have no experience using databases of this sort.

the important things are the *quality* of the implementation and the acceptance and quality of the API.

ObjectDB has about 5 postings on their forum, most of which are by the company itself. Not exactly a "tried and true" product I'd trust my precious data with in a hostile, fault-infested and highly concurrent environment.

unsurprisingly, you haven't provided any technical substance whatsoever. the forum has clearly been recently released with the redesign of the website and of course contains little in the way of comments. i know this because i've seen the website change in the last week.

until you are prepared to technically understand these products and use and evaluate them, your comments are worthless. all you are doing is arguing your entrenched position, as a matter of pride.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.