Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,550

filter by tags archive

The right storage model

time to read 2 min | 276 words

Originally posted at 12/15/2010

What are the advantages that you get when using RavenDB? The easy answers are:

  • Sparse data
  • Dynamic data
  • Better scaling across nodes

But there is another one that is even more important, in my eyes. It is the simple issue that with RavenDB, a document is a transactional boundary. That makes it very easy to model interactions on root aggregates that are much harder in relational database.

The most commonly used example is Order & OrderLines. In a relational database, those would be in two separate tables, and it is possible to modify order lines without touching the order. With RavenDB, on the other hand, the OrderLines are embedded in the Order document, so you literally cannot modify them without touching the order as well. This has a lot of implications. The most obvious one is that you just got rid of a big burden in terms of managing concurrency. You no longer have to be very careful about how you update parts of your model, as you have to be when using relational databases. You can just make any update you want, and if there are concurrent updates, it will completely, without you having to do anything at all.

Another benefit of this approach is that because a document is the transactional boundary, accessing all of it is a very cheap operation. Coming back again to the Order, it is a very cheap operation to access all of the Order details, which can be very costly in a relational database (having to access Orders, OrderLines, Addresses, etc… ).


James L

Hmm, hadn't thought about it that way. Interesting.


I can see how abstracting your transactional boundary around the design of your storage model would be a benefit but what about the exact opposite? If I don't want Orders to be locked when I am merely updating an order line(for performance etc) surely this does not mean that I have to separate my order lines from my order in terms of how it is represented in the document? For example, if you are only issuing a "known" partial update ... why lock something or make it part of the transaction if you aint gonna need it?

Ayende Rahien


You can do partial updates if you want to.

Demis Bellot

I don't know why this is so special? You can Blob the order details on the Order row to achieve the same result. It's kept normalized on purpose for other benefits.


Isn't it all about paradigm of document data bases, not specifically Raven?

Comment preview

Comments have been closed on this topic.


  1. The worker pattern - about one day from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats