In the Domino world we had a nice, easy to use, built in noSQL datastore in the NSF alongside your application, or you could easily code your application to use data from a different NSF if you wanted to separate the datastore from the frontend. Either way it was easy to use and easy to access.
So how do you go about deciding on a data store for a new development track? My first suggestion is to look at any other datastores that you are working with in your company. If you have a team of DBAs that all use Oracle DB then maybe that is a good choice for your relational data, if you have DBAs that talk Microsoft SQL then maybe your decision should be in that direction. Need an noSQL solution then options include Mongo, CouchDB etc.
One of the recommendations of the microservice approach is that each microservice has its own datastore and that the datastore is appropriate for that particular microservice. What this means in the real world is that you may end up with some of your microservices using relational SQL and some using noSQL document stores. It all depends on the microservice. Having said that you should still try to pick a standard so that when you know you need a SQL datastore you will use the same SQL datastore.
We have a MSSQL DBA on staff and a number of MSSQL servers, so we decided that our main SQL datastore we will use Azure MSSQL. For noSQL document stores we are looking at Azure DocumentDB and for file/blog storage we are looking at Azure FileStorage. Yes that is a lot of Azure and there are reasons behind that which I’ll discuss in later posts.
Dec's Dom Blog 
I would be interested to hear why you decide to go with Azure documentDB versus MongoDB. Having in Azure DocumentDB locks you into a fixed vendor versus MongoDB which allows you to be more flexible.
LikeLike
Isn’t Azure DocumentDB in cloud version only? How do you handle on premise deployments?
LikeLike
You will notice a lot of our stack is Azure Cloud based and that we don’t have any need for on-premises ( not ‘On Premise’, that means ‘something assumed or taken for granted’ ) deployments. Azure networking does have the ability to link the Azure Cloud deployments to your own MPLS network via Azure Virtual Networks if you need that linkage.
LikeLike
There is a MongoDB emulation mode on Document DB which may avoid lock-in. there is also a local instance that can be used for development.
It is worth looking at the costs on DocumentDB. You pay for a maximum throughput rather than for usage, you can throttle it up and down but it does feel like the kind of situation where you could spend quite a lot just learning how sensitive it is. In Lotus Land night time is often when we hit the databases hardest with agents etc.
The pricing is also by collection which I think is somewhere between an NSF and a view. i am still trying to understand how the normalisation works.
I am certainly intrigued by Document DB, an all MS stack would have advantages but it would be nice to avoid lock in. There have bee some price announcements just recently that seem to disadvantage “pay as you go” users and I am sure that all of the vendors will make changes at some point.
LikeLike