Using the same logic, a key/value database is also a graph database?
Isn’t the biggest benefit of graph databases the indexing and additional query constructs they support, like shortest path finding and whatnot?
Using the same logic, a key/value database is also a graph database?
Isn’t the biggest benefit of graph databases the indexing and additional query constructs they support, like shortest path finding and whatnot?
I think the confusion stems from the fact that we call a database what is really a database management system.
I'd just like to interject for a moment. What you're refering to as a database, is in fact a database management system, or as I've recently taken to calling it, database plus management system.
You confuse the raw fist with the master who calculates the shortest path to your destruction.
Yes, the author is likely unaware of this. They see markdown files with links, so a graph and the set of those files, so a "database".
https://neo4j.com/docs/graph-data-science/current/algorithms...
Neo4j looooooves the "if you think about it, everything is graphs!" marketing maneuver. They (their marketing department) were the very first thing I thought of when I read this headline.
"Everything is graphs, so let's use a graph DBMS for anything" is a classic blunder
I've seen it work to sell their product to managers who definitely should have gone with something else, so I get why they do it. It works.
His argument is that the LLM is the query engine. By that logic you can approximate anything since LLMs can.
Indeed, what is the point of links/edges when the llm can figure out the relations by itself?
>what is the point of links/edges when the llm can figure out the relations by itself
Making it work less, faster, and saving tokens. Duh!