The RavenDB caching solution

time to read 2 min | 265 words

One of the more interesting aspects of Raccoon Blog is that we have done absolutely no performance work on the blog at all. Nevertheless, one of the most common items of feedback was that it feels much faster.

There are actually two reasons for that. The first is that unlike relational databases, we model the data so loading each page is usually just a single query to the database. The second is that RavenDB has been designed to be very cache friendly.

Think about this, if you are using something like Entity Framework or Linq to Sql , you are basically out on your own with regards to a caching solution. With NHibernate, there is a builtin option, but that one is:

  • Disabled by default (rightfully so).
  • Easy to get wrong.
  • Usually takes me two hours to explain just this topic in my course.

In contrast to that, with RavenDB, caching is such an basic part of the system that we made it the default. Everything is cached by default (actually, we have multiple levels of caching, both on the client and on the server, but that is beside the point). The end result is that for the vast majority of cases, we only need to check if we are up to date, and all the data is already in the local cache.

I built this feature just for this scenario, but because it is on by default, I never actually thought about this, we just worked as we normally would, focusing on features, and RavenDB took care of the performance.