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.