Hacker News Reader

Comment by voodooEntity | Hacker News Reader

Im a big fan of GraphDatabase's since about 10 years. I even wrote my own "in memory graph storage" in golang for a specific use case that none of the big GraphDatabase's could cover at the time.

That said - i WISH people would embrase the existing GraphDatabases more and make the hosters support them as standard, rather than abusing existing relational databases for graph purposes.

And to make it clear,i'm not talking about my own experimental one, i mean stuff like Neo4j, OrientDB etc.

View on HN

> rather than abusing existing relational databases for graph purposes.

In my experience, the vast majority of graphs can be embedded in relational databases just fine and most people don't want general graph querying. People just don't like optimizing queries (or equivalently the schema to enable such queries).

I personally have never seen a pitch for graph databases that makes them seem attractive for more than data exploration on your local machine.

Well im working since multiple years on a private lets call it "research" project which deeply relies on growing/deep structured graphs.

I don't think that GraphDBs should a default choice, but there are cases in which they just perform better.

Could i write my research project with a relational DB? Yes - i tried - and it sucked xD

Yep, something like adjacency lists have solved a lot of dumb recursive queries/"graph queries" for me, usually because the graph doesn't change much and is just a few nodes deep.

When you look at AWS Neptune database implementation details, it looks realy close to the Aurora backend... :-)

https://docs.aws.amazon.com/neptune/latest/userguide/migrati...

Hrhr very true.

Also, the last time i checked neptune, it could only be run in AWS but there was no public application image for local tinkering/dev. But its some years ago to be fair - maybe have changed.

My personal opinion is that nobody should touch OrientDB with a 10 ft pole.

I started with orientdb than switched to Neo4j. Orientdb was good for starting tbf, but we talking about 10+ years back. Now i would definately default to Neo4j

Why?

The only problem with representing graphs on an RDBMS is the queries. So whats the big issue if queries are added which can handle the graph cases?

Thats like saying why do we need json we can represent it also in a textfile but accessing values can be more tricky.

Sure you can represent a GraphDB in a RDBMS - but graphdbs are optimized for their specific use case. Therefor for example locking of resources is optimized for said purpose. When going a "Edge" and "Node" table approach, locking is by default rather unoptimized in many RDBMS. Just one simple example.

> Thats like saying why do we need json we can represent it also in a textfile but accessing values can be more tricky.

If your text processing stack works good enough, and JSON only solves edge cases, then I think its a legit argument against adding another tech to the stack.

Its not like everyone immediately switched over to JSON even if they could have.

And the analogy may not be the best - in the case of graph databases, they don't do what RDBMS can do, at least not as efficiently.

So if we need some graph functionality in our RDBMS, do we split the database and use a "real" graph database or just incorporate the graph functionality into the existing DB? The choice seems quite easy for me, because there are whole host of issues in splitting DBs (duplication of information, inconsistency, etc.)

Well i took the best example that came to my mind at that moment. may not be the best analogy but well its what it is.

My point was not about people enrichhing an existing RDMBS concept with Graph, it was about using RDBMS as Graph (as only purpose). So maybe i wasn't exact enaugh in my definition. Therefor:

"If your purpose is to use the benefits of Graph and you want to use it for this purpose only, use a GraphDB and dont use a RDBMS and make it a GraphDB."

I hope thats better now.

Reply on news.ycombinator.com