2.2. Comparing Database Models

A graph database stores data structured in the nodes and relationships of a graph. How does this compare to other persistence models? Because a graph is a generic structure, let’s compare how a few models would look in a graph.

A Graph Database transforms a RDBMS

Topple the stacks of records in a relational database while keeping all the relationships, and you’ll see a graph. Where an RDBMS is optimized for aggregated data, Neo4j is optimized for highly connected data.

Figure 2.1. RDBMS

Figure 2.2. Graph Database as RDBMS

A Graph Database elaborates a Key-Value Store

A Key-Value model is great for lookups of simple values or lists. When the values are themselves interconnected, you’ve got a graph. Neo4j lets you elaborate the simple data structures into more complex, interconnected data.

Figure 2.3. Key-Value Store

K* represents a key, V* a value. Note that some keys point to other keys as well as plain values.

Figure 2.4. Graph Database as Key-Value Store

A Graph Database relates Column-Family

Column Family (BigTable-style) databases are an evolution of key-value, using "families" to allow grouping of rows. Stored in a graph, the families could become hierarchical, and the relationships among data becomes explicit.

A Graph Database navigates a Document Store

The container hierarchy of a document database accommodates nice, schema-free data that can easily be represented as a tree. Which is of course a graph. Refer to other documents (or document elements) within that tree and you have a more expressive representation of the same data. When in Neo4j, those relationships are easily navigable.

Figure 2.5. Document Store

D=Document, S=Subdocument, V=Value, D2/S2 = reference to subdocument in (other) document.

Figure 2.6. Graph Database as Document Store