We used RavenDb 3.0 as an experiment for an internal management system. Spoiler alert: We ended up switching to SQL.
For the upsides, RavenDB is by far the easiest DB I've ever written against. Getting up with CRUD operations is stupidly simple and just works. The in-memory instance you can create on-the-fly for unit testing is amazing.
However.. (please bear in mind, these are my opinions and largely from recollection, it was >1 year ago now)
LINQ for secondary indexes is awesome.. when it works. When it fails, you're left with useless stack traces and really, really bad error messages. Often this doesn't happen immediately. In one instance, someone had accidentally inserted some enum values using strings instead of integers (or vice-versa, whichever was the way we weren't using). The index operation would appear to work fine, then eventually get stuck on these incorrect records (after minutes or even hours), retry a bunch, then mark the index as failed and it would suddenly be useless. It took a long time to figure out the cause of this.
I also found the secondary indexes actually got quite difficult. It would either be really easy to get something working, or mindbogglingly confusing. Sometimes you have to project/cast results, other times you don't, and it would never be obvious (to me, though others on my team had the same complaint) -- you'd just have to see you're missing a bunch of fields, then realize "oh this one needs to be projected or needs a cast".
I found joins to be even worse. They either worked right away, or required an hour of messing around with to figure out what magic options needed to be passed. I'm sure this is lack of experience/knowledge on it, but we found the learning curve to be VERY high. This included stuff like when we changed a join from using one index to another (that included some other data) the join would have to be changed dramatically, and it never seemed obvious why. In several cases it go to the point where we'd just run two queries and do the join in (trivial) .NET code. Not coincidentally, this is also where we were starting to have serious conversations about moving away.
At one point our ops team accidentally put the main database on the (slow) system drive instead of the SSD-backed storage. This wasn't immediately obvious, until it started timing out and doing other strange things. Essentially, when you hit load limits, it just acts badly and doesn't tell you what's wrong. We only figured this out from looking at I/O graphs and seeing the system drive maxed out.
Stale indexing really is a big problem. We may have been misusing this feature, but we had an index that gave a list of objects that included counts and some other data from inside each document, and this was used as the main UI list. Because sometimes it would go stale, you'd add an object, then go back to the list and it wouldn't be there. Telling it to wait for non-stale is okay, when indexing is working, but when you have some of the other problems we had you end up with a useless system.
So I'm sure a lot of this can be chalked up to using it wrong or not being educated enough.. but that is also a documentation issue. I don't often feel stupid when I use products like this, but I did get that feeling often from RavenDB.
The combination of bad situations we got into (eg: "ANOTHER problem with RavenDB? Why are we still using this thing?") and the fact it was not a core business system or product for us was what basically lead to us moving away: we felt we were spending more time fighting RavenDB problems than we were supposedly saving by using SQL.
For the upsides, RavenDB is by far the easiest DB I've ever written against. Getting up with CRUD operations is stupidly simple and just works. The in-memory instance you can create on-the-fly for unit testing is amazing.
However.. (please bear in mind, these are my opinions and largely from recollection, it was >1 year ago now)
LINQ for secondary indexes is awesome.. when it works. When it fails, you're left with useless stack traces and really, really bad error messages. Often this doesn't happen immediately. In one instance, someone had accidentally inserted some enum values using strings instead of integers (or vice-versa, whichever was the way we weren't using). The index operation would appear to work fine, then eventually get stuck on these incorrect records (after minutes or even hours), retry a bunch, then mark the index as failed and it would suddenly be useless. It took a long time to figure out the cause of this.
I also found the secondary indexes actually got quite difficult. It would either be really easy to get something working, or mindbogglingly confusing. Sometimes you have to project/cast results, other times you don't, and it would never be obvious (to me, though others on my team had the same complaint) -- you'd just have to see you're missing a bunch of fields, then realize "oh this one needs to be projected or needs a cast".
I found joins to be even worse. They either worked right away, or required an hour of messing around with to figure out what magic options needed to be passed. I'm sure this is lack of experience/knowledge on it, but we found the learning curve to be VERY high. This included stuff like when we changed a join from using one index to another (that included some other data) the join would have to be changed dramatically, and it never seemed obvious why. In several cases it go to the point where we'd just run two queries and do the join in (trivial) .NET code. Not coincidentally, this is also where we were starting to have serious conversations about moving away.
At one point our ops team accidentally put the main database on the (slow) system drive instead of the SSD-backed storage. This wasn't immediately obvious, until it started timing out and doing other strange things. Essentially, when you hit load limits, it just acts badly and doesn't tell you what's wrong. We only figured this out from looking at I/O graphs and seeing the system drive maxed out.
Stale indexing really is a big problem. We may have been misusing this feature, but we had an index that gave a list of objects that included counts and some other data from inside each document, and this was used as the main UI list. Because sometimes it would go stale, you'd add an object, then go back to the list and it wouldn't be there. Telling it to wait for non-stale is okay, when indexing is working, but when you have some of the other problems we had you end up with a useless system.
So I'm sure a lot of this can be chalked up to using it wrong or not being educated enough.. but that is also a documentation issue. I don't often feel stupid when I use products like this, but I did get that feeling often from RavenDB.
The combination of bad situations we got into (eg: "ANOTHER problem with RavenDB? Why are we still using this thing?") and the fact it was not a core business system or product for us was what basically lead to us moving away: we felt we were spending more time fighting RavenDB problems than we were supposedly saving by using SQL.