Hacker News Reader

Comment by maayank | Hacker News Reader

Do they though? Haven’t seen many companies with graph problems at such scale that require a new solution integrated, leaving aside the social network trope

View on HN

You don't need scale to make graph databases useful. As soon as relationships between items are more important than the data within a table, graph databases make your data easier to navigate than joins upon joins.

I feel like I’m taking imagination-b-gone pills. The only potential uses off the top of my head that I’ve witnessed are credentials management and financial instruments arbitrage, and in both cases it was solved well by other measures.

I’m sure there are projects where it’s useful, but not “every company” useful like SQL or even a server supervisor framework. I would be happy to be proven wrong.

I've got a friend who claims that nearly everything you can do with SQL, you can do easier with a graph database. I'm not sure that's true; as long as you need only one or two tables at a time, and/or automatic validation against the database schema is vitally important for you (that's probably the big one), then SQL databases are probably still better. But as soon as relations start to matter, and the number of joins in your queries starts to grow, a graph database becomes much nicer to use.

Is it so substantially easier to justify keeping (and maintaining) another copy of your data in the second database? Or, alternatively, to keep your data split between several different databases and invest all the required effort to keep them consistent?

Sometimes it is, of course. But not often.

Any concrete examples of these kinds of data management problems where graph databases are a good fit?

Reply on news.ycombinator.com