8

As .NET developers currently we're using RavenDb as our default choice of database, in the nosql scenario. Now that Microsoft introduced DocumentDb, a nosql document database-as-a-service, we're looking for the differences between the two. Database-as-a-service does seems nice, as we run RavenDb on our own server.

Ayende Rahien as an interesting post, but it's a little outdated as it compares with an old DocumentDb version. Nevertheless it's still a good read.

Edit: After reading Thoughts on Azure DocumentDB I started doubting about the pricing of DocumentDb. Let's say my data model consists of 7 collections, this means I would have to pay 7 * $25 = $175 per month! I must be making some kind of mistake here, right!?

Edit2: The idea of the creators of DocumentDb seems to put more than one type of document into a single collection, which seems a bit odd to me after using ravendb for a while now. The term collection caused some trouble understanding DocumentDb pricing as it is something completely different in DocumentDb then in RavenDb

In which scenario would you choose DocumentDb over RavenDb?

Andrew
  • 5,395
  • 1
  • 27
  • 47

1 Answers1

6

The post recommends that you put a lot more stuff in a single collection than you would otherwise. I'm not sure of the wisdom of that long term, but they propose it as a way to keep costs down. Also, since there is no cross-collection transactional isolation, it might be better if you need to update more than one document at a time, to keep them in the same collection anyway.

Larry Maccherone
  • 9,393
  • 3
  • 27
  • 43
  • 2
    exactly. don't think of a collection as a table that can only accommodate a single type of entity. – Ryan CrawCour May 06 '15 at 17:38
  • It'd be apt to say DocumentDB's collections are closer to physical partitions than tables. Collections support many entity types (they do not enforce schema). Each collection gets a reserved amount of storage (10gb) and throughput (based on perf tier). You'll find that pricing to be quite competitive when looking at storage and throughput (compare to https://ravenhq.com/pricing.html) – Andrew Liu May 06 '15 at 19:16
  • Yeah, think of them as partitions. That helps. I still wonder about how that impacts the coding and running experience, but I will go with it for now. Will indexes be larger/slower because of this? Or is that only a concern in b-tree indexes, as opposed to the first 3 character hash approach that DDB uses? – Larry Maccherone May 06 '15 at 21:01