Hacker News new | past | comments | ask | show | jobs | submit login

> reminiscent of graph dbs

Why are you talking as if graph dbs are a thing of the past like the "object-oriented dbs"? I'm about to start a project for which a graph db seems the only sane option right now and I'm contemplating Neo4j vs Titan.

I see graph dbs as a the only sensible future because graph data is a very common type of data, and once your queries involve traversals, path findings with conditions and such, expressing them as joins becomes both a performance penalty and a need to basically implement a graph db atop a rdbms in a form of a monstrous graph-orm-thingy.

And once you use a graph db with acid and all the goodies, you'll probably ask yourself what's the point of having a two datastores system, so one will have to go away.




> expressing them as joins becomes both a performance penalty

Under the hood, graph databases are still effectively performing 'joins'. There'll likely be optimisations with respect to node lookups, but the fundamental issue of locality of access is still there: it's simply a hard problem in graph data storage. Depending on the flexibility/declaritiveness of the query language provided, there's still the issue of intermediate result set explosion that also plagues triple stores.

This isn't meant to say that graph databases aren't very useful: native graph stores will certainly offer some useful technical specialisations and ease of use benefits - it's more to say that there's not (afaik) anything wondrous under the hood that means that native graph databases fundamentally solve the performance challenges of graph-structures-on-relational-dbs.


I think you may have misinterpreted his use of "reminiscent"




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: