There's another feature that we just started implementing, which is partial updates of documents. It doesn't require the entire object to update, but updating documents across applications becomes difficult because you have to pull the entire document, which means you have to support the entire model to update it. So, that application has to know about every single parameter that may or may not have been added because if it reads and writes the document again, you'll lose data elements.

An improvement would be a more robust functionality around updating elements on a document, or some type of procedural updates that don't require pulling the entire document. Otherwise, you have to keep all of your apps up to date with the models, and that can be cumbersome and lead to errors. Usually, you don't always remember, and then it leads to some type of bug, but you won't realize why. You'll lose some value because you don't realize that you have some application that doesn't run often. You forget that it writes to that same document and you didn't update the model.

It would be nice to have some type of functionality for less common updating applications and to not always have to worry about keeping that model up to date.

There's some integration with Entity Framework and it's nice, but it's not robust and it would be good to have something like that when it comes to pulling data.

Occasionally, you have to query the database for values because we save our appointments and we don't have an index on appointments. We don't have a manual lookup for appointments, so we don't save it in another file. We have to run a query to get appointments that occur on a specific day and the downside of that is you have to use strings just to hardcode the string values. It would be nice to more easily integrate with a tool like Entity Framework, and I know that they do, but it's not an easy process. It would be nice to have an easier way without relying on text to query the database.

In terms of improvement, slight enhancements in integration interfaces, expanded dashboard functionalities, and broader use-case support would be beneficial.

The built-in integration of the solution is tight. It can be used in conjunction with Synapse, Microsoft has also created a Synapse link. In this solution, the OLTP workload will never affect the OLAP workload. Therefore, the solution does data replication asynchronously without affecting the OLTP source system. No specific pipeline is thus required, which is not easily found in other services. 

In the server, there are two ways in which you can provision a call, one is serverless, which has a pay-as-you-go model, and another is a dedicated provision throughout. So, irrespective of what you allocate and whether you use it or not, in this solution, the charges are accounted for the request unit per second. This is a big drawback of the solution.

This is an expensive solution and if you get the initial calculation wrong involving how much you are going to ingest, how many people are going to query and more, then you are going to receive a very large bill at the end of every month.

Additionally, on the serverless option, there is a limitation regarding the amount of data you can ingest; this doesn't allow you to upgrade beyond a point, and the limit cannot be utilized for many use cases. On the execution side, whatever you create as a container, that container cannot be used as a destination when using serverless mode. This is another key limitation of the solution. 

The downside is that Cosmos is new and fairly complex. There's a limited pool of talent who are really good at working with it.

Because of that, I've been approached by recruiters quite a bit; they see my Cosmos DB certification on LinkedIn. It's hard to find people to work on Cosmos projects. 

Sometimes, a really smart developer will design and build a Cosmos implementation and then move on, leaving the company struggling to find someone to work with it and maintain it.

Interestingly, if you need to restore a Cosmos DB database, you have to put in a ticket with Microsoft – they're the only ones who can do that.

The solution cannot join two databases like Oracle or SQL Server. Joins have to be done programmatically through our sysHUB. We use .NET code so need the middleware to join databases. 

There are certain restrictions for inner classes or employee roles. 

Data retrieval is slightly more difficult than in SQL Server or other SQL databases. 

Documentation needs some improvement to help end users. Documentation for joining includes some generic or peculiar cases but needs to be more comprehensive. It should lay out how to join databases and what procedures to use. 

The integration of the on-premise solution with the cloud can be difficult sometimes.

There is room for improvement in their customer support services.

At this stage, we would like more enterprise support. We use MongoDB a lot, and we're trying to get rid of MongoDB. So, I would like to see more features in the Cosmos DB API for MongoDB space.

Sometimes, the solution's access request takes time, which should be improved.

I have been a devoted Microsoft fan, but Redis DB's memory caching capabilities are really making progress. Even if Cosmos DB is continuously improving and is quite advanced in the field of internal memory optimization, I would still recommend Redis DB to a customer. My dilemma still lies in the price of both solutions. I believe if Redis DB is superior and pricier than Cosmos DB, customers will be reluctant to use Redis DB.  

Memory streaming and various optimizations contribute to higher costs but also increased speed. Currently, there's nothing specific I can pinpoint that needs to be added – I haven't made any purchases yet. However, I am inclined to recommend working with it. 

By design, Microsoft Azure Cosmos DB provides multiple APIs. You have to decide where to write to. Will you write to Excel, Word, PPT, or OneNote? You have to do the homework properly. If there is no tool, then there will be no provision, then there is no database.

I would like to see Cosmos DB introduce a feature that would convert machine language to human-readable queries. For example, if we want to generate a simple diagram that shows the relationship between devices and how frequently have they failed at various locations, we have to consider that the IoT data that is put into Cosmos DB, called byte codes, is not readable to humans. This is a machine language type of data. So when we push that type of data it looks like gibberish, because it is not meant for us, meaning we can't write a normal query. We have been asking for years for them to work with the IoT partner to provide a feature to convert the machine language to readable human queries.

The UI should be improved since if you provide the option to query directly when signing into the Azure portal, it makes no sense if you have such a poor UI for querying that you can't even feed the reports correctly. 

It should offer a simple user interface for querying Microsoft Azure Cosmos DB.

At the moment, because I'm still new in terms of using Microsoft Azure Cosmos DB, I don't have any feedback regarding areas for improvement in the product. So far, it has met all the expectations and needs of my company.

It would be nice to have more options to ingest the data, for example, more file options or more search options. Currently, you can use JSON, but if there were other file types you can use for data ingestion, that would be nice. This is the additional feature I'd like to see in the next release of Microsoft Azure Cosmos DB.

One thing that concerns me is the cost, especially for smaller workloads. Cosmos DB is a little more expensive than other database services, particularly if you have tight-traffic models. However, it does have a few advantages, such as being a multi-model database. The biggest problem is the learning curve and other database services like RDS. 

Additionally, advanced analytics capabilities like real-time analytics and machine learning are not embedded in Cosmos DB. Vendor lock-in is a big concern. Cosmos DB is a proprietary database service offered by Microsoft that might not be compatible with other databases. 

There is room for improvement in terms of stability. 

I hope they improve the service. Before last year, improvements on Cosmos DB were very slow. I didn't see many changes in the functionality.

The support tickets are not cheap.

I would like to see better documentation for this solution. 

The pricing of the solution should be reduced. 

The performance point can be improved because when we run a search query on our on-premises machine and develop connectivity, a response comes in. But sometimes, the response gets delayed, and it can be due to network latency or something else we are yet to figure out.

Performance and high availability are two features I want to be added in the next release because that is the basic requirement of customers. Mostly, we have customers with the bank and banking institutions, and they want their databases perfectly integrated with the high availability feature.

The tool's pricing is expensive. 

The solution’s pricing could be improved.

The pricing of the solution is an area with certain shortcomings. From an improvement perspective, I wish for the solution to offer users an increased storage capacity at a cheaper price.

I would like the speed of transferring data to be improved.

It is not as easy to use as DynamoDB. The product always shows JSON-based documents. However, DynamoDB shows a table-based document. The documentation must be improved.

In Microsoft manufacturing, managers really need to know about the product. This market is flooded by other vendors. So putting Microsoft in action in such places looks challenging.

I provide architect solutions on top of Azure. A couple of features that would help me in architectural solutions would be customizable architecture or customizable documentation, which both Microsoft Azure and Microsoft Teams can provide. I can easily pick and choose a couple of architecture and merge them. This would be a very helpful feature for me in my role.

We should have more freedom to tweak it and make our own queries for non-traditional use-cases.

Microsoft Azure Cosmos DB's pricing model is complicated, which people don't understand. So, the pricing model should be improved.

There are features that are ADF only or ADB only, so it would be good to see more cross-compatibility between the two. The solution is also more expensive than the alternatives. 

Since we're working in the cloud, it's not easy to incorporate all the features it supports. There is room for improvement in terms of integration with other vendors.

Better documentation on how to integrate with other components would be helpful because I was struggling with this. For example, I had trouble finding information on how to integrate with other Microsoft components. Also, consider a situation where you want to use Cosmos DB to manage the uploading of data to your website. Information on how to do things like this should be readily available.

The query is a little complex. SQL server should have more options. But the query should be better. 

The setup takes a bit of time but once it's done, it goes well. Backend developers need a bit of time to do the setup. 

The API compatibility has room for improvement, particularly integration with MongoDB. You have to connect to a specific flavor of MongoDB. We'd also like a richer query capability in line with the latest Mongo features. That is one thing on our wish list. The current version is good enough for our use case, but it could be improved.

I cannot recall finding any missing features. Everything we need is pretty much there.

It would be ideal if we could integrate Cosmos DB with our Databricks. At this point, that's not possible.

Microsoft Azure Cosmos DB's performance could be better. In large volumes of documents, the querying process becomes slow and complicated. It could be faster.

New features can be included and its stability can be further improved.