OrientDB Reviews

1. Elaborated documents for a beginner without any graph background knowledge to grasp basic graph theory and orientdb practice.

2. Build on Java platform, which is our company's main dev language as well, it's too easy to spend much time customizing various implementation as we demand.

The infrastructural graph engine/model can't support too much online real-time concurrency(OLTP), especially when facing to plenty of edges concurrency maintenance on super node.

As of now, we can realize real-time in other way, it'll be just perfect if someday orientdb support high-concurrency well.

Although orientdb is still not the top1 graphdb in market, its rising trend cannot be ignored. It has proved that the customers and market admits its abilities and features, whatever multi-model, or ease of use, or powerful graph traverse engine, or distributed architecture. Almost every element with regards to internet technologies is introduced in. What are you waiting for?

Since we're a financial company, the scenarios we leverage orientdb to satisfy are:

1. anti-fraud, based on transactions, payment, orders, GPS, phone call, etc. Actually this is similar and applied to any social network model.

2. RPC invoke chain, collecting rpc invoke records into orientdb, analyzing the bottlenecks or design issues.

We’re a consultancy company who helps clients adopt Big Data technologies, and Graph is increasingly becoming an important aspect of the data-stack; especially for complex and connected data-sets such social network applications and analysis. We have a number of customers using Orient with 50-million + node/relationship workloads. We’ve worked with all the major Graph platforms and Orient is currently our preferred choice. Performance is great and the query language, being a hybrid of standard SQL & Graph means adoption is easier than if using Gremlin or Cypher, both of which look great at first but query complexity can escalate rapidly. Orient’s mix works in practice. Another feature we like is the ability to query it via standard JDBC connections, which means standard tools such as DB Visualizer work; which just make using it more pleasurable than rivals. We develop in Java, and their APIs are rock solid. Pricing is also more reasonable that rivals; making horizontal distribution more practical.

Sometimes the Orient Studio forgets the visualisation settings for the Graph so all the lovely setup work you’ve done to make it look pretty gets lost. Sort it out Orient!

We use Orient for its Graph capabilities, where Orient is very fast. Make sure you understand Graph query and why you'd use them.

Various types of network analysis, both for commercial and government. We’re also looking at helping to implement social network style features and newsfeeds, the recursive nature of which Graph is perfectly suited for.

This is an easy to install DB.

The fact that it's SQL is very close to relational SQL makes it easy to use to most developers.

The results from querys are extremely fast.

Graph and Document characteristics combined make this DB very unique.

Embeded maps are extremely useful.

Drivers are a down side in this datababse. Connector drivers should be improved - but this should not stop you from choosing this DB.

OrientDB's documentation is not always up to date.

There is no import button in Orient Studio. Imports must be run manually.

Changing attribute names can cause problems.

If you are looking for a flexible database, quick to learn, easy to migrate from other databases, this is the one.

Another thumbs up is the fact that it is free.

Big Data, database analysis, graph database / non-relational data structure, fast development.

OrientDB has a really friendly licence. This is essential for our research purposes. The main aspects we have liked is that OrientDB is easy to understand and to use. It combines schemas, documents and graphs in an easy and simple way. In addition, it is well documented and has a large community providing support.

More than dislike, I think it is a feature request :). OrientDB has already integration with Python and is compliant with Apache TinkerPop. We hope new versions of OrientDB will bring higher integration with specific Python tools such as NetworkX.

We have been working in the H2020 project MixedEmotions (http://mixedemotions.insight-centre.org/modules) for analyzing the social context of users, that is, how emotions are propagated in the network. OrientDB has been used for storing and retrieving ego networks. Analyzing how emotions are propagated is used for marketing, brand monitoring, radicalism detection, etc.

The friendliness and support from the staff, even in the OSS side of the dev process.

The database needs better driver support. The full text search is good, but it would be great, if ODB supported Elasticsearch natively, like Titan does.

Version 3 is going to be the "final" version. The ODB team have gathered a ton of experience over versions 1 and 2. They will be culminating this knowledge and experience in version 3.

The prospect of having polyglot persistence is a huge benefit, since it can cover so many use cases. This is the magic of ODB. But, at the same time, it could be its Achiles heel, due to the complexity. Getting that to "simple" will be the big challenge, which I hope will happen in version 3. Still, the database is quite amazing to use, even though it has its teething pains.

Multi model Nosql database as we can trust in our operational business . The best performance in graph , document , indexing , read and write with intensive data .

Documentation integration and lack of examples , best practices and social tutorial system .

if you want to choose a right product for Operational Database and working with graph , documents , key-value , spatial , analytical with the painless configuration and a good support in communities , i suggest to use OrientDB in your business environment .

If you be familiar with the simple and basic concept of OrientDB in operation , you can easily switch to achieve more performance in read and write iops as you reached .

We have use OrientDB in a CMS and a Mobile location based service .

our CMS service use OrientDB document base features actually . the highest read and write is our founded benefit in OrientDB .

In the location and mobile based scenario we used orientdb graph and spatial features too .

There are several function for working the graphs like the shortest path , Dijkstra , A* and many standard Geo spatial functions in OrientDB that provides facilty and ease of use to making a business better .

OrientDB is a open source and live database project in github so we can contribute to growing together . we can write modules , functions or report our issues to orientdb project and receive a nice , fast and friendly online support .

OrientDB have a native and official support for wide range of developing platforms . as we experienced with nodejs and java api , we can develop our software and services and connect fast and secure to orientdb remotely and easily.

Quite easy to install.

It has good drivers for working with various programming languages, and also a great plus is the ability to work through REST.

A mixed model is an excellent solution for storing complex data, and built-in classes and inheritance solve many problems.

It is very convenient to work using SQL like requests.

Weak documentation. Many powerful things are simply not described in it.

Use it, if you need the best graph database engine

Work with large amounts of data. Quick search of results in the graph. Convenient use with several programming languages.

The thing I like the most of OrientDB is the rapidness of the development team.

The most of the request and questions are replied almost instantly. When I started using the software it was quite buggy, but collaborating with the team was really the plus to make the software better and the usage simpler.

The software is rapidly evolving and the features comes and goes. The development process should be more predictable and new features should be added only if necessary.

At least the previous version should be supported.

Please consider that using a new language (also if inspired to SQL) will be a cost for your developers.

Consider also the cost of following the software evolution since many features are constantly added and to use Orient in a smart way you should always be updated on his news.

I use Orient in embedded mode as main database for a web application with hundred of users.

The best benefit was obtained for graph query performances.

The main feature that as a user and from the perspective of benchmarking that I found was that it is embeddable. I can simply use the the database by including a jar, and update whenever necessary. No mash-ups or complications of explicitly having to maintain the server started for the database. Also having implemented the Tinkerpop stack which is the standard for graph APIs, there is little transition time from using other graph databases to OrientDB. And ofcourse the SQL to Graph transition becomes simple as it supports SQL based syntax.

Many a times when nodes go down (using a distributed setup), there are inconsistent states left hanging loose. The database has to be deployed again. Also when I scaled up my cluster I had to manually move all the data in the smaller cluster to the bigger one.

It's certainly the newest idea for combining document oriented storage and graph functionalities. I would definitely recommend it to a user who would like to easily deployable a graph database/ document database through code. It is also extremely fast on the small amount of data, but for very large graphs on distributed setup it proved otherwise,

I have been trying to benchmark our graph analytical framework against various graph databases like Titan/OrientDB/Neo4j. But ours being a distributed Graph Database and using graphs having billions of nodes and performing OLAP and OLTP operations on that, we found that Titan scales and performs better than OrientDB when dealing with billions of nodes in a distributed environment.

Orientdb gives a very flexible java api which enables developers to develop their applications on top of orientdb very easily.

Also the rest api enables developers to directly access javascript functions on orientdb. It specially suits for angularjs based web applications so that the db access layer can be implemented directly on top of orientdb .

Has some major issues about the stability. I have experienced huge performance issues when accessing classes with records more than one million. Therefore to enforce indexes we had to change most of our queries by manually checking what index is good for which query.

Also we have the experience of corrupted NOT_UNIQUE_HASH_INDEXES and we had to manually drop them and rebuild them in order to get the db working again.

Orientdb is great for rapid application development.

But when you application scales you may have issues with the stability.

We maintain a rapidly growing database which contains some critical data. With orientdb what we tried to archive was to have maximum availability with considerable amount of accuracy with time.

- Mixed model allows for very flexible solutions. Classes and inheritance is a great way to approach complex solutions

- SQL-like querying makes life simple. Extended functionality set for graph traversals and in-query manipulations is a great asset for the language

- Build-in Lucene indexing allows for more flexible queries

- Studio is a very convenient tool + graph visualization is very helpful

- Variety of language bindings

- Database functions is a handy addition to the overall feature set

- Good documentation

- Lack of stability and/or testing (e.g. bug version releases often introduce new problems)

- Binary protocol lacks flexibility (but otherwise is good enough for production environments)

- Might need to improve speed and efficiency (especially in removal of graph vertices, edges)

Patience

We are aiming at providing clients with more insights on what their partners or clients might be interested looking into. Graph allows for that with ease.

Simplicty for graph & document DBs, uniq ACID support in NoSQL world. And being an opensource project with those properties makes this product unique. And being able to replicate to remote DC is a perfect feature.

Random crashes when running SQL from its web client is a big problem which makes me sad after great expectations from this project.

If you need SQL style queried DB server with transactions, clusters and HA with open source, only DB to use is OrientDB. As it is fully open source, you'll not find yourself naked as happed to me for FoundationDB.

Clustering with transactions and HA support gives us opportunity to sell extra licences for same product if customer needs to run on multiple servers.

The best thing for me is that I can use it as an embedded database inside my server avoiding network overhead.

Also low level functionality is available for me with Java API and I can avoid using SQL and other languages.

Massive usage of mutable state and ThreadLocal variables in the OrientDb source codes could introduce tricky bugs.

Documentation is not comprehensive and far away from this. So I have to read source codes to find out a solution.

I have a DSL language which allows to define a data structure and define business logic. This makes OrientDb almost ideal solution for me because I can use low level feature directly avoiding overhead from network communications and other languages such as SQL.

The community.

The people there are very helpful. You can get an answer to almost any of your questions within a couple of days.

Data model

The data model is very convenient for creating representation of any type of domain.

Performance

OrientDB uses several advanced techniques under the hood that make it really fast.

There is no cost-effective managed service. Sometimes it is cheaper to set up AWS RDS, instead of hiring a person who would operate instances with OrientDB

If you are looking for a self managed OLTP database with data model similar to OOP, OrientDB is a good choice.

User support was a part of my responsibilities. I was helping different companies to build their applications. So I saw OrientDB in many different use cases.

The main advantage of OrientDB is that its data model is very similar to data model of OOP, that's why it is very convenient for most applications that is focused on business logic.

Scripting with JavaScript is incredibly useful, especially if some of your team members are more proficient with front-end technologies.

Documentation touches most topics, but it does not go into enough detail in almost all cases and there are way too few examples. The OrientDB team really needs to put more resources into documentation and code examples.

Also, there is a lot of work to be done on the web interface. Its heading in the right direction, but definitely still in its early stages.

Still a young product

We are building a product with some very complex/deep relationships with very large data sets. Graph databases have made it much easier to model these relationships than the relational alternatives.

SQL. OrientDB supports multiple commands (such as insert, query, update, delete, traverse, and more) all through the use of SQL. It should also be noticed the Orient team is very active on github, including support for bugs, new features, and help on any matter for it's users.

Also, although not used thoroughly (yet), OrientDB is scalable. For write & read. Which is a very important thing, specially in today's world.

It's web interface. Orient web interface feels immature, and a bit too complicated for the task it should do.. Also, some of it's simple commands seems a bit awkward. A simple example would be connecting to a database, after connecting to the server, which will still require you to enter credentials, and the connection information (host, port, etc, assuming they are needed for the server as well).

Try it. OrientDB has good performance, it is easy to use, and has a wide support.

OrientDB helps me both query "simple" data, much like any other database, and find connections between people in a fast way.

OrientDB is the only NoSQL database I have come across, that has the potential to be an everyday's database usable for any type of project, giving you the full range of features (including SQL as query language) you have been used before using your relational database systems plus all the advantages of NoSQL databases in one single database system. No need anymore to select the most appropriate relational or NoSQL database, OrientDB does it all and does it all very well.

A lot has been added to the SQL dialect lately. A lot of the late additions make me feel like that it was more important to have some language construct to be able to access a new feature fast rather than thinking a little bit more about how to add new language constructs the best way so that the dialect maintains to be a consistent SQL dialect rather than slowly growing into a language of its own, rather confusing at times and rather distinct from SQL.

Simply just use it! You will fall in love and replace your relational database systems with OrientDB, I did, at least.

OrientDB has replaced MySQL and Postgres as my first choice database system. The only other database "system" I am still using besides OrientDB is Sqlite, but as soon as data amount increases, OrientDB is my first and only choice at the moment.

What used to be complex and slow SQL queries against relational databases are now simple and short SQL queries performing fast and making it a joy treating the data in my databases as object graphs rather than trying to rebuild objects from relational data using complex and slow joins.

What a non-sense really, we used to serialise objects to relational data for years now (INSERT, UPDATE) to try to rebuild the objects again when fetching the same data later on (SELECT). Thats all over now.

OrientDB is very easy to start with. It's also very flexible as you can use it as a simple document store (like MongoDB). As a document store with link (a unique feature of OrientDB) and as a graph store. Graphs can be queried in a SQL-like language so it's quite familiar to most of us.

OrientDB sometimes looks like a Beta product, crashes are quite common (specially using the UI). Their documentation is incomplete or not very clear sometimes, others is simply outdated. Sometimes you feel like they have tried to do too much before fixing some bugs that look like they occur very common.

Also, their Gremlin version is outdated with the current Gremlin documentation so, sometimes is quite difficult to figure out how to do something.

Be prepared to find bugs very often when using the console and the web UI. Also, be ready to really dig into the documentation struggling on how to do some things that you'll finally do by pure coincidence. You won't find many tutorials and most of the information you'll find is about Neo4J. Be also aware that in first quarter of 2016 its compatibility is with Gremlin 2 (current version is 3)

We wanted to graph some dependency tree and we had two options: Neo4J and OrientDB. We choose OrientDB as it was completely open-source (so we could contribute when finding errors) Its licensing was with Apache 2 license, a real advantage in terms of "princing".

The recommendation engine my colleagues and I coded using OrientDB is actually working in this very moment. In the end, it turned out to be a solution for us. The studio it provides is also quite useful and pretty, especially the graph part of it. And it's a relatively cheap solution after all.

Bad documentation. New versions breaking code written with old version. The SQL-like syntax is only useful for basic queries, which a complicated project will not limit to. Using gremlin is painfully difficult.

If you can afford Neo4j, choose Neo4j. If you are ready to have a bit of headache and not a lot of money to spend, OrientDB will probably do the job after all.

The business problem I was solving was to create a recommendation engine on top of a graph database and make fast queries of type "start from this vertex, give me all its neighbors by this edge and their neighbors by that edge and sum the weight along the edges". And do it fast.

How fast we were productive with Orient DB - right from the start

The lack of understanding by some of our own system integrators into why we would choose a graph DB versus an Oracle SQL based table solution. I think if Graph DB's were more ubiquitous it would be an easier selling point to the higher level decision makers on software architecture

Look at the other graph db vendors out there - we found Orient to be the one that was ready for production. We integrated it into our business logic and it performed quite well, and we in our opinion the only choice at this stage.

We have now and have had in the past - equipment that is connected in a star, bus, and tree structure. The ability to find the equipment, and provision it all starts with a tool or database that closely models the topology. Clearly for us, a graph DB was the choice and Orient passed all the tests for being the implementation we wanted.

Fusion of object-oriented and document/graph features in the one single database. I also like very fast access to the linked entities which OrientDB provides by using the notion of 'pointers'. You literally have O(1) complexity in terms of accessing nested and linked entities.

This database also has a multi-master replication feature which means that you will have less sleepless nights if, for example, one of your database servers goes down. The other ones will correctly handle this problem.

This database has any possible feature that you'd ever need. It's blazing fast, supports multi-master replication (as I already mentioned) and has Apache 2 licence which means that you can use this database for your commercial products.

If you run into a bug, don't hesitate to create an issue at Github. Most of the bugs are solved in 1 to 3 days which is quite impressive for so massive product.

In general, OrientDB suffers from childish problems. For example, embedded maps were broken since OrientDB 2.0.1 and nobody noticed that (until I created a bug report). Import/export feature was also broken for a long time and it seems that I was the only one who was using this feature back then.

Most of the problems were quite simple and had been fixed very fast (thanks to the OrientDB team).

Try to build a prototype which will be using all the database features that you're gonna need in your final product. Trust me, it'll save you a lot of time.

The first project where I was using OrientDB was about creating a custom web-based platform where users can create domain model with UML notation. Here's where OrientDB showed its power. We were able to create all our domain model on the fly which would've been very inconvenient if we would've chosen a relational database.

That fact that OrientDB uses lightweight pointers instead of JOIN operator gave us a serious performance boost in terms of retrieving interconnected entities.

easy installation on raspberry pi and operates smoothly on it.

The system persisted about 2 million registers of data without problems.

Orientdb never stopped. (one year).

The web application for database administration is pretty good.

The web application for database administration is pretty good.

The flexibility about choosing operational mode (Document database, graph database, ...)

The Orientdb documentation seems good, but I have problems in searching about specific practical situations (ex: website "stackoverflow")

I'd like to have more documentation about accessing orientdb from python and JavaScript languages.

I need write data quickly and handle high volume of data as well.

The database is easy to install and integrate with existing architectures since it supports both JDBC, a SQL-like query language, and strong tools that run in the web browser and provide visual indicators of how the database is performing.

Documentation tends to be updated slower than one would expect and there isn't enough emphasis on securing the installation in the documentation. Much of the documentation assumes that you're installing in a standalone mode and not in its clustered modes (which work very well).

You need to perform a proof of concept with orientdb from the perspective of a graph database and not try to turn it into a relational database with graph features. If you do that, you will not find that it meets your criteria. Since many relationships are well represented with graphs and easily traversed with graph queries - you will need to make sure that you go into the project with the right mindset or you will find that you are carrying RDBMS baggage into the graphical world. You may find that traditional DBAs have a hard time adopting the solution since it is very different from what they are accustomed to.

A lot of our data requirements are based upon graphical relationships and they need to be traversed in a reasonable amount of time. Arithmetically there are some other databases that have better performance, but not all of them are as well supported or offer the tool chain that Orient provides.

Best thing about OrientDB that I liked that it is a multipurpose NoSQL database. Second thing that I liked is that it is made in Java programming language. Being a pro fan of Java I find it exciting to use OrientDB.

There are few drawbacks in OrientDB. First one that I shoud mention is the performance as compared to other rival NoSQL database solutions. I think guys at OrientDB is constantly working on that. Second thing is the community. Size of the OrientDB community is small and I find it hard to find some solutions online.

1 : NoSQL database requirements.

The SQL Queries

The Both OOD and graph in single DB

There is an bit of slow processing while using huge data .. and getting the graphical tree.

Giving an ability to teh customer to get the insight of what is happening in .

1. Easy to use

2. Read performance is good

1. Stability of the product after a GA release

2. More concurrency needed in writing

3. Consistency in Read performance timings preferred

It is a event driven network management application in which lot of read transactions are happening per minute. Also, one transaction will read hundreds of rows from multiple tables.

Its versitility, the 'it fits whatever data you have' attitude.

I came to OrientDB to try to do something that Neo4J could not do. Grantedm I was trying something most in this community might find really stupid, trying to connect edges to edges, but it fitted my use case.

Sadly I also couldn't get OrientDB to do it, it took me a lot of experimenting though to find out since the Docs are barebones, hard to navigate and hard to understand and the error reporting is also not that clear, if there even are error messages.

None

It was my first contact with a database that implements a graph model

The documentation at that time was not quite sufficient, I needed to dig into code to find sometimes / clear things up.

I was conducting research on databases used for big data analysis. The benefits in this database mainly comes from it's graph model.

I liked the in memory feature which i waslooking for. Other than that i was happy with the way i could easily save persist the data into disk.

What i did not like was it had heavy load on memory. For that i needed to split files and open db file by closing currently opened.

I am using this for high availability problem. I am working on a log management tool. To solve the problem of high availability, i am using this db.

The SQL like queries to interact with Graphs.

The dashboard could use some work. There felt like there were some bugs in the dashboard javascript. Id much prefer an installable application such as SSMS then rely on the web browser dashboard.

We evaluated orientdb to solve a shortest path problem between two nodes.

Having a graph db with ability to use SQL. The db has some good features, can improve even more with time.

Some bugs, but they are getting fixed constantly

I use Orient for personal testing purpose

well, the coloured balls are very pretty, but I think that the enterprise support is even better

they have a pretty bad official documentation

we use orient for our web based application.