“Titan Is Staying”
groups.google.com
groups.google.com
Titan was (design-wise) by far the most promising FLOSS graph database around, it's really sad to see it going away.
But, there are other very good graph DBs out there too, like OrientDB.
What is important in my opinion, is for all of these graph DBs to embrace the Tinkerpop Blueprints graph API (which Titan and OrientDB do). https://github.com/tinkerpop/blueprints/wiki
I didn't have any performance issues with OrientDB, but it's worth noting that I worked with relatively small datasets (e.g. graphs with ~1000 edges).
Titan, given that it runs on HBase or Cassandra, is on a whole different level compared to these two graph DBs. If you're working on a small app which needs an ebedded graph DB, you'll definitely not use Titan.
http://thinkaurelius.com/2013/11/24/boutique-graph-data-with... (good in-memory performance -- like Neo4j)
http://thinkaurelius.com/2013/03/30/titan-server-from-a-sing... (if you do grow, its easy to add more machine)
Fortunately we've been using the Tinkerpop API so it should be fairly inter-changable on the back end, we're definitely going to have to look into other options now that Aurelius has been acquired.
That ~5B edges is roughly where we're currently at, however that is growing and the limit of 34B is under 10x of where we're currently at.
http://thinkaurelius.github.io/titan/
which was recently acquired
http://venturebeat.com/2015/02/03/datastax-acquires-aurelius...
I can't understand people that appreciate Titan: it's just a library on top of a DBMS that is not even Graph. It's definitely not a Graph Database. People love buzzwords, but who is using it in production? I mean, real production? If you wanna do just Graph Processing you have plenty of choices like Spark+GraphX, Giraph, etc.
If it's built on top of something you're already maintaining why not. It make sense.
GraphX last I check was in beta, at least last databrick meetup stated so.
GraphX would make sense if you're stack is cassandra + spark.
For me personally, I have time to wait to see if Flink will mature and interop with Cassandra before I invest my time in Spark or Flink (or both if I have the luxury).