Why I Use OrientDB on Production Applications

Like many other Java developers, when i start a new Java development project that requires a database, i have hopes and dreams of what my database looks like:

• Java API (of course)
  
• Embeddable
  
• Pure Java
  
• Simple jar file for inclusion in my project
  
• Database stored in a directory on disk
  
• Faster than a rocket
  

First I’m going to review these points, and then i’m going to talk about the database i chose for my latest project, which is in production now with hundreds of users accessing the web application each month.

Here’s what i’m looking for in my database. These are the things that literally make me happy and joyous when writing code.

I code in Java. It’s natural for me to want to use a modern Java API for my database work.

My development productivity and programming enjoyment skyrocket when my database is embedded. The database starts and stops with my application. It’s easy to destroy my database and restart from scratch. I can upgrade my database by updating my database jar file.

It’s easy to deploy my application into testing and production, because there’s no separate database server to startup and manage. (I know about the issue with clustering and an embedded database, but i’ll get to that.)

Back when i developed software that would be deployed on all manner of hardware, i was a stickler that all my code be pure Java, so that i could be confident that my code would run wherever customers and users deployed it.

In this day of SaaS, i’m less picky. I develop on the Mac. I test and run in production on Linux. Those are the systems i care about, so if my database has some platform-specific code in it to make it run fast and well, i’m fine with that. Just as long as that platform-specific configuration is not exposed to me as the developer.

I really just want one database jar file to add to my project. And i don’t want that jar file messing with my code or the dependencies i include in my project.

If the database uses Guava 1.2, and i’m using Guava 0.8, that can mess me up. I want my database to not interfere with jars that i use by introducing newer or older versions of class files that i already reference in my project’s jars.

I like to destroy my database by deleting a directory. I like to run multiple, simultaneous databases by configuring each database to use a separate directory.

That makes me super productive during development, and it makes it more fun for me to program to a database.

I think that’s just a given.

My latest project is Floify.com. Floify is a Mortgage Borrower Portal, automating the process of collecting mortgage loan documents from borrowers and emailing milestone loan status updates to real estate agents and borrowers.

Mortgage loan originators use Floify to automate the labor-intensive parts of their loan processes.

The web application receives about 500 unique visitors per month.

Floify experienced 28% growth in january 2015. Floify’s vital statistics are:

• 38,301 loan documents under management
  
• 3,619 registered users
  
• 3,113 loan packages under management
  

When i started Floify, i looked for a database that met all the criteria i’ve described above.

I decided against databases that were server-based (Postgres, etc).

I decided against databases that weren’t Java-based (MongoDB, etc).

I decided against databases that didn’t support ACID transactions.

I narrowed my choices to OrientDB  and Neo4j. It’s been a couple years since that decision process occurred, but i distinctly remember a few reasons why i ultimately chose OrientDB over Neo4j:

1. Performance benchmarks for OrientDB were very impressive.
   
2. The OrientDB development team was very active.
   
3. Cost. OrientDB is free. Neo4j cost more than what i was willing to pay or what i could afford. I forget which it was.
   

Here are some of my favourite features in OrientDB. These are not competitive advantages to OrientDB. It’s just some of the things that make me happy when coding against an embeddable database.

• I can create the database in code.
  
• I don’t have to use SQL for querying, but most of the time, i do. I already know SQL, and it’s just easy for me.
  
• I use the document database, and it’s very pleasant inserting new documents in Java.
  
• I can store multi-megabyte binary objects directly in the database.
  
• My database is stored in a directory on disk. When scalability demands it, i can upgrade to a two-server distributed database. I haven’t been there yet.
  
• Speed. For me, OrientDB is very fast, and in the few years i’ve been using it, it’s become faster.
  

OrientDB doesn’t come in a single jar file, as would be my ideal. I have to include a few different jars, but that’s an easy tradeoff for me.

In the future, as Floify’s performance and scalability needs demand it, i’ll investigate a multi-server database configuration on OrientDB.

In the meantime, i’m preparing to upgrade to OrientDB 2.0, which was recently released and promises even more speed. Go speed. :-)