A word or two about OrientDB

I’m writing this note due to the fact that me and my team have wasted hours and days in result of problems that has been built into the OrientDB due to trivial mistakes made in its development process. After years of development in Open Source society, I know that expectations a person may have of an open source and free tool is different to a commercial equivalent but the common practices of same Open Source society persuades that if a tool, application or a piece of code is NOT production ready, at least let the user know so that he decides it by his own where or not to risk using it. Unfortunately OrientDB team goes into the opposite direction. With over 1000 open issues on GitHub, they are all pushing their product as production ready and doing their best to cover bugs and problems. This is not ethical not in the definition of Open Source neither in definition of commercial software.

This is not ethical not in the definition of Open Source neither in definition of commercial software.

the story

Around 8 months ago our team started working on a new project. A project from scratch, This is the opportunity that a developer will not really find so often and therefore we decided to make a good use of it. A new system design based on reactive model, a new code structure and even a new database system.

The tests and evaluations began, we agreed on some technologies and there was also the intention to use some graph database instead of a classical relational one. After a while evaluating different solutions and considering that most of the development environment was Java and JVM based, we decided to go with OrientDB. It seemed a nice fit in, all pure Java, open source, free and had a lot of very interesting features. Even the early tests showed satisfying results.

At some point we closed the feature set and technology stack and started developing. As normal in a programming challenge, from time to time we had problems and troubles with tools and technologies we were using however in contrast to normal flow (where problems become less often) as the product emerged, there was one specific category of problems that were increasing in size, and that was surprisingly the database related things.

We had previous experience with new databases where we had problems at beginning because of the fact that we did not know it, but with OrientDB it was the other way around: at beginning everything was smooth and working (or at least it was advertised to be so) but the longer we used OrientDB the problems were found!

… at beginning everything was smooth and working (or at least it was advertised to be so) but the longer we used OrientDB the problems were found!

minor bugs and workaround?

Soon we were investing more time debugging database problems and bugs than our own code base. Finding workarounds for things that should have obviously and simply worked. It took an extensive amount of time and we were not sure anymore if something works in staging, it could also mean it will work on production. Unpredictable factors (like simply running server longer) seemed to have major effects on DB.

Another problem was the way OrientDB's development team reacted to bug reports, in many cases the only answer we got to a bug report was that it is (or will be) fixed in a newer version. This could have been no problem if the upgrade process was not again troubling.

instability on production releases

What we soon learned from upgrading database was instability and inconsistency. What worked in 2.0.8 may not work in 2.0.9! new releases offen contained a bunch of regressions and we had to find new workarounds for what was working on older versions and not any more on more resent ones. On other hand upgrades where inevitable because from time to time we bumped into a bug that was only solvable by upgrading.

… new releases offen contained a bunch of regressions and we had to find new workarounds for what was working on older versions …

testing before releasing?

It seems to me that OrientDB does not really take testing seriously. Not even simple primitive positive tests. Query parser has serious problems, database get in inconsistent status every now and then. We found edges that could be read from one side but not form other side. Even simple use cases needed workarounds. What we found on one version as a problem’s workaround did not work on a newer version and we had to invest even more time to find new workarounds after each upgrade.

introducing new features before fixing existing ones One big mistake that I think OrientDB is suffering is their hast in introducing new features. Where there is a large amount of bug reports, they just keep pushing. It seems to me like building a ruin on top another ruin and OrientDB team has to stop it seriously.

walking away

From what I have seen from marketing activities of OrientDB, I expect their response and reaction to this post. I want to just say whatever is here is just my personal experience in hope to help another team waste their time on it. I’m not willing to start a debate over it. OrientDB could potentially be a great piece of software, but it is way away from it now. I even may come back to it later but for now we are walking away.