Ask HN: Which graph database would you advice?

In terms of scalability, reliability and performance? And what are your thoughts about implementing a graph inside e.g. PostgreSQL or Cassandra?

The graph will contain roughly about 150.000 vertexes, around 50.000 of those are highly connect between the other 100.000, expecting around 2.500.000 edges in between. The 100.000 vertex will almost all be updated daily. The graph will be used for OLTP workloads, expecting around 10 q/s. Queries will resolve the similarity (one-to-many).

If I were doing a lot of graph specific stuff, where it was crucial to store the graph itself, I'd definitely go with a pure graphdb over trying to shoe-horn it into a relational db, or even Cassandra. It's hard to give a real precise answer without more info, but Neo4J is probably a good starting point unless your requirements are real specific in some way that isn't compatible with Neo4J.

You should probably also ask if you really need a graph database or if you just need to use a graph processing engine (like Giraph) to perform graph operations on data that can be extracted from elsewhere.

Yes you are right, please have look. I have updated the question text.

The main concern I would have is over the OLTP requirement.

A well-built analytics system should be able to start from the raw data and rebuild if you trash it, thus would not be so concerned about transactions, consistency, etc.

For online transactions at the volume you are describing, however, you don't want a glitch to break the app, so the first question in my mind is what the story is for concurrent access and updates to the DB.

I build systems big enough to break Neo4J but as others mention, it works just fine for graphs your size.

OrientDB