I've seen many developers want to migrate away from a relational database (RDBMS) in the last few years. Often this is because they feel some class of NoSQL database (document store, graph database, key-value store, etc.) is easier to work with. They feel that native JSON storage and serialization/deserialization is much easier for them than an object relational mapping. There is also the performance argument, as different systems have been shown to scale quite well by adding nodes, much as we add additional web servers to meet the workload.

CosmosDB is Microsoft's NoSQL offering, combining a few APIs with very high scalablity and low latency. They also offer different consistency models for different needs. In almost every Microsoft event that deals with data, there is some CosmosDB demo, and some are very impressive. The idea of scaling without pre-planning some tier of hardware is appealing. But is this something we'd want to use for our application?

I'm curious what you might think of this piece that looks at a relational model and how that can be implemented in CosmosDB. Data Platform MVP Leonard Lobel walks through a typical commerce application and maps this into various containers and documents, showing how you might migrate away from an RDBMS into CosmosDB.

I find this read interesting, and to be sure, it's a simple view of the application. I'm not convinced this makes sense, though I am sure it would work. I think this is more inefficient than a relational model, and it leaves out lots of the challenges of being able to query lots of data at once. However, perhaps I'm just jaded and set in my preferences for the relational platform.

Read the article, think about the topic, and let me know. Does a move to a CosmosDB structure seem like a good idea for any of your applications? Are there any great benefits, any big downside, or perhaps, just not enough of a difference to even consider a migration? Does this make you more or less likely to consider a non relational store for a future project? Let me know.