Graphs in RavenDBGraph modeling vs. document modeling

time to read 3 min | 445 words

One of the most important design decisions we made with RavenDB is not forcing users to explicitly create edges between documents. Instead, the edges are actually just normal properties on the documents and can be used as-is. This means that pretty much any existing RavenDB database can immediately start using graph operations, you don’t need to do anything.

The image below shows an order, using the RavenDB’s sample Northwind dataset. The highlighted portions mark the edges from this document. You can use these to traverse the graph by hopping from document to document.


For example, using:


This is easy to do, migrates well (zero cost to do so, yeah!) and usually matches nicely with what you already have. It does lead to an interesting observation. Typically, in a graph DB, you’ll model everything as a graph. But with RavenDB, you don’t need to do that.

In particular, let’s take a look at the Neo4J’s rendition of Northwind:


As you can see, everything is modeled as a node / edge. This is the only thing you could model it as. With RavenDB, you would typically use a domain driven model. In this case, it means that a value object, like an OrderLIne, will not have its own concrete existence. Either as a node or an edge. Instead, it will be embedded inside its root aggregate (the order).

Note that this is actually quite interesting, because it means that we need to be able to provide the ability to query on complex edges, such as the order lines. Here is how works:


This will give us all the discount products sold in London as well as their discount rate.

Note that in here, unlike previous queries, we use an named alias for the edge. In this case, it gives us the ability to access it properties and project the line’s Discount property to the user. This means that you can have a domain model with strong cohesion and locality, following the domain driven design principles while still being able to run arbitrary graph queries on it.  Combining this with the ability to pull data from indexes (including map/reduce) ones, you have a lot of things that you can do that used to be very hard but now are easy.

More posts in "Graphs in RavenDB" series:

  1. (08 Nov 2018) Real world use cases
  2. (01 Nov 2018) Recursive queries
  3. (31 Oct 2018) Inconsistency abhorrence
  4. (29 Oct 2018) Selecting the syntax
  5. (26 Oct 2018) What’s the role of the middle man?
  6. (25 Oct 2018) I didn’t mean to build this feature!
  7. (22 Oct 2018) Query results
  8. (21 Sep 2018) Graph modeling vs. document modeling
  9. (20 Sep 2018) Pre-processing the queries
  10. (19 Sep 2018) The query language
  11. (18 Sep 2018) The overall design