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,026 | Comments: 44,842

filter by tags archive

RavenDBReplicating to a relational database

time to read 2 min | 369 words

I just finished implementing a very cool feature for RavenDB, the Index Replication bundle allows you to replicate an index to a relational database.

What does this mean? Well, consider the following document:

var q = new Question
     Title = "How to replicate to SQL Server?",
     Votes = new[]
         new Vote{ Up = true, Comment = "Good!"}, 
         new Vote{ Up = false, Comment = "Nah!"}, 
         new Vote{ Up = true, Comment = "Nice..."}, 

And this index:

from q in docs.Questions
select new 
         Title = q.Title, 
         VoteCount = q.Votes.Count

With the aid of the Index Replication bundle, that index will be replicated to a relational database, giving us:


You can find full documentation for this feature here and the bundle itself is part of RavenDB’s unstable as of build 159.

More posts in "RavenDB" series:

  1. (22 May 2015) Adding a new shard to an existing cluster, splitting the shard
  2. (21 May 2015) Adding a new shard to an existing cluster, the easy way
  3. (18 May 2015) Enabling shards for existing database



Very cool feature!

You have a type in the documentation:

"You can directly replicate between a document and a RDBMS table, because the format of a document simply cannot be made to work on a relational database."

Should probably be "You can't ..."

Jeff Handley

Nice! I'm getting closer and closer to wanting to use RavenDB. :-)

Khalida Abuhakmeh

When does the replication happen?

  • is it triggered with every new document that is added to that index ?

  • is it on demand (press this button here) ?

  • is it a timed job ?

When I first heard about this i thought "Why would I want my index definition stored in a database?" Now i understand you meant the index result set is replicated into the database.

This is a great bundle for teams who have members more comfortable doing reporting with SQL.



This is very very useful as it makes it very easy to do mixed data storage with sql server still in use. This will make migration a lot easier too. I think you should advertise this feature a bit to see if it might be a killer one.

You could also try to replicate json trees as xml for which sql server has great support.

Ayende Rahien

Configurator, thanks, I fixed that.

Ayende Rahien


Xml fields in SQL Server are... workable, but they don't really work nice with reporting tools.


Another idea would be to replicate from sql server to ravendb as a means of having stacked materialized views (which sql server does not support yet). You can implement this in a number of different (complex) ways: CDC, replication infrastructure, triggers, change notification/sqldependency class.

I was proposing xml fields as a means of making sql server behave more like a document storage. I am sure there are cases where the performance benefit justifies the complexity.

Ayende Rahien


I would be pretty trivial to do the reverse using triggers, but I am not sure what it would give you.

What do you mean, stacked materialized views?


Materialized views can only reference tables, not other materialized views. So you can only get one level deep. It could be very convenient to have nested materialized views to build up more complex structures. I have encountered the need multiple times (I wanted to do two level aggregation and the other time I wanted to express exists queries through joins and groupings over multiple levels).

nested materialized views = stacked materialized views.


Also I would have liked to pre-materialize a xml/json document that describes every piece of data needed for a particular url. This is not possible using sql server indexed views but would be quit a killer. Image you could stitch all information required for a whole forum thread (thread-info, posts, users, their reputation and badges, ...) up into one json document by creating a tree of raven indexes that ultimately result in a table with pk (threadid) and a json document containing all required data. this would allow you to write normalized data in sql server (convenient and immune to data anomalies) and read in a document-oriented way from raven (also convenient and very fast). not sure if this is possible today as I believe raven indexes cannot join or build tree structures but I hope you see the use case. Low dev costs and blinding performance. certainly a complex feature set to implement.

Ayende Rahien


You can certainly do it today using Raven.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats