Who's using OrientDb in production?

[StarpTech]

Hello
im very interesting in who's using OrientDb in production and what is your use case.
Do you have any problems with orientdb? What is you experience? It would be nice if you follow this template.

Your opinion
Version: ?
Years of experience: ?
Goods: ?
Bads: ?
Problems: ?

Your configuration
Driver: nodejs, php, c#.. ?
Protocol: binary, REST ?
Distribution enabled : ?

Key message: ?

Thank you very much!

[PhantomYdn]

We are using OrientDb in a stack: OrientDB + Orienteer (our datawarehouse system) + proprietary extensions for different domain (CRM, ERP, PRM, accounting and etc). So:

Your opinion
Version: 2.1
Years of experience: 1 year
Goods: Very good support, easy extensible
Bads: Quite slow releasing...
Problems: Commonly can be quickly resolved through support right here on github

Your configuration
Driver: native java
Protocol: java api + REST api

[StarpTech]

@PhantomYdn thanks for your reply.

[seeden]

I am using it in production for one month

Version: 2.0.13 (2.1 has problem with metadata #4804)
Years of experience: half of the year
Goods: fetchPlan is great
Bads: I would like to see more examples in documentation and more tests for embedded list items
Problems: embedded list items (#3449) I need to fix each query by myself.

Your configuration
Driver: livia-orientdb (orientjs)
Distribution enabled : no

Communication with orientdb team is good.

[StarpTech]

@seeden thanks! How do you solve the problem if you want to change the projection of nested records in the fetchPlan? I have to filter all by myself.

[sumpton]

We are developing what we consider a large scale project with OrientDB as our primary store. We are working in Node.js so with Oriento, now OrientJS, which we consider poor and neglected. We are caching everything in Redis, similar to what several big and successful social sites have done, and use Elasticsearch, and Kafka to decouple. We laugh at ourselves when we say that OrientDB is likely the weakest point in our stack.

We bought the dream, and are banking on future releases, and some Javascript love. Refactoring is constantly in our minds :) We would have loved to use OrientDB for everything but went with the addition Redis, Elasticsearch, and a lot of consistency code to be comfortable we can scale. Our AngularJS does not read from OrientDB.

We are encouraged by how hard Luca and and other talents seem to be working. I know my reply is off topic, but we have invested a lot of time and money into OrientDB development and hope to put it live in a few months.

[seeden]

@StarpTech I am not sure if I understand your question. Can you explain it more?

[nooruls143]

We are using OrientDB as our main data store for our Mobile App backend. Currently we are in development phase, we plan to go on Enterprise version once we plan to go live

Your opinion
Version: 2.03 (Planning to migrate to 2.1)
Years of experience: 8 months
Goods: flexible, SQL support, transaction support, extremely fast, Schema-support, easy to install and maintain
Bads: Documentation not up to the mark, we need more examples/full-fledged sample applications for APIs, specially Javascript, Groovy, No support for scheduled jobs
Problems: Nothing major so far, lack of robust documentation and examples makes development task slow and needs a lot of guessing

Your configuration
Driver: nodejs, php, c#.. Native Java driver, used in Spring application
Protocol: binary
Distribution enabled : Not yet but will be done soon

Key message: Please add Scheduled Job support (like in Oracle) and create sample applications for all APIs

[smolinari]

Love this thread and am following it with interest.

I'd also like to say, we are looking at OrientDB coming from looking hard at MongoDB for our project. We decided however, that the relational needs we faced just needed a relational database and found OrientDB, because we also need flexible schema in a document store and our overarching goal is to have a serious graph between users at one point. We don't have enough experience to say good or bad on the technology itself, but I can say I like where ODB is heading and the flexibility it offers.

I can echo the concerns that others have said about the documentation. Orient might want to consider hiring someone who can do professional documentation for them. I am coming from MongoDB's docs and Orient's is a few notches behind in comparison.

What I also like is the team at Orient are approachable, and even Luca, the CEO is constantly in contact with the community. 👍 for that!

Our project will be PHP based and will be using the binary protocol.

Scott

[imeleshkov]

We tried OrientDB as a db storage for implementation of custom GEO-location service (0.5 million of vertexes + 2 millions of edges). Version 1.7.x. We spent about 8-10 man months before finally figured out that there are some cases where performance of OrientDB is not sufficient for us and support team couldn't help us to address them.
Problems: work in cluster, performance of particular queries, ordering by multiple columns, poor documentation. Do not hesitate to check source code by yourself in order to take an impression. Please feel free to contact me directly if you need more info.

[smolinari]

@imeleshkov - did you open issues in Github for the problems you were facing at the time?

Scott

[StarpTech]

At the end of this thread I hope @lvca will take part on it. The most issues here are well-known.

[StarpTech]

@imeleshkov did you try Orientdb 2.0.x or even 2.1RC for your test cases?

[StarpTech]

@seeden e.g if you want to fetch a plan you can configure your projection in the select statement but this configuration is only valid for the first layer all other nested records are unaffected.

[lvca]

Hi guys,
Glad to hear feedback from you guys, good and not-so-good. I created this project some years ago by myself in my spare time, but today OrientDB counts thousands of users with so different use cases, very often completely different by each others. This is the good of being Multi-Model: you can do so many different things with OrientDB we can't even imagine.

We know OrientDB project is not perfect, but everybody in Orient Technologies + external contributors are working very hard to make it rock-solid, well tested and well documented.

Unfortunately OrientDB is bigger than most of NoSQL products out there, so also providing good docs is much harder. By the way I think we improved docs since the last year, but we absolutely know that what users are asking is really missing: tons of examples. Unfortunately finding somebody good at it it's hard, because he should understand OrientDB very well first. If you know somebody good at it, please email me in private ;-)

We also decided to publish our code coverage, as signal of complete transparency from our side. How many NoSQL vendors did it? The OrientDB team is also working on writing tons of new test cases for some parts where test coverage was quite poor. You can see the code coverage trend is growing and it's getting every better every week.

I'm sure you all have seen our big improvements on stability in 2.1, where we closed hundreds of issues. If you worked with OrientDB in the past, I suggest you to get a recent version.

If your project is important and you have a little budget I suggest you to get the Developer Support or pick any certificated guy that helps you (certification is important because we saw big damages made by non-certified consultants hired by companies...). This is not just advertisement, but since users are thousands today, answering to everybody in the Community Group is really hard (Sometimes I read long emails there, with use cases that just to reproduce them you can spend an entire day).

That said, OrientDB is an Open Project (we receive many contributions every week - thanks to everybody contributed!). Any constructive critique is well accepted and it helps us to build a better product.

I already know we can't make everybody happy, and there can always be a use case where another product performs better, but with your feedback and contribution we can improve OrientDB all together.