For integrating Microsoft Azure Cosmos DB with other Azure products or other products, there are a couple of challenges with the current system. Right now, the vectors are stored as floating-point numbers within the NoSQL document, which makes them inefficiently large. This leads to increased storage space requirements, and searching through a vast number of documents in the vector database becomes quite costly in terms of RUs. While the integration works well, the expense associated with it is relatively high. I would really like to see a reduction in costs for their vector search, as it is currently on the expensive side.

The areas for improvement in Microsoft Azure Cosmos DB are vector pricing and vector indexing patterns, which are unintuitive and not well described. I would also like to see the parameters of Fleet Spaces made more powerful, as currently, it's somewhat lightweight. I believe they've made those changes intentionally to better understand the cost model. However, we would like to take a more aggressive approach in using it. 

One of the most frustrating aspects of Microsoft Azure Cosmos DB right now is that you can only store one vector per document. Additionally, you must specify the configuration of that vector when you create an instance of Microsoft Azure Cosmos DB. Once the database is set up, you can't change the vector configuration, which is incredibly limiting for experimentation. You want the ability to try different settings and see how they perform, as there are numerous use cases for storing more than one vector in a document. While interoperability within the vector database is acceptable—for example, I can search for vectors—I still desire a richer set of configuration options.

There are several areas for improvement. Firstly, having a local development emulator or simulator for Azure Cosmos DB would be beneficial. It would be very handy to have a Docker container that developers can use locally. Although, I know there is a free tier and so on and so forth, having a local environment would be nice. For example, SQL Server is very portable. You can even install it on your machine. That is the number one thing that is missing in Azure Cosmos DB.

The second improvement area is the IDE of choice. That means how you interact with Azure Cosmos DB. For example, with SQL Server, you have SQL Server Management Studio. I know there is a little bit of support for Azure Cosmos DB in Azure Data Studio, but it is not heavily advertised or it does not feel like first-class citizen support. Developer experience or developer tooling is missing in terms of interacting with the database. Better developer tools or an IDE for interacting with Azure Cosmos DB would enhance the developer experience.

Lastly, there is some mixed messaging about what Azure Cosmos DB is, given its multiple APIs. There are so many Azure Cosmos DB APIs available. There is NoSQL. There are MongoDB, Gremlin, and others. There is still some mixed messaging for others who are new to Azure Cosmos DB about what Azure Cosmos DB is. Is this like MongoDB, but then there is also MongoDB in Azure Cosmos DB? I know it well, and I know that the default one is just NoSQL, but others I have interacted with over the last ten years or so get confused.

In Microsoft Azure Cosmos DB, I would suggest improvements in security. If anyone who has the endpoint and has access to infrastructure can potentially affect your DB. Instead of relying on a single endpoint for authentication, having multiple authentication factors would be beneficial. 

I have limited recent information about the use cases as I am about to leave my organization to pursue Masters in the US.

After three months of use, while it's difficult to specify improvements, the RU (Request Units) models could be enhanced. The model with autoscaling for RU is complicated to optimize RU consumption. Currently, we have some difficulties understanding the RU consumptions with our workload. For instance, we consume 200 RU, but the database is not big.

In RU models with autoscaling, we want to have more precision in the consumption of RU. The dashboard could include more detailed RU descriptions, IOPS, and compute metrics. Having more detailed metrics of RU consumption would be beneficial.

Continuing to educate customers on how they can take better advantage of Microsoft Azure Cosmos DB without having to completely rewrite their entire application paradigm would be beneficial. They can help them understand that there are multiple options to interact with it. They do not necessarily have to start from scratch. They can refactor their existing application to be able to use it better.

They can continue to find better use cases for it. It helps to be able to show our customers example documents or example applications. It definitely helps us to be able to show customers how they could be using this.

One thing that we do as a best practice is lock down Microsoft Azure Cosmos DB to where you have to use an identity to connect to it. For instance, I have a service running in Azure Container Apps, which is using my Azure account or identity. You cannot connect with the connection stream. You cannot connect with an access key. In that scenario, two things can be improved. The first one is the ability to assign role-based access control through the Azure portal for accounts to have contributor rights. Currently, you can only do that by executing a script using the Azure CLI. Being able to do that in the user interface would be more convenient.

The other thing is that when you are in that type of configuration and you want to use the data explorer through the Azure portal, you have to separately click the button to authenticate with your Entra ID. That times out after an hour or so, and then in order to reauthenticate, you have to leave the data explorer and come back so that any queries or anything you have up and running go away. That is another area of improvement.

Cosmos DB needs improvement in a few areas, primarily the ability to join data across containers. Currently, it doesn't support cross-container joins, forcing developers to retrieve data from each container separately and combine it using methods like LINQ queries. This workaround is inefficient and cumbersome. A built-in join functionality would be a significant improvement. Additionally, Cosmos DB's SQL queries are susceptible to injection attacks due to limited parameter support. Currently, only one parameter can be used, compelling developers to use string interpolation, which introduces security risks. The ability to pass multiple parameters would enhance both security and code quality.

Sometimes, clients may lack technical expertise and run queries without utilizing partition keys, leading to significantly increased request units and higher costs. While Microsoft Azure Cosmos DB currently leads the market, enhancements are needed, particularly regarding data statistics across different containers. Dealing with clients who have multiple containers often requires custom code to stitch data together, highlighting the need for functionality supporting joins across containers. Additionally, a more stable and predictable pricing plan would benefit both developers and clients.

The main downside I have faced was with hierarchical partitioning in Microsoft Azure Cosmos DB. When using the second partition within hierarchical partitioning, I encountered issues while fetching queries. Though it retrieves values, the performance is not optimal when using partitioning. For example, when dealing with users and different categories of users in hierarchical partitioning, the query results were not providing all the desired results. The documentation regarding partitioning keys was limited, and despite contacting support, the problem remained unresolved. Additional documentation on this feature would be beneficial.

For streaming platforms, Azure Cosmos DB could improve efficiency in data storage. Indexing can also be better. Enhanced capabilities are necessary to manage increased data amounts more effectively during searches.

Azure Cosmos DB provides vector search capability. I used it for an AI application. We needed a vector database that could manage and give us a dynamic connection with the application. It was quite easy to integrate with the application. Querying vector databases and writing the queries is very easy in vector databases. There is also an option for semantic search. We can use the search engines present by default in Azure Cosmos DB to search in the database. That is also useful. Most things were easy, but the vector API part was a bit tricky. If we have a lot of data, doing a real-time vector search is a performance challenge because the search happens over a large dataset. It consumes more time. It is computationally intensive and can be optimized.

I would love to see more features because the market is very competitive for cloud databases. There are many startups offering vector database integration at different speed rates or higher velocities.

There aren't any specific areas that need improvement, but if there were a way to achieve the right cosine similarity score without extensive testing, that would be very beneficial.

The cost is a concern. Microsoft Azure Cosmos DB did not decrease our total cost of ownership. From the standpoint of the old way of doing DBA operations, it did, but our cloud cost increased significantly. 

Unpaid support is not very good at all.

Azure Cosmos DB could be better for business intelligence and analytical queries. While it excels at high-throughput data ingestion and point reads with low latency, querying within partitions is smooth. Complex cross-partition querying, and BI/analytical tasks often necessitate moving data to other solutions like Fabric and Azure AI Search.

A limitation in Azure Cosmos DB is the 2 MB document size. Developers need more systemic support in chaining multiple documents if more than 2 MB is required. Compared to competitors like MongoDB, which allows for gigabyte-sized documents, Azure Cosmos DB's limit is small. An improvement could include increasing the document size or providing a method to manage larger sets efficiently. If they want to keep a 2 MB limit, they should provide a way to chain multiple documents in a systematic way so that developers do not have to figure out what to do when a document is larger than 2 MB. For some use cases, the 2 MB size is very small. If they improve this aspect, a lot of customers will benefit from it. 

Another area for improvement is making it available on different cloud providers. Currently, Azure Cosmos DB is an Azure-only offering. Not supporting other cloud providers results in Microsoft losing some customers.

The integration with other solutions needs to improve because Cosmos DB's interoperability is lacking in some scenarios. For example, I'm currently implementing Fabric. That involves migrating from environments without apps, processing data and users, and taking them to Fabric. 

When I have the pile of information that I need a data scientist to look at, I tell them to use Fabric as the development center. They can't connect to Cosmo DB, but I have data there. The documentation could be clearer, especially concerning infrastructure aspects.

One area for improvement is the ease of writing SQL queries and stored procedures in Microsoft Azure Cosmos DB. Writing an SQL query and a stored procedure on top of that is a little challenging. It is not so easy with Microsoft Azure Cosmos DB. It requires some understanding. It is a relatively new product, so the knowledge gap is there. There should either be better documentation or an easier way to implement. We should be able to write a stored procedure in a simple language like SQL.

Additionally, there should be support for maintaining large files. It does not support files that are more than 2 MB in size.

Other than that, I do not have any input. It is a good product. It solves all the problems I have seen.

A minor improvement would be enabling batch operations through the UI. Currently, to delete all documents in a collection, we must use an API, which some of my team finds inconvenient for admin tasks.

The auto-scaling feature adjusts hourly. We have many processes that write stuff in batches, so we must ensure that the load is spread evenly throughout the hour. It would be much easier if it were done by the minute. I'm looking forward to the vector database search that they are adding. It's a pretty cool new feature. 

The RUs still appear to be a black box for everyone. Even though they explain read and write RUs, it remains unclear for many users. With Microsoft Azure Cosmos DB, we are using event streaming in the entire organization. We are using a framework for event streaming, and we suddenly reached a huge amount - the capacity of 20 GB partition key. When it reaches 100% of RUs, we face issues. We have to work on rebuilding the partition key. 

Regarding billing, we need better control. Sometimes it exceeds the forecasted budget. More clarity on RUs would be beneficial, even though documentation exists.

There is a 2 MB limitation for a document, which is a hard limit. Additionally, modeling in Microsoft Azure Cosmos DB is more challenging compared to RDBMS and other NoSQL solutions because we cannot store everything in one place. Since it's NoSQL, we sometimes need to split one document into multiple containers due to the 2 MB limitation.

Overall, it works very well and fits the purpose regardless of the target application. However, by default, there is a threshold to accommodate bulk or large requests. You have to monitor the Request Units. If you need more data for a particular query, you need to increase the Request Units.

The main area of improvement is the cost, as the expense is high. Also, when writing processes into Cosmos, sometimes the threshold is met, which can be a problem if developers have not written the code properly, limiting calls to five thousand. These aspects need addressing.

For areas of improvement in Microsoft Azure Cosmos DB, the cost from the RU perspective needs attention. The cost structure differs for internal and external customers, causing frustration among some internal customers. Additionally, outside of SQL and Mongo APIs, there is limited support for the APIs. Developing new features compatible for customers beyond SQL and MongoDB would be beneficial, and reducing the overall cost would make it more accessible for startups.

I do not have any specific suggestions for improvements at the moment. However, having more AI capabilities in the future would be beneficial.

We are at the beginning of production, and everything is working very well. The price can always be lower, but currently, it's not a problem.

The topic of RU consumption needs better documentation. 

Now that Microsoft has partnered with different LLM organizations, such as OpenAI, a bot could guide us through different metrics present in Microsoft Azure Cosmos DB. For enhanced productivity, it would be better to add information about the new features to the Microsoft Azure Cosmos DB admin dashboard itself. We usually have to rely on YouTube tutorials or the official documentation. 

Furthermore, while it is supported regionally, I did experience a rare case during our working time where it went down on their end and showed faulty previous data. Better error handling would be beneficial. We had to go to forums to check if it was failing for everyone else. It was surprising that a large organization like Microsoft doesn't provide an official statement about the maintenance or issues that could impact our overall usage.

What is missing in Microsoft Azure Cosmos DB is definitely cold storage. We know it's coming, but that's currently what is missing—the possibility to park older data in a cold tier. Aside from the storage, we are pretty happy with the rest.

Cosmos DB should continue evolving in AI features. We expect Cosmos DB to lead on that. There is potential for improved security features, which is important for data storage, especially for Dell Technologies. We must ensure data security remains the top priority.

One of our biggest pain points is the backup and restore functionality needs improvement. They've gotten a little better in this area. SQL Server's long-term retention is amazing, and you can restore data from years ago. You need to open a support Microsoft ticket to restore your Cosmos DB backup, and it comes in on a different Cosmos account. It's just kind of a headache to restore data.

CosmosDB's ability to search through large amounts of data isn't great. It kills the RUs if you're using the transactional store. We use Synapse Analytics for our more analytical workloads. We love Synapse for that purpose.

Areas of improvement for Microsoft Azure Cosmos DB include indexing. While it makes data retrieval easier, it also increases costs. If there's a better way to improve indexing at a lower cost, that would be really helpful, but that's the major point for now.

We had some performance issues with a data segregation query. We worked closely with Microsoft to solve the problem of performance where, for example, one query had a delay of almost two or three minutes for this one use case. Microsoft tried to improve the product, but in the end, the solution was to change to MongoDB. MongoDB had better performance. We reached the performance required using MongoDB instead of Microsoft Azure Cosmos DB.

There are no specific areas I believe need improvement as I am happy with what I am getting currently. However, I am open to new features in future versions, like possibly integrating AI features natively into Cosmos DB. Any improvement would be beneficial.

The only area Microsoft Azure Cosmos DB can improve on is its documentation; while it is solid and very useful, enhancements in the indexing documentation would help users save costs and make it more cost-effective. This is often a missing piece from Microsoft's side regarding how we can utilize it in the most cost-effective manner. The documentation for the FSx tab was not very good, and we faced a lot of struggles with it a few years back. I believe that has improved, however, Microsoft should really focus on these features since data analytics is very important today.

There is room for improvement in Microsoft's maintenance aspect. For example, we had a major incident at the end of December where the entire South Central region was down for our application, causing many problems due to a lack of access to the database. It led to missing data in some systems. They can implement a better backup system or alert system on Microsoft's end. We do receive notices for regular maintenance or updates, but sudden issues create significant problems.

We would like to see advancements in AI with the ability to benchmark vector search capabilities, ensuring it answers questions accurately. During our initial implementation, we faced challenges with indexing and sorting, which are natively available in other offerings but required specific configurations in Cosmos.

Currently, I have no suggestions for enhancement or new implementations in Microsoft Azure Cosmos DB. However, the cost can sometimes be high, especially during cross-partition queries with large data amounts.

One area that could be improved is indexing. Some of the developers struggle with the way the indexing works. We are exploring vector indexing, which we haven't examined fully yet. Indexing is an aspect we're looking to improve upon potentially.

It would be beneficial if Cosmos supported batch and real-time use cases to make the system more seamless. Our biggest challenge migrating data is the fact that we're a multi-cloud organization with data stored in multiple platforms like AWS and Snowflake. It's all over the place, so we are using solutions like Fabric to migrate the data. If you want to bring the data from AWS, you must pay data egress costs. That's a pain point.

Overall, it is a good resource. I am not aware of the background, but it seems to currently support only JSON documents. They could expand their scope to support other types of data, such as XML or EDI formats. EDI is an old technology, but it is still in high use in supply chain and retail industries.

In the long run, there should be an addition of more features, especially because this space is evolving quickly. It all boils down to how many more features you are adding, how many integrations you are supporting, and how many more APIs you have that are standard APIs. The team is already doing a great job. They are already doing all that is needed, but the more features we have, the easier it is for us and our clients.

For example, when you have these vectors, it requires us to know a little bit about the configuration behind things such as HNSW. When it comes to the MongoDB vCore piece of Azure Cosmos DB, people like us know how to get to higher recalls easily but a regular user may not. If they have a feature that provides an easy way to get to a certain recall you need, and that is a configuration by default, that would be great. Currently, the flexibility is amazing, and we love that. The competition is usually not providing that. The competition sometimes gives you a recall of 80%, but they are taking away the latency and requests per second. Azure Cosmos DB does not do that. It is a better solution. If Azure Cosmos DB has configurations and a feature allowing us to pick any of the use cases we want, it would be great. For example, if I have an application that I am okay with, and my application does not require a huge recall that is 80% but needs one that is 60%, for us, it is very easy to take HNSW and do it that way and reduce the requests per second because that might not be a concern. If there is a feature that allows people to pick out of five different permutations and combinations, it would be very easy for anyone else to do it. However, keep in mind that competition does not even have that flexibility, so competition is lagging behind on that, at least in the case of the ones we have tried. If Azure Cosmos DB has such a feature, it will be easy for more people to take advantage of the things we are taking advantage of.

Cosmos DB is quick at searching through basic datasets, though its indexing capabilities may not be as robust as some competitive solutions. This can make it challenging to perform complex queries on large datasets.

The current data analytics of Cosmos DB is inefficient for large-scale queries due to its transactional design. While tools like Synapse can transfer data to an analytical store, there's no effective way to utilize that data. Cosmos, in particular, is not optimized for analytical queries, especially with large datasets, and lacks the cost-effectiveness of solutions like Oracle Autonomous JSON, which seamlessly integrates analytical capabilities. Although Microsoft offers various tools, a comprehensive solution for efficient analytical queries within this system remains elusive, short of implementing a full-blown SQL Server.

I had a challenging experience implementing the emulator with a Mac. I had to install the emulator in a Docker container because it is not natively compatible. A significant amount of time was spent researching how to enable HTTPS communication when connecting the container and the emulator. I encountered TLS and SSL errors but resolved most of them by setting an environment variable in the container and using HTTPS protocol communication. I also had to use gateway mode with the Cosmos client in my Java app. I am disappointed with the lack of compatibility of the Microsoft Azure Cosmos DB emulator with Mac. I also found a scarcity of online resources regarding this issue.

It would be great to include compatibility with various databases like graph databases, adding to the existing NoSQL and MongoDB compatibility. I have used that for various projects on other platforms, and such additions would be beneficial.

Azure Cosmos DB for NoSQL has a less developed interface and fewer SQL commands than MongoDB, and its community support is also smaller. Additionally, Azure Cosmos DB for PostgreSQL users face the challenge of not having a portal for running queries.

Microsoft could improve its pricing, and the way request units are purchased. The current system requires users to pre-purchase an estimated amount of requested units, often leading to unused units and unnecessary costs. This pre-purchase model is inefficient and inconvenient for users. Overall, the pricing structure must be more flexible and transparent to align with actual usage.

Using it is easy. We are having trouble optimizing it. I'm not a technical person, so I couldn't explain why, but we're not getting the performance we were expecting. I'm sure it's probably an us problem instead of a product problem, but that's where we are.

From about half a billion rows, we're returning maybe 20,000 in two or three minutes. We don't know why, but we are working with Microsoft and a third party to figure that out. 

Cosmos DB has a couple of areas for improvement. Firstly, the lack of multi-collection joins is a significant limitation. Secondly, Azure Synapse Link, their data warehousing and synchronization feature, is unreliable and still feels like a preview feature. Improved reliability in this area would be greatly appreciated. Additionally, while Microsoft provides helpful internal monitoring tools, the managed nature of Cosmos DB can sometimes hinder visibility and make it difficult to troubleshoot issues, leaving us unsure whether the problem lies with our implementation or the service itself. Overall, we are satisfied with most aspects of Cosmos DB, but addressing these issues would significantly enhance its usability.

One of the primary challenges with Cosmos DB as a non-relational data store is the careful data modeling required due to the lack of collection-level joins when using the SQL API. While joins are possible within a single document, joining across documents or collections is not supported with this API. Although the Mongo API and Gremlin API on Cosmos DB allows for cross-collection joins this limitation in the SQL API remains a significant drawback.

The UI needs enhancement. Unlike SQL, Cosmos DB's UI is not as straightforward, making it a bit challenging to use efficiently.

Resource governance across tenants is something that requires some work. There is some room for improvement there. We are a multitenant solution. We decided to follow a certain approach in our architecture, which had an impact on the Azure Cosmos DB. There are multiple approaches to implementing multitenant architecture on Azure Cosmos DB, but there is still no single or best-recommended approach when you have a big variance in the size of your tenants. That is something that still needs to be worked on.

The monitoring aspect can also be better. There should be better monitoring of the costs versus the performance. That is sometimes difficult. It is easy to see or track performance monitoring and separately track your bill, but it is difficult to view the overall picture in terms of the relationship between the cost and the performance. That is something they still have to work on.

The one thing that I have been working on with Microsoft about this is the ability to easily split partitions and have it do high-performance cross-partition queries. That is the only place where either our data size or our throughput has grown beyond one partition, so being able to do cross-partition queries efficiently would be my number one request.

The request unit architecture that they have in place is understandable but could be better. What you get out of some solutions like SQL Server or MySQL is a lot more understandable. The request unit architecture of Azure Cosmos DB is not as easy as pure SQL solutions. They could do better in making the RUs more understandable and more flexible because changing your partition keys and your indexes is a larger batch of work than it necessarily needs to be.

There are some disadvantages as it is costly compared to other NoSQL databases. It has a complex pricing model and has a strict partitioning strategy. There are limited SQL query capabilities in Microsoft Azure Cosmos DB.

It is more expensive than other server cloud service providers with its request units pricing model.

There should be a simpler way for data migration. Currently, we need to write scripts to update data in bulk and ensure proper connectivity for migration with .NET, which seems hectic and risky.

The query searching functionality has some complexities and could be more user-friendly. Improvements in this area would be very helpful.

We have multiple applications. Our applications are running in different environments such as AWS and Azure. We are able to give flexibility to AWS to access this data from Microsoft Azure Cosmos DB. We have created an interface between them through APIs. Through the APIs, the AWS applications can consume the data from Microsoft Azure Cosmos DB, but we have seen some slowness or latency, whereas with Azure, we see better performance. Our AWS is in the Eastern zone, and people in the Western zone have some latency.

We encountered an issue with Cosmos DB's recently introduced hierarchical partition feature. After enabling it, we discovered that the web-based Cosmos Explorer tool sometimes fails when hierarchical partitioning is disabled. Although it usually works, we occasionally encountered situations where we couldn't query and manually inspect data in the Cosmos Data Explorer within Azure. We believe this is a significant issue and anticipate a fix will be released soon, although it may already be resolved.

The library of Azure Cosmos DB is like JPA, but it is not exactly JPA. We could not integrate that.

The size of the continuation token in Azure Cosmos DB should be static rather than increasing with more data, as it can lead to application crashes. They should use a static key size.

If we want to update some data, we cannot use the SQL command line. It is not like SQL Server or any other relational database. We have to send the JSON file or send the text to the Azure portal.  These are the only two options. We cannot use the normal SQL statement.

It is easy to use, but optimization has been a mixed experience. It has been more of trying to figure out how to do so. We have not found much support there, so we have to come up with our own way of optimizing it in different ways. That is one area of improvement. We would like to have more tools that support the optimization of Azure Cosmos DB. There are not many tools out there. We have had to develop our own tools internally, such as a clean plan or query plan, and look at the index usage, throughput, and those sorts of things. The portal experience for optimizing and monitoring the service needs a few enhancements.

I am looking at it through the lens of MongoDB API. There are four or five other APIs that are supported in Azure Cosmos DB. The MongoDB API experience could be improved substantially by having a more user-friendly set of administrative tools so that I can go out there and query the documents that are part of the collection. Currently, I am working around that by using third-party tools like 3T. I also use MongoDB's Compass client tool. They can make this part of managing the database or the collection a lot easier by providing some built-in toolsets, similar to what is offered by Azure with Azure Data Studio. That is a big area for improvement. 

We should also be able to better manage the cost. There have been some improvements there, but there is still room for improvement in terms of how costs are managed through the Azure portal relative to Azure Cosmos DB. To me, it is one of the more expensive services out there depending on how it is being leveraged.

One of the key limitations is that only so many vectors can be supported. It does not work very well with the large amount of text that has to be embedded in the vectors. That is one limitation we have run into with the feature set.

For the third-party driver support they are currently providing, they need to ensure it stays up to date with the market throughout development. If MongoDB updates a particular feature in their drivers, we as developers expect that service and support to be available in Microsoft Azure Cosmos DB as quickly as possible in production.

For our Disaster Recovery plan, we currently use geo-replication. We'd like to avoid full DR replication if possible, as this would result in significant cost savings.

There's a little bit of a learning curve because I was new to Azure. But once you learn the tool, it's pretty straightforward.

Once you create a database, it calls the container, and then items show up. A better description and more guidance would help because the first time I created it, I didn't understand that a container is similar to a table in SQL. 

There should be parity between the various APIs. I often work with the Mongo API, and features for it sometimes lag substantially behind the core API, such as the Analytical Store feature. Additionally, I am waiting for the full fidelity change feed that would surface all changes, including deletes to documents.

While Microsoft Azure Cosmos DB is generally easy to use, it has some limitations. Certain areas are more restrictive, and we are awaiting features that will simplify development. For example, currently under development, the full fidelity change feed will expose all document changes, enabling tasks like synchronizing collections while accounting for deletions. This is challenging because the existing change feed doesn't provide information about deleted documents.

One area of improvement for Cosmos database is the auto-scaling of RUs during high loads. It would be beneficial if the database could automatically scale resources rather than requiring manual adjustments.

Microsoft Azure Cosmos DB can be improved by providing more fine-grained control over certain aspects, such as connections and threads. There could be more control over how many connections are made. I am not sure if it is a knowledge gap issue. A regular connection with the Azure Cosmos DB team might help in addressing knowledge gaps. Being able to fine-tune these features would be helpful for us.

I think Cosmos DB enhanced the benefits of NoSQL databases, offering query flexibility, partition management, and backup and restore options. These aspects are crucial, and perhaps improving the complexity of partition management would be a beneficial area for Microsoft to focus on.

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.

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

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.

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

There is room for improvement in their customer support services.

The support tickets are not cheap.

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

There are no particular factors that need improvement. There is a little bit of a learning curve with scaling workloads, but it works smoothly.

There is room for improvement in terms of stability. 

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. 

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 solution’s pricing could be improved.

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.

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

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. 

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.

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.

The tool's pricing is expensive. 

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.

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 to see better documentation for this solution. 

The pricing of the solution should be reduced. 

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

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.

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.

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.

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. 

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.

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

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.

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.

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.

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. 

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.

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

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.