Reasons for using OrientDB in a relational project

We are currently testing two systems we developed for startups in the UK. They should go live at some point in August (please do keep an eye on our posts). Both applications have database structures that fit in typical relational databases, but we used OrientDB – a NoSQL database – to store and manage the data. I have worked with MySQL for 15+ years and developed applications from scratch, as well as updating/improving existing ones, which gave me reasonable time to experience the good and the bad of this relational open-source database. It is very difficult to find a system that is 100% relational. Many systems will have a mix of requirements, and DBAs will try to bend their databases by optimising queries and tables. Such work is both expensive and time-consuming.

What follows is a list of good reasons why one should consider using OrientDB to support the development of any software application.

OrientDB is free. Yes, it is free for real. Some features are only present in the Enterprise Edition, and if you do get to the point that you need some of the Enterprise features, then you will certainly be earning enough money to afford its cost.

OrientDB uses the SQL language your developers are used to. There are minor additions to or differences from MySQL, but nothing that would put anyone off of the game.

It is significantly faster than MySQL. Here at Techifide, we’ve found that OrientDB performs 30 to 40 times faster than MySQL when traversing tables, but the database we used to test wasn’t too complex or too populated. This means that if a query takes 1 second to retrieve data in MySQL, the same query would take 0.03 seconds to fetch the same data in OrientDB. Bear in mind that a NoSQL database performance gain is more evident when data is complex and immense. The simple fact that your database is ready to store and retrieve large amounts of data should give you peace of mind that your app will be ready to support your business growth.

OrientDB can easily grow or expand as you develop your app. Flexibility is key in every project, and it is absolutely necessary for new applications or MVPs (Minimum Viable Products) in which you will need to plug in extras around the core functionality. In NoSQL databases, we can add/remove columns without downtime; they are built for that. In SQL servers, such updates can be painful, especially if you have already stored some data as and/or dependencies between tables/columns.

In OrientDB, foreign keys and optimisation are done for you (at least most of them). There are many techniques used to optimise a relational database, but primarily you will be looking to create foreign keys, reduce the use of subqueries, and apply de-normalisation. In a NoSQL database, pointers to the linked records are automatically stored in the related data, which both ensures speed when retrieving information and saves a lot of development time.

Modern web applications use API Gateways for communicating data in JSON format. OrientDB is no different. It has its own REST API, returning database query results as JSON. In MySQL, we have to loop through the results, create data objects or arrays, and then convert those objects to JSON. With a REST API on the database side, we can simply output the returned query result, which again, saves a hell of a lot of development time.

Until recently, transactional queries were only found in the SQL databases’ realm, and this was the first reason why developers preferred SQL over NoSQL DBs, but today most NoSQL DBs (including OrientDB) support this feature and are ACID-compliant (Atomicity, Consistency, Isolation, Durability).

So, considering the following list of pros, why not adopt OrientDB for a transactional data structure?

  • Fast software development
  • Low development costs
  • API-read database
  • Data returned in JSON format
  • Atomicity
  • Data Consistency
  • Data Isolation
  • Data Durability
  • Flexibility