RavenDB Vs SQL - A follow up

The fight they were all waiting for

This is a following on post from RavenDB is it all it’s cracked up to be. A few have commented that to provide any meaningful interpretation of the load test they needed to know more about the SQL implementation which is fair enough. So, here we go.

Is RavenDB all it's cracked up to be?

It all started with a Vampire Launch.

As a seasoned technologist I’m always happy to bare old battle scars and discuss them candidly with my peers and starry eyed groupies* over a few pints down the local. Technology, after all, always has problems and we have taken it upon ourselves to carry that giant boulder up the hill and start afresh when it rolls back down again.

Take, for example, a recent run in with a search implementation on a property website. We selected a search technology built on Lucene.Net - a high performance, enterprise search platform that is fast becoming an industry standard.  Choosing a Lucene based search provider for a web site heavily reliant on search functionality seemed like a great idea at the time. Fast forward to go live and we soon discovered that the search didn’t hold up very well under significant load. This is what I call a “Vampire Launch” i.e. a web site having a brief moment in the sun but then suddenly erupting into flames. One stressful week later and the search was back online and taking the strain of public exposure. This time however, it was now driven by trusty Microsoft SQL.

Before I cover up this grizzled scar (until the next showing that is), it's worth highlighting three important lessons harvested along the way.

Lesson 1: If you are trying out a new technology make sure your POC includes load testing.

Lesson 2: If you are using a new technology make sure the providers of the technology are able to support it.

Lesson 3:  Make sure you build using interfaces and abstraction in case you ever need to swap out a nasty search implementation.

So how does this all relate to RavenDB?