7 ms·

Spicy take: graph databases are the blockchain of the database world. Sounds sexy, scales badly, has very few if any use cases that traditional databases can't

Spicy take: graph databases are the blockchain of the database world. Sounds sexy, scales badly, has very few if any use cases that traditional databases can't handle better.

chillfox 4y ago
I have only encountered one problem that was best solved with a graph style query and I did that in sqlite. So what would likely be nice is a better query language that can compile to sql.
- styluss 4y ago
  What was the use case? I agree, a lot of stuff that is supposedly magic in graph dbs aren't that hard to do in SQL.
  - chillfox 4y ago
    Nodes with specific properties within a certain number of connections from a specific node, only going through nodes with specific other properties, ordered in fewest connections to most. I was looking for profitable trade routes in EVE Online.
  - lolive 4y ago
    Such as multiple inheritance?
mrweasel 4y ago
It doesn't seem that spicy. Graph databases are a niche thing. While I can't think of a problem I've had to deal with that would require one, I'm sure there are some problems where they make sense. In those cases you could just charge people whatever you feel like. That does come with expectations, and from the comments it seems like Neo4J haven't been able to deliver. Anyway, pricing, for niche product, you don't have a $64.80/month offering, bump that to a $1000 for a developer version and just stick the "Contact Sales" on everything else. If you need a graph database (or any specialized database) then pricing is almost irrelevant.
zozbot234 4y ago
SQL is getting standard syntax extensions to make graph-like queries a bit more intuitive (Property Graph Query). But you're absolutely correct, Postgres with the right schema is a very serviceable graph database already.
- sofixa 4y ago
  But Postgres also scales (out) badly. You need external tools (and it's non obvious to choose which one of the external tools) to achieve even a basic active/passive setup, let alone a more complicated one with read replicas.
  - zozbot234 4y ago
    The Postgres docs describe how to set up read replicas and HA. They're admirably clear and high quality, more so than many FLOSS projects. You can also set up sharding to scale out further.
_8j50 4y ago
In infosec stuff it is useful for stuff like bloodhound for example.
phkx 4y ago
I imagine that you have to implement the logic about relationships and queries yourself and spread the I formation across at least two relational tables. I’d hope for graph databases to do that for you. Is that not the case?
inkyoto 4y ago
I don't understand where this comes from. If the problem warrants the use of a graph data model, property graph databases provide an efficient solution for that. Graph databases also excel at discovering distant relationships between loosely coupled data entities and deriving previously unknown facts about the data that would be otherwise too cumbersome to unravel using document or relational database queries. The graph databases also easily allow one who knows the answer to a question to arrive at a set of of one or multiple original questions that have yielded the single answer; it is somewhat niche although is incredibly useful in knowledge graph scenarios. Just like a document database is not a good fit for a data model with inherent relations between data entities (simple or complex; the reverse is also true), a graph database is not a butt plug for every butt. Every problem requires an appropriately fitting solution for it.
- Delemono 4y ago
  It adds complexity to a narrow use case. If it wouldn't be narrow neo4j wouldn't need to lay off stuff. Your examples do not refute this
  - inkyoto 4y ago
    > It adds complexity to a narrow use case. It also simplifies the unnecessary complexity in many cases, and I have witnessed both. Just like one should not use an expensive Zeiss microscope to hammer nails into a concrete wall as a hammer substitute, one perhaps ought not to stick a graph database everywhere where it does not belong. Engineering (including software) is about selecting the appropriate tooling for each job. > If it wouldn't be narrow neo4j wouldn't need to lay off stuff. I fail to see how the two are related. If a company struggles with the execution of their incumbent business model, perhaps it is not necessarily related to the product (may or may not be though)?
- rippercushions 4y ago
  > If the problem warrants the use of a graph data model I think this is the crux of the problem. I once worked on MegaBank's peer to peer payment app, where somebody had figured that the people sending money to each other was a directed graph, so they should use a graph DB to store it. And when Azure's sales team convinced them that CosmosDB could handle relational data and graphs and documents, they bought it hook, line and sinker. Needless to say, this was a terrible idea: an RDBMS could have handled it just fine, and because everything else was stored in an RDBMS (which despite the marketing fluff is quite different internally in CosmosDB), now doing any kind of join was a huge pain in the ass. As a cherry on top, they were now locked into CosmosDB, which has completely incomprehensible ("request units per second") but very, very high pricing particularly for graphs. Whee!

Spicy take: graph databases are the blockchain of the database world. Sounds sexy, scales badly, has very few if any use cases that traditional databases can't handle better.

chillfox 4y ago

I have only encountered one problem that was best solved with a graph style query and I did that in sqlite. So what would likely be nice is a better query language that can compile to sql.

styluss 4y ago
What was the use case? I agree, a lot of stuff that is supposedly magic in graph dbs aren't that hard to do in SQL.
- chillfox 4y ago
  Nodes with specific properties within a certain number of connections from a specific node, only going through nodes with specific other properties, ordered in fewest connections to most. I was looking for profitable trade routes in EVE Online.
- lolive 4y ago
  Such as multiple inheritance?

mrweasel 4y ago

It doesn't seem that spicy. Graph databases are a niche thing. While I can't think of a problem I've had to deal with that would require one, I'm sure there are some problems where they make sense. In those cases you could just charge people whatever you feel like. That does come with expectations, and from the comments it seems like Neo4J haven't been able to deliver. Anyway, pricing, for niche product, you don't have a $64.80/month offering, bump that to a $1000 for a developer version and just stick the "Contact Sales" on everything else. If you need a graph database (or any specialized database) then pricing is almost irrelevant.

zozbot234 4y ago

SQL is getting standard syntax extensions to make graph-like queries a bit more intuitive (Property Graph Query). But you're absolutely correct, Postgres with the right schema is a very serviceable graph database already.

sofixa 4y ago
But Postgres also scales (out) badly. You need external tools (and it's non obvious to choose which one of the external tools) to achieve even a basic active/passive setup, let alone a more complicated one with read replicas.
- zozbot234 4y ago
  The Postgres docs describe how to set up read replicas and HA. They're admirably clear and high quality, more so than many FLOSS projects. You can also set up sharding to scale out further.

_8j50 4y ago

In infosec stuff it is useful for stuff like bloodhound for example.

phkx 4y ago

I imagine that you have to implement the logic about relationships and queries yourself and spread the I formation across at least two relational tables. I’d hope for graph databases to do that for you. Is that not the case?

inkyoto 4y ago

I don't understand where this comes from. If the problem warrants the use of a graph data model, property graph databases provide an efficient solution for that. Graph databases also excel at discovering distant relationships between loosely coupled data entities and deriving previously unknown facts about the data that would be otherwise too cumbersome to unravel using document or relational database queries. The graph databases also easily allow one who knows the answer to a question to arrive at a set of of one or multiple original questions that have yielded the single answer; it is somewhat niche although is incredibly useful in knowledge graph scenarios. Just like a document database is not a good fit for a data model with inherent relations between data entities (simple or complex; the reverse is also true), a graph database is not a butt plug for every butt. Every problem requires an appropriately fitting solution for it.

Delemono 4y ago
It adds complexity to a narrow use case. If it wouldn't be narrow neo4j wouldn't need to lay off stuff. Your examples do not refute this
- inkyoto 4y ago
  > It adds complexity to a narrow use case. It also simplifies the unnecessary complexity in many cases, and I have witnessed both. Just like one should not use an expensive Zeiss microscope to hammer nails into a concrete wall as a hammer substitute, one perhaps ought not to stick a graph database everywhere where it does not belong. Engineering (including software) is about selecting the appropriate tooling for each job. > If it wouldn't be narrow neo4j wouldn't need to lay off stuff. I fail to see how the two are related. If a company struggles with the execution of their incumbent business model, perhaps it is not necessarily related to the product (may or may not be though)?
rippercushions 4y ago
> If the problem warrants the use of a graph data model I think this is the crux of the problem. I once worked on MegaBank's peer to peer payment app, where somebody had figured that the people sending money to each other was a directed graph, so they should use a graph DB to store it. And when Azure's sales team convinced them that CosmosDB could handle relational data and graphs and documents, they bought it hook, line and sinker. Needless to say, this was a terrible idea: an RDBMS could have handled it just fine, and because everything else was stored in an RDBMS (which despite the marketing fluff is quite different internally in CosmosDB), now doing any kind of join was a huge pain in the ass. As a cherry on top, they were now locked into CosmosDB, which has completely incomprehensible ("request units per second") but very, very high pricing particularly for graphs. Whee!