What is behind the thought that graph databases are going to grow so much in the next few years? To me they've always had a niche use... Are they really going to be ubiquitous (like this funding seems to assume?)
What is behind the thought that graph databases are going to grow so much in the next few years? To me they've always had a niche use... Are they really going to be ubiquitous (like this funding seems to assume?)
Overall, graph databases are so general as a model that writing slow queries will always be a possibility, so one should be mindful of these concerns. But that's just as true in NoSQL graph db's.
To summarize this post[0] by someone involved with the standards:
- GQL (ISO/IEC 39075) is a full database language to create and manage property graphs and create, read, update, and delete nodes and edges (or vertices and relationships)
- SQL/PGQ (ISO/IEC 9075-16) is a new add-on part of the SQL standards which introduces the capabilities to create property graph views on top of existing tables in an SQL database, as well as the ability to query property graphs using a GRAPH_TABLE function in an SQL FROM clause
- The input to the SQL/PGQ GRAPH_TABLE function is a property graph query, sometimes referred to as Graph Pattern Matching or GPM. Graph Pattern Matching is common between SQL/PGQ and GQL. That is, the syntax accepted in a GRAPH_TABLE function in an SQL FROM clause is identical to the syntax in a GQL graph query. Because GPM is the same in both draft standards, changes to GPM for SQL/PGQ also apply to the GPM portions of the GQL specification.
---
I also just came across the Apache AGE project[1] which basically allows you right now to extend PostgreSQL DBs with property graph capabilities and enables full(?) use of Cypher/GQL.
[0] http://www.jcc.com/resources/jcc-blogs-menu/blog-database-dr...
GraphDBs make more sense when there is strong evidence that either the natural description of the program is a graph or that the underlying storage engine can efficiently model the graph.
So far no GraphDB has demonstrated either statements as true for the majority of problems.
As for those specific figures, I'm guessing there's enough wiggle room in "data and analytics innovations" (emphasis mine) to find or project almost any trend one wishes. What are data analytics innovations? Why, it's the set of things that will see 80% use of graph technologies! "Graph technologies" is also so potentially-vague that it could plausibly be 100% of almost anything related to software.
Relational data may be a hassle but its a hassle you end up having to deal with anyway at some point.
I can see a graph database as being a useful place to stash a ton of shitty data as an initial place to start an ETL but I can't imagine using it as a system of record except in very limited situations.