Microsoft Azure Cosmos DB Reviews

My main use cases in my company for Microsoft Azure Cosmos DB are to store data for semi-structured and unstructured data and to retrieve data for data agents.

The feature I have found most valuable in Microsoft Azure Cosmos DB is its scalability and speed.

Microsoft Azure Cosmos DB can scale quite fast and easily, and you can store a lot of data, so I believe that is the biggest advantage of it.

I evaluate the enterprise-grade security features of Microsoft Azure Cosmos DB in terms of data encryption and access control as a positive implementation because data security is important today, so it is very beneficial.

These features have helped improve my company's data security strategy because every client, as I work in a consultancy, wants their data to be secured, and nobody wants it to get leaked. The features already implemented into Microsoft Azure Cosmos DB help to make our job easier.

I think it could be better if it included more in regards to AI or if it were more exposed to AI. I find it straightforward as you store whatever you want and then train the models and fine-tune the models.

I have been using Microsoft Azure Cosmos DB for around six months, as they introduced it relatively recently.

In my experience, the global distribution and multi-region replication of Microsoft Azure Cosmos DB have not significantly influenced the performance and availability of my applications because we work primarily in West Europe. I did not experience much multi-regional functionality as we are based in one region and work in one region.

Microsoft Azure Cosmos DB can scale quite fast and easily, and you can store a lot of data, so I believe that is the biggest advantage of it.

I have utilized Microsoft Azure Cosmos DB's multi-model support for handling diverse data types to some extent, but not extensively.

I would assess Microsoft Azure Cosmos DB's automatic and elastic scaling of throughput and storage for my current projects as quite good, as it is fast, easily scalable, you can store a lot of data, and you cannot see significant latency.

I have minimal interaction with customer service and technical support because we have salespeople and more tech-related sales representatives who handle all the talking and requirements gathering. I am more of a tech-savvy technical specialist who implements everything.

Neutral

Before choosing Microsoft Azure Cosmos DB, the company I work for did not use another solution. I have had some exposure to AWS, but now I am in the Microsoft stack.

For me and my colleague, the deployment process for Microsoft Azure Cosmos DB is quite easy and not complicated.

The biggest return on investment for me when using Microsoft Azure Cosmos DB is that you can store everything—not only structured data or unstructured data, but everything. You can also integrate it with AI, which I believe is the best investment.

I do not believe my company is considering other products instead of Microsoft Azure Cosmos DB because we are currently very happy with the product and what Microsoft is doing by integrating Microsoft Azure Cosmos DB and AI Foundry. We also received news that it is a DocumentDB as well, so we will stay within the Microsoft tech stack.

I would say the main difference between AWS and Microsoft is that I prefer Microsoft since, in my opinion, it is more user-intuitive and everything is on one platform. If you want to do Fabric, everything is in one place, and if you want to do Azure, everything is still in one ecosystem, so you do not need many third-party applications to do your job.

From what I have used, I believe the tool is quite good.

Microsoft Azure Cosmos DB is currently quite good, and I do not have any enhancements I would recommend since I am not a heavy user, having used it for about six months.

My advice to other companies considering Microsoft Azure Cosmos DB is to simply try it, and you will love it. I would rate this product a 9.5 out of 10.

I was using Microsoft Azure Cosmos DB to store unstructured data.

It is easy to learn how to use Azure Cosmos DB.

Azure Cosmos DB enhances search result quality by enabling rapid data retrieval within its collections. It can handle large amounts of data efficiently.

Azure Cosmos DB offers numerous advantages, including flexibility, cost-effectiveness relative to performance, and a pre-existing infrastructure on Azure. Its support for multiple data models, extensive document database capabilities, and fully managed maintenance provided by Azure make it a compelling choice with immediately apparent benefits.

Microsoft Azure Cosmos DB simplifies the process of saving and retrieving data. The only requirement is to create the collection and streamline data management.

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.

I have used Cosmos DB in my previous project for around one year.

Azure Cosmos DB offers high availability, at approximately 99.9 percent, with good latency.

Azure Cosmos DB handles scalability well. It is easy to scale up the workloads.

Dynamic scaling enhances cost-efficiency and usability by automatically adjusting resources to meet demand. This means the system scales up capacity when needed and scales down when not in use, preventing unnecessary expenses.

I have used MongoDB, but not extensively. If working with Node, I would recommend Mongo, but in a Microsoft environment, I recommend Cosmos.

The initial deployment was manageable. It took around five to seven hours to deploy Cosmos to a working condition fully.

At that time, we had a team of four people managing the infrastructure and deployments.

I would rate Microsoft Azure Cosmos DB a seven out of ten.

New users should be familiar with DocumentDB since most people are only aware of relational databases, but Cosmos is different.

I have been using Microsoft Azure Cosmos DB for the last five years for IoT-based data saving and other purposes. We use non-structural data for various reasons. For instance, we are using artificial intelligence to save multiple data sets coming from different sources.

It is a managed service, so we do not want to worry about other aspects.

One valuable feature of Microsoft Azure Cosmos DB is partitioning. Its performance is very nice. I use it mostly on the Microsoft backend, particularly .NET and .NET Core technology. From deployment and accessibility aspects, there is significant performance improvement.

Additionally, consistency is noteworthy. For example, we have people spread across multiple locations. If they update data in Australia, we can access it in another location within a fraction of a second. That is an impressive feature of Microsoft Azure Cosmos DB.

It is very good from the optimization and usage point of view. It is very user-friendly. Microsoft also provides support from the performance aspect. They support us from the optimization and scalability aspects.

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.

I have used the solution for five years.

We are seeing some latency issues with AWS. It offers good availability. 

Being serverless, the scalability is very good.

We pay for the support. We are happy with their support. If we face any challenges initially, they provide us with a resource to answer all our questions.

Positive

Previously, we used MongoDB and DynamoDB, though not extensively. Because of client preferences and their use of Azure, we chose Microsoft Azure Cosmos DB. DynamoDB uses clusters, which affect costs.

The initial setup can be somewhat tedious. We have to set up things, run them, see the results, and fine-tune them.

The initial setup took more than one month. After that, everything became automated. Now, if we want to deploy it in another location, the operational team typically takes one week. They verify whether everything is working properly or not. By using the automated scripts, we can deploy it at other locations.

We have a separate team for configuration. We also get support from Microsoft.

Its price is in the middle, neither too low nor too high.

We are happy with the usage of Microsoft Azure Cosmos DB for our use case. In terms of learning, it is of medium complexity. It is neither very tough nor very easy.

Overall, I would rate Microsoft Azure Cosmos DB an eight out of ten.

I find SQL API suitable. I used it in my last project. Previously, I worked for a client called EPS, which has a product called BOS (brokerage operation support system). There I have used the SQL API.

I have used it in a product called BOS, and we achieved many things with Microsoft Azure Cosmos DB, which helped improve our products efficiently.

It helps in many ways in my current projects such as brokerage operation, which shifts multiple data in different regions. It helps significantly in storing and retrieving data from different countries for shipping details, shipping ID, and all data records in different countries.

Microsoft Azure Cosmos DB is a fully managed globally distributed NoSQL database. It is highly available with low latency and scalability. It supports multiple data models and APIs, making it flexible for different applications. Its features include multi-model support, global distribution, automatic scaling, and support for multiple APIs such as SQL API, MongoDB API, Gremlin, and Cassandra.

We can use Microsoft Azure Cosmos DB for storing and managing all types of data manipulations including inserting, fetching, and updating records. These operations can be performed efficiently.

The storage in Microsoft Azure Cosmos DB is globally distributed and highly efficient. Storing and retrieving data is much faster and more efficient.

It is cloud-friendly and easy to use. We can easily insert data and retrieve information from this cloud platform. The UI is better, faster, and efficient.

It supports various types of APIs and is a fully managed, globally distributed database that helps in different regions. Microsoft Azure Cosmos DB is a distributed and multi-model NoSQL database that supports SQL, MongoDB, and other platforms. Its scaling is managed using the request per unit, and it has auto-scaling based on business requirements.

The features include support for multiple NoSQL data models such as documents in JSON format, key-value store, graph database, wide column store, and MongoDB compatibility. In the document model, we can use the SQL API, while in the key-value store, we can use the table API. The Graph database is used for Gremlin.

It has a large capacity of up to 12 GB per physical partition per container. I have used up to three to four GB.

Its latency is high and impressive. The support is very high, with read-write latency at 10 ms per second.

It handles large-scale operations efficiently, such as tracking views, logs, or events. It has high write throughput and handles partition issues and storage growth effectively.

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.

I have one year of working experience with Microsoft Azure Cosmos DB in my current organization.

The solution scales very well.

I'm not sure about technical support. I haven't worked with them. 

Before Microsoft Azure Cosmos DB, I used SSMS and MySQL server management. For cloud solutions, I have only used Microsoft Azure Cosmos DB.

Initially, we logged into the Azure portal and create a new Microsoft Azure Cosmos DB account. Then we chose an API such as SQL API or MongoDB. We set up account details, subscription, region, and enable geographical replication and multi-write regions. After that, we created a database and specify the name and provisional throughput. Then we created a container inside, providing the container ID, partition key, and index policy.

It took around 15 to 20 days for full-fledged training.

Initially, it took approximately three months to get comfortable for learning purposes. I encountered some difficulties while learning, however, through the project, I learned many things.

It's fully cloud-based, so there is no maintenance.

We have six developers for deployment and related tasks in Microsoft Azure Cosmos DB.

AWS is another choice available. I find Microsoft Azure Cosmos DB better suited for my needs.

Microsoft Azure Cosmos DB and AWS DynamoDB are basically the same, however, Microsoft Azure Cosmos DB supports multi-region support and can replicate and auto-replicate the data. It is highly manageable, which is why I chose Microsoft Azure Cosmos DB.

I definitely recommend Microsoft Azure Cosmos DB. It handles large amounts of data, is highly reliable, and operates in a very fast and efficient way. Users can deploy their applications in the cloud, and it supports various APIs. On a scale of one to ten, I rate Microsoft Azure Cosmos DB a nine out of ten.

I develop applications. I developed an application where I had to search the Azure Cosmos DB database for values related to suspicious entities. It involved retrieving, sorting, and manually searching data through queries.

Azure Cosmos DB helped improve the quality of our search results. We could see its benefits immediately after the deployment.

The availability and latency of Azure Cosmos DB are excellent. It handles large data insertions efficiently without any problems related to scalability. It scales workloads very well.

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.

I have been using it since December 2021.

The scalability is very good. We performed performance tests, inserting objects with more than 10,000 records without any issues, although, on the application side, we started to see high memory consumption. That is because, with larger JSON files, you will have more objects in the Java application. These things consume memory, but there are no issues regarding scalability.

I have not contacted their support.

Neutral

I have experience with MongoDB but only for personal studies. I only learned the basic things.

It was easy because we have Terraform embedded in the Jenkins pipeline. Once I deploy the application, it connects with Azure Cosmos DB. It is already configured, so I do not have to worry about this part.

It took us about one month to get onboarded and understand the basic functionalities. 

It does not require any maintenance at our end.

We usually have a team of three to four people.

I am not aware of the price, but a challenge that I have faced occasionally is that running longer queries requires more RUs, so I have to ask someone with permissions to execute the queries.

I would advise learning more about queries and select statements. You can use that on the Java side and Cosmos SDK.

It is easier to learn if you already know relational databases. You can use some of that knowledge to work with Azure Cosmos DB. Also, if you know JPA, it would not be so difficult to work with the Cosmos SDK for Java application development. Inserting data is also simple.

It is at a medium level in terms of ease of use. There is documentation for gathering the information. Azure Cosmos DB does not have any constraints for the column names. If you want to create a specific query, you can find information related to that in Microsoft documentation. You can find queries to solve specific problems.

I would rate Azure Cosmos DB an eight out of ten.

We use Microsoft Azure Cosmos DB for a lot of facets and various production-based products. In one case, we use it to store news articles and process information about them for AI processing. We also use Microsoft Azure Cosmos DB to store conversations with AI chatbots and for managing data pipelines and orchestration. These are just a few of our use cases.

We use the built-in vector database primarily for searching documents that live within Microsoft Azure Cosmos DB. For instance, if I have a lot of documents stored in Microsoft Azure Cosmos DB and I want to do vector-based searching on those documents, having the vector store in Microsoft Azure Cosmos DB makes a lot of sense because the vector store lives in line with the data. It is in the same workspace and the same region. We do not have to worry about ingress and egress charges because with it being co-located with our data, we are going to have better performance. In other cases, we use the vector database as a vector index for documents that do not even live in Microsoft Azure Cosmos DB. This could be documents that live in a storage account, for example. We find that the vector store within Microsoft Azure Cosmos DB is highly performant and a good place to store those indexes for fast searching.

We have primarily integrated it with web applications that live within Docker containers. They are Azure Container Apps and Azure Kubernetes Service (AKS). They are the primary ones. The nice thing about those services is that we have all of our custom code running within those containers. We use them in a couple of different scenarios. When we are using Azure Container Apps, those are within standard public endpoints, and the integration works quite well. In the case of AKS, we are doing that using private endpoints and virtual networks, so it is locked down a lot more, but the integration with Microsoft Azure Cosmos DB is still easy. That is because we are also using private endpoints for Microsoft Azure Cosmos DB. In both scenarios, it works quite well.

We use it quite a bit with Azure AI services. That goes hand in hand with using the vector store within Microsoft Azure Cosmos DB as well because we typically call out, for example, Azure OpenAI to do some embedding of the data that either lives in Microsoft Azure Cosmos DB or outside of Microsoft Azure Cosmos DB. We then store those results in the vector store. Also, sending the data content that lives in Microsoft Azure Cosmos DB as context to AI services works well too.

Microsoft Azure Cosmos DB has helped improve our organization’s search result quality in a couple of cases. In one case, it does that when we are using the vector store. We already talked about those unique capabilities, but in another case, we have used it alongside Azure AI search. Indexing the data that is in Microsoft Azure Cosmos DB in that search service works quite well. Using a combination of the vector stores and the content from Microsoft Azure Cosmos DB to do a semantic type of search or hybrid search options also works well.

We were able to see its benefits right away. That also comes down to our level of expertise. If you pay attention to how you model your data, how you set up the containers and configure them, and those things are optimized for performance, you will see immediate benefits. Those things are crucial to see immediate benefits. Some people might not know how to do those things as well at the beginning, so it might take a little bit longer. If you follow best practices and documentation, you can see benefits right away.

The most valuable feature of Microsoft Azure Cosmos DB is its ability to handle concurrency and consistency. In scenarios with heavy usage where multiple users or services are accessing Microsoft Azure Cosmos DB or updating and creating new documents, its ability to manage such interactions in a performant way is outstanding.

For me, it is easy because I have a lot of experience with it, but it is easy for most people to get started with Microsoft Azure Cosmos DB. The more challenging aspect is modeling your data for the best performance. That is one of those things where there is a little bit of a learning curve to do it correctly, but there is a lot of good information out there on how to do that.

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.

I have been using it since before it was Cosmos DB. Back then it was called DocumentDB, so I started using DocumentDB in 2016.

Microsoft Azure Cosmos DB is highly stable and built for stability and scalability. Outages are rare and usually due to regional issues rather than the service itself. I have not experienced Microsoft Azure Cosmos DB as the only service being down in a region.

The ability to scale workloads is one of its strongest points. About three years ago, they added the auto-scale feature which helped a lot. Before then, if we were going to do a big batch processing workload against Cosmos DB, we would manually scale it up. Manually scaling up usually takes seconds. It is immediate, depending on how high you are scaling it up. If you are scaling it up by a certain high factor, it can take a little bit longer, but, generally, it is fast. Now, auto-scale throughput is what we use in all of our deployments. In cases where it has to automatically scale up to your maximum, that happens very quickly.

I contacted their technical support once a few years ago to restore a Cosmos DB backup point. The response was quick. It was all done electronically. I did not talk to anyone on the phone, and it was a quick resolution. Their support was good for that one case.

Positive

I have used RavenDB, which is probably the closest to Microsoft Azure Cosmos DB. I have also used MongoDB through Atlas, which is very similar to the MongoDB API available on Microsoft Azure Cosmos DB.

The initial setup is easy. You can quickly deploy it through the Azure portal. You do not need a whole lot of configuration to get started. If you want to programmatically deploy it, that is also a simple process. You can do it through ARM or Bicep templates or even through Azure CLI. It is quite simple.

In terms of the learning curve, back when it was DocumentDB, it did not take very long to get onboarded. It is a matter of getting used to the conceptual differences. If you are a traditional database administrator, you would not have to do your typical tasks that you would do with SQL database as an example. That is a little bit of a mind shift. If you are a developer and you are used to working with relational databases, that is also a very big mind shift, but it is not any different than using any competing NoSQL database.

We teach a lot of people how to use Microsoft Azure Cosmos DB. People generally get it quickly. A lot of the learning curve comes in the details. It is quick for people to get up and running and do something with Microsoft Azure Cosmos DB. There are a lot of quick-start examples and resources out there. The longer learning curve is how to properly optimize and take advantage of the features that I already talked about. You can get up and running and start using Microsoft Azure Cosmos DB in a day, but to fully understand how to properly optimize it and configure it requires a couple of weeks of experimentation and learning. Then you get very proficient at it.

Its maintenance is being taken care of by Microsoft. That is one of the benefits.

The pricing for Microsoft Azure Cosmos DB is good. Initially, it seemed like an expensive way to manage a NoSQL data store, but so many improvements that have been made to the platform have made it cost-effective. With so many improvements to the platform and ways to optimize, in our big enterprise deployments, Microsoft Azure Cosmos DB tends to be one of the least expensive services even though it gets a lot of use. The pricing has improved a lot over the years.

My biggest advice is to learn how to correctly model your data. Learn how to select the appropriate partition key. Learn how to use the change speed if you need to use more than one partition key. These are all performance-based things that have a higher learning curve. These are the most important things to get down so that you are not overspending and so that you do not have to scale it up higher than you otherwise would have to because things are not set up properly.

Microsoft Azure Cosmos DB can decrease the total cost of ownership if you are taking advantage of certain things such as being able to do some downstream processing of data using the change feed, which simplifies how you can process incoming data versus having multiple services set up. That is one example. Another example could be doing analytical queries against Microsoft Azure Cosmos DB. You can use something like Synapse Link so that the data gets stored in parquet files in the storage account automatically for you, and you can query over those using something like Spark. That saves you time and money because you are not hitting your operational store. You are not consuming RUs, so you are not worried about data movement, and you are removing having to set up a separate data pipeline to do that. That is a potentially big saving, and then you are not consuming your transactional resource units on your Microsoft Azure Cosmos DB containers doing those analytical queries. That is another way to save a lot of money. If done properly and using the available features, Microsoft Azure Cosmos DB can decrease the total cost of ownership.

I would rate Microsoft Azure Cosmos DB a ten out of ten.

It has not been a direct approach for me because all of my enterprise-level applications are deployed in MongoDB. At some point, we usually face issues where we need multi-directional and different contexts to connect with the database. Sometimes we use SQL and need to retrieve data from the database. If using a typical MongoDB, this is not possible. Microsoft Azure Cosmos DB has bidirectional support for cross-platform connections, so we don't need to recreate our entire database structure in our application. We can work with the MongoDB driver and interact with Microsoft Azure Cosmos DB. The applications under my portfolio currently rely on that, mostly indirectly. We created the models, deployed our data, migrated it, and are using it heavily in Microsoft Azure Cosmos DB. 

Recently, we are building an AI-powered application where we heavily rely on Microsoft Azure Cosmos DB to bring data from ServiceNow, SAP, Salesforce, Cisco, and other customers we have at our organization. Reading and inserting data into Microsoft Azure Cosmos DB is a very smooth process.

Its scalability is great. Microsoft Azure Cosmos DB offers auto-scaling both horizontally and vertically. We haven't faced any issues.

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.

Its scalability is good and depends on the traffic, with auto-scaling functionality ensuring we don't need to worry about database crashes or data loss during insertion. These problems were common when deploying our data on-premises. With Microsoft Azure Cosmos DB, we have overcome those struggles and are now operating smoothly.

It depends on the application. In some cases, we use Microsoft Azure Cosmos DB directly with Azure Functions to store customer details and manage the customer onboarding process through our enterprise applications. In several instances, operations happen directly with Microsoft Azure Cosmos DB.

For legacy applications built on MongoDB that need to transition to Microsoft Azure Cosmos DB, we take a different approach. If a company is migrating from on-premises systems to the cloud—whether it’s Microsoft Azure or AWS—sometimes it’s necessary to adopt different tools for the billing process and other infrastructural needs. In such cases, we may choose to use Microsoft Azure Cosmos DB to avoid having to restructure our entire legacy application. In these situations, we utilize MongoDB and its drivers as a mediator. These drivers interact with Microsoft Azure Cosmos DB to perform the necessary operations within the application.

On another note, when using Azure Functions, we typically handle cases such as creating, updating, or retrieving customer details. This process directly connects Azure Functions to Microsoft Azure Cosmos DB. Currently, we are managing these two different patterns effectively.

If you are an engineer with good experience in microservices and the Azure platform services, it's a one-day setup process, based on requirements. If you are new to the entire Azure platform and services, it can be a bottleneck. It takes time to understand the configurations and related aspects. If you're new, there is a learning curve. You need to understand which version you're using, what features are supported fully or partially, and which features are not supported. For example, when using MongoDB drivers to interact with Microsoft Azure Cosmos DB, understanding which version (4.1, 4.2, or 4.3) you're using and what features are supported by Microsoft Azure Cosmos DB for that particular version is important. Understanding query performance improvements based on supported features is crucial. For newcomers, it might take several days to understand and review documentation. For mid-level engineers with two or three years of experience, it's a straightforward, one-day process.

Pricing is a complex process at the enterprise level. While I'm not handling the pricing directly, through stakeholder meetings and conversations, we understood that having everything in a single platform with billing up and running for all required application services is beneficial. Microsoft Azure Cosmos DB comes into a single billing system for gold or silver partners, though I'm not familiar with specific company policies and terms and conditions as I'm not an infrastructure specialist.

I would rate Microsoft Azure Cosmos DB an eight out of ten.

We use Microsoft Azure Cosmos DB as a NoSQL database to store JSON documents for our clients in the Banking, Financial Services, and Insurance sectors, primarily insurance. They require storage for numerous documents, including policy, claims, and costing documents, making Cosmos DB the ideal solution.

Because the company is spread across multiple regions, maintaining consistency with traditional relational databases was a challenge. Cosmos DB solved this by offering various consistency options and geo-replication capabilities. Logical partitioning within Cosmos DB improved routing efficiency, and composite indexes, combined with the partition key, optimized query execution by directing requests to specific documents, minimizing resource consumption.

Cosmos DB can offer faster data retrieval than SQL for certain queries and workloads, particularly those involving large volumes of unstructured or semi-structured data.

Cosmos DB is highly capable of handling large workloads and offers exceptional reliability for document storage and similar needs. Its particular strength lies in-stream analytics, a functionality currently not supported by MongoDB. This makes Cosmos DB the ideal solution for customers requiring real-time data processing, and it is our consistent recommendation for those working with stream analytics.

I appreciate Microsoft Azure Cosmos DB's robust document management and consistent availability. The databases are always operational, ensuring continuous accessibility and simplifying disaster recovery procedures. The geo-redundancy feature is particularly valuable, especially for European operations.

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.

I have been using Microsoft Azure Cosmos DB for more than four years now.

Microsoft Azure Cosmos DB offers exceptional stability, boasting a reliability rating of 99.95 percent. This ensures continuous availability without downtime.

I rate the scalability of Cosmos DB highly, with a score of nine point five out of ten.

Microsoft's support services are inadequate, especially during critical incidents. The faster response times found in community-driven resources, such as Stack Overflow, underscore the shortcomings of Microsoft's customer support.

Negative

While Amazon DynamoDB offers extensive configurability, this can be time-consuming. For projects with tight deadlines requiring a NoSQL database, Cosmos DB is a preferable choice due to its ease of setup and minimal configuration. Additionally, Cosmos DB provides superior support for the Jira application and offers better uptime than DynamoDB.

The provided templates help us deploy Cosmos DB quickly.

Cosmos DB's billing is based on request units, which isn't ideal for all clients. Pricing plans offering set benefits, similar to Azure's platform resources, could be beneficial. The current method lacks clarity for clients new to cloud-native architectures, hindering migration from on-premises systems.

Billing is based on request units, so it's crucial to optimize queries to minimize consumption. A standard estimate is one to one point five request units for read requests and four to five for insert, update, or delete operations.

I would rate Cosmos DB's cost at seven out of ten, with ten being the highest.

Cosmos DB can provide improved search result quality, but we must understand the partition key of our container. Using the correct partition key in our queries ensures precise results. Without it, queries may consume excessive Request Units of over 5,000 and ultimately fail.

Microsoft Azure Cosmos DB is a strong product with the potential for improvement in supporting joins from different containers and providing more stable pricing plans. Despite these areas for growth, Cosmos effectively competes with services like AWS DynamoDB and currently leads the market. Overall, I rate the solution an eight out of ten.

Our Cosmos DB deployment spans across Europe, with the primary data center located in Italy to serve our European users. Additionally, we have another customer based in the eastern US, where their data is replicated across three data centers in the eastern US and three more in the western US for redundancy and high availability. We currently have 40 projects using Cosmos DB for clients in different industries ranging from oil and natural gas to sports and media.

We use Azure WebJobs to maintain our databases by removing expired policies and contracts. However, Microsoft should implement a similar system in Cosmos DB, utilizing its Hot and Cold Tier functionality for archival storage. This would allow us to efficiently move outdated data to archival storage, mirroring the functionality we have with Azure WebJobs.