Do graph databases deprecate relational databases?

Question

I'm new to DBs of any kind. It seems you can represent any relational database in graph form (although it might be a very flat graph), and any graph database in a relational database (with enough tables).

A graph can avoid a lot of lookups in other tables by having a hard link from one entry to another, so in many/most cases I can see the speed advantage of a graph. If your data is naturally hierarchical, and especially if it forms a tree, I see the logical/reasoning benefit to a graph over relational. I imagine a node of a graph which links to other nodes probably contains multiple maps or lists... which is effectively containing a relational DB within nodes of a graph.

Are there any disadvantages to a graph db vs a relational db? (Note: I'm not looking to things like missing features in implementations, but instead the theoretical pros/cons)

When should I still use a relational database? Even if I logically have a single mapping of an int to int I could do it in a graph.

Ybarra

With Amazon, Microsoft, and others beginning to offer products based on native graph databases, it's probably time for some new answers to this old question! – Balthazar

Answer 1

Graph databases were deprecated by relational-ish technology some 20 to 30 years ago.

The major theoretical disadvantage is that graph databases use TWO basic concepts to represent information (nodes and edges), whereas a relational database uses only one (the relation). This bleeds over into the language for data manipulation, in that a graph-based language must provide two distinct sets of operators : one for operating on nodes, and one for operating on edges. The relational model can suffice with only one.

More operators means more operators to implement for the DBMS builder, more opportunity for bugs, and for the user it means more distinct language constructs to learn. For example, adding information to a database is just INSERT in relational, in graph-based it can be either STORE (nodes) or CONNECT (edges). Removing information is just DELETE (relational), as opposed to either ERASE (nodes) or DISCONNECT (edges).

Taxi

Hmm, but it seems that there are a number of new graph DBs and other non relational DBs in what appears, to someone just looking at it for the first time, to be the hottest latest innovation... The whole noSQL thing... How does that mesh with this answer? – Ybarra

@dave, The IT industry is driven by fads. NOSQL products address certain deficiencies of the SQL software stacks that happen to dominate the marketplace today. Those deficiencies have nothing to do with the relational model as such but the NOSQL market is immature and has its roots largely in market-disrtuptive companies, open source and young startups. It's likely that the R&D cost and time-to-market for these graph/doc/other products is less than it would be for similar relational ones. SQL is a MS/Oracle/IBM hegemony and it's easier to break that mould by offering something "different". – Marhtamari

I've once taken a look at the command language/syntax for Neo4J, one of those "popular modern graph DBMS's". Imagine my surprise when I discovered that the "novelty" introduced language keywords that were for the most part literally the same as those that I was using in the early 80's, when writing COBOL programs against an IDMS database. – Taxi

(There's a proverb that's rather popular in RelationLand, and which goes like this : "those who don't know history, are doomed to repeat it") – Taxi

Answer 2

Building on Erwin Smout's fine answer, an important reason why the relational model supplanted the graph one is that a graph has a greater degree of "bias" baked into its structure than relations do. The edges of a graph are navigational links which user queries are expected to traverse in a particular way. A relational model of the same data assumes much less about how the data will be used. Users are free to join and manipulate relational data in ways that the database designer might not have foreseen. The disruptive costs of re-engineering graph database structures to support new requirements were a factor which drove the adoption of the relational model and its SQL-based offshoots in the 1980s.

Marhtamari

Answer 3

Relational databases were designed to aggregate data, graph to find relations. If You have for example a financial domain, all connections are known, You only aggregate data by other data to find sums and so on.

Graph databases are better in more chaotic domain where to connections are more important, and not all connections are apparent, for example:

• networks of people, with different relations with one and other
• films and people creating them. Not just actors but the whole crew.
• natural language processing and finding connections between recognized words

Luminous

Answer 4

Data model is important, but what matters more is how you access your data. Notice, there are very few (none, actually) sharded or otherwise distributed graph databases out there. If you compare insertion speed into a typical relational database and a graph database, your relational database will most likely win.

Yes, graph model is more versatile than relational model, but it doesn't make it universal - in some cases, this versatility is a roadblock for optimizations.

In fact, modern graph databases are a niche solutions for a narrow set of tasks - finding a route from A to B, working with friends in a social network, information technology in medicine.

For most business applications relational databases continue to prevail.

Invocate

The graph model is "more versatile"? – Marhtamari

It lets you model some structures in a more natural way - graphs, to begin with, but also associations, friendships, molecules, drug formulae and so on – Invocate

Answer 5

I'm missing the performance aspect in the answers above. Performance of graph based data bases is inherently worse for scalar and maybe even tree based models. Only if you have a real graph, they may exhibit better performance.

Also most graph DBs do not feature ACID support such as almost any RDBMS.

From my real life experience I can tell almost any evolving data model will sooner or later become a graph and that's why graph DBs are superior in terms of flexibility and agility (they keep pace with the evolution of your data model).

That's why I don't think that RDBs will prevail for "For most business applications" as @Kostja says. I think they will prevail where ACID capability is essential.

Algeciras

ACID is a property of transactional systems and transactional systems are not the exclusive territory of relational and/or SQL systems. To prove : both IDMS (graph-based) and IMS (hierarchical) existed way before SQL systems got to dominate the market, and they offered full ACID transactional capability. – Taxi

neo4j is fully ACID compliant. – African