Lately we work great deal of time with Azure's CosmosDB.
This is how it's defined:
"It is schema-agnostic, horizontally scalable, and generally classified as a NoSQL database."
This, unconfident in itself, quote below is clarified as:
"The SQL API lets clients create, update and delete containers and items. Items can be queried with a read-only, JSON-friendly SQL dialect."
To be honest this SQL API made us favor CosmosDB.
So, we started a development with CosmosDB as a data storage.
The next development ingredient we learned the hard way is to try to refrain from clever techniques.
The lesson we learned is simple: after you finish with a project, provided it's not a toy, you give it to people who will be supporting it. You should think about those future developers before you're going to insert some cleverness in you code.
With this common sense we selected EF Core as a library that will serve as an interface between C# and the database.
Initialy all went well until we needed to store a list of strings as a document property and found it's not possible.
Why? - was a naive question.
Answer puzzled us a lot - because string is not an "Entity" (what ever it means), and EF is about framework of entities.
You could argue with this argument as long as you like, it just does not work. It is especially bad if you need to store a class that you do not directly control e.g. structures returned from other services.
Next pothole with EF was when we tried to run an innocent query that joins the data from document: e.g. document contains items, and you want to query some items from some documents.
Guess what?
Right, EF Core does not support it.
Why?
Because!
Later we have found that many other constructs and functions that you easily use in SQL dialect of CosmosDB are not possible or supported in EF Core.
We were very upset with those crutches and came to a conclusion that EF Core harms more than helps when you work with CosmosDB.
We went on and looked at how you work directly with CosmosDB client, and have found that it has all features ready:
So, do we need EF Core?
We answered, no.
This does not mean we reject the value of EF Core but here our conclusion was that this API layer just complicated things instead making them simpler. It might be that EF Core for CosmosDB is not mature enough at this time.