This is an old post, but always actual. We've published a page with a 
comparison between two products by also collecting the feedback of users 
that worked with both:

http://www.orientechnologies.com/orientdb-vs-neo4j/

Lvc@


On Wednesday, 11 January 2012 18:51:09 UTC+1, bayoda wrote:
>
>
> *absolute pro: *
>
>
> Licence: Apache 2.0 
> Some Marketing from Luca :-) 
> Speedy problem solution 
> Speedy BugFixes (that's a must!)
> scaleable (as we found out) 
> speed (raw write speed on Key Value like storage with blobs - nearly 100mb 
> on SAS2 Discs) 
> index speed 
>
> *cons actually: *
> multithread capabilities - hmmmm - a little bit problematic - but seems to 
> be in reworking 
> good feature set - but luca is sometimes alone with testing (and real life 
> is not all-times a junit test)
> so testruns about several  100 GBs of Data sometimes show bottle necks - 
> index / memory pressure and co - but luca tries to fix fast! 
>
> some pure java functionality (no external libraries) makes more problems - 
> than external libraries would do
> Linked Hash Map - Problems with Memory for example) and luca doesn't like 
> to embedd external things ;-) 
>
>
> but just give it a try - i think orient is getting more mature ... we work 
> with it since 14 months now .... 
>
> michael
>
>
> 2012/1/11 TheSweetlink <[email protected]>
>
>> I looked at Neo4J and liked the product very much.  It has a lot of
>> good momentum.
>>
>> Then I came across OrientDB when researching which graphdb I wanted to
>> use.
>>
>> I ultimately chose OrientDB because of:
>>
>> 1) Licensing.  Neo4J clustered setups require a costly license and
>> OrientDB's Apache 2.0 license is extremely liberal.  Free for any
>> use.  I intend to run multi-master OrientDB with no upfront software
>> cost.
>>
>> 2) SQL syntax + gremlin graph traversal language = VERY powerful ways
>> to explore/grow/analyze your graph.
>>
>> 3) Mixing schema-full/-mixed-/less allows you to arbitrarily add/
>> remove criteria from your schema.  Also a very easy transition for
>> anyone working with SQL-based RDBMS.
>>
>> 4) Luca and OrientDB community respond with lightning speed.
>>
>> Both are good products that have slight nuances between the two.
>>
>> Ex. Neo4J has lots of different algos for analyzing your graph depth
>> or breadth first and much more but OrientDB has SQL syntax + gremlin,
>> also a very powerful way to traverse your graph which can accomplish
>> similar results.
>>
>> If you're in python you might choose the Bulbflow project and abstract
>> yourself from both OrientDB and Neo4J, however this would not allow
>> you to take advantage of many useful Orient
>>
>> Best performance has seemed to go back and forth between the two and
>> it's hard to tell because benchmarks are good but != real life.
>>
>> Switching to OrientDB from a traditional RDBMS made a very noticable
>> difference in performance.
>>
>> Queries with heavy joining took on average 90-100ms. and refactoring
>> my code to use OrientDB dropped those times to < 1-10ms.
>>
>> Not everyone will experience a 10 fold performance increase, sometimes
>> less, perhaps many times more depending on your setup.
>>
>> I encourage you to explore both products more and hopefully you'll
>> wind up here if it suits your project best.  :)
>>
>> -David
>>
>>
>> On Jan 9, 4:59 am, Stuart Roebuck <[email protected]> wrote:
>> > Personally, I didn't view my need to be for a graph database.  I was
>> > looking for something light, embeddable, simple and key value based. 
>>  When
>> > I reviewed the options Neo4J appeared to be quite different from the 
>> rest
>> > in it's graph focus and I made the assumption - rightly or wrongly that 
>> the
>> > graph handling capabilities might come at a performance cost for those 
>> not
>> > particularly requiring that functionality.
>> >
>> > On reflection I think OrientDB is currently quite early in its lifecycle
>> > and Neo4J looks like it may have more mature multi-threaded access.
>>
>
>
>
> -- 
> bayoda.com - Professional Online Backup Solutions for Small and Medium 
> Sized Companies 
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to