Microsoft Azure Cosmos DB Reviews

We use Microsoft Azure Cosmos DB for one workload, which is a recent implementation. Microsoft Azure Cosmos DB has two use cases: storing unstructured documents and serving as a vector DB for AI purposes. We utilize Microsoft Azure Cosmos DB as a vector DB. In our company, we implement RAG (Retrieval-Augmented Generation) implementation of AI. In RAG implementation, we must chunk and store vectors in databases, so for our workload with RAG, we use Microsoft Azure Cosmos DB as a vector DB to store chunks. We have used the vector database with Azure AI services in our RAG applications.

Microsoft Azure Cosmos DB is not complicated to use; it's very user-friendly. The engine is approachable, and it's straightforward to implement, manage, and migrate. Microsoft Azure Cosmos DB improves reliability through replication in many regions in Azure. MongoDB, for comparison, is more complicated for replicating all clusters worldwide.

Microsoft Azure Cosmos DB is simple in many tasks, and for application performance, we can set many models for scaling, autoscaling, and pay-as-you-go models. We are more efficient with these features. The best feature of Microsoft Azure Cosmos DB is the replication all over the world. The second notable feature is the simplicity of deployment.

Microsoft Azure Cosmos DB is a good general-purpose database with low cost. For our little workload, it's very interesting to work with Microsoft Azure Cosmos DB. The ability to deploy a world-replicated Microsoft Azure Cosmos DB is very efficient in terms of cost.

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.

We have been using Microsoft Azure Cosmos DB for three months in deployment.

Microsoft Azure Cosmos DB has good scalability. We use autoscaled models which work well for our needs. The system allows setting a range of RU, starting RU, and max RU, with autoscale triggering between these two values. The scalability functionality is satisfactory for Microsoft Azure Cosmos DB.

Technical support in Microsoft Azure Cosmos DB is good. We haven't opened many tickets in support, except one ticket for migration of Microsoft Azure Cosmos DB to another subscription. We experienced some problems with slow transfer during this process. The support provided for this issue was helpful.

I used MongoDB before Microsoft Azure Cosmos DB.

The switch to Microsoft Azure Cosmos DB was simple using the MongoDB plugin.

Microsoft Azure Cosmos DB is a good general-purpose database with low cost. For our little workload, monthly consumption costs about 20 to 25 dollars. For a big initiative, it costs approximately 300 dollars. In comparison, MongoDB deployed in Azure has an initial price of 100 dollars just for support, before computing and storage costs. Microsoft Azure Cosmos DB provides excellent value, particularly for smaller workloads.

Microsoft Azure Cosmos DB can be used to store unstructured documents and serves as a vector DB for AI purposes. The onboarding process took approximately three months with the plugin, which is relatively quick. While all our workloads originally worked with MongoDB, Microsoft Azure Cosmos DB's MongoDB plugin driver makes the transition transparent for developers. This results in a short onboarding time in this context. 

On a scale of 1-10, this solution receives a rating of 8.

Our primary use case for Microsoft Azure Cosmos DB is as a solution for customers who are not necessarily migrating an existing application but are looking to build something more cloud-ready and scalable. The objective is to provide a scalable and flexible database solution that does not require the compatibility requirements of Azure SQL, allowing for fast data access across regions without latency concerns. They are not looking for all the compatibility requirements for Azure SQL, but they are looking for something that they can scale quickly without latency.

I found Cosmos DB to be rather intuitive and straightforward. The documentation is pretty clear because it is a managed service. I could give the custom developers their endpoint and even set up managed identity in a way where we do not have to worry about having secret keys and all of those pieces. We are using private endpoints for everything and found it to be working just as advertised.

The most valuable features include the global write capability, which allows customers to read and write across different regions simultaneously, enhancing performance and availability. 

A lot of my customers like the ability to choose a different API with which they are familiar. The flexibility to choose different APIs, such as MongoDB or Cassandra, allows customers to leverage their existing knowledge while using Microsoft Azure Cosmos DB. 

We are using the vector database a little bit. We often use Azure AI search for that capability. We have an application that is taking in legal documents and needs to do a semantic search against those. It is a combination of using the embedding models and vectorization to get closer to the right chunks of the documents that they are looking for. We, in turn, send that over to Azure OpenAI services to fine-tune and get the best result from our initial results.

We integrate the vector database with another application. It is a custom-built homegrown application that provides a UI for their end-users to be able to use AI search and vector search to be able to get highlighted results of their PDFs.

The vector database absolutely improved the search result quality of our customer's organization. They are partially using Microsoft Azure Cosmos DB in that, but, in general, the two combined absolutely did help by not defaulting only to keyword search and being able to do a hybrid between the two.

For this project, there has been significant improvement in the time to process these documents. There has been a 5x time reduction for the end users in finding the data they are looking for, inputting it into their model, and performing their workflow.

In terms of Microsoft Azure Cosmos DB’s ability to search through large amounts of data, for this specific use case, we are probably on the low end of what Microsoft Azure Cosmos DB can accomplish. We have a decent dataset, but definitely not a gigantic one. So far, our experience has been great, but we are not necessarily testing it to its limits. The one that we are working on is still under a terabyte. We only have several hundred gigabytes for this specific customer. It is a lot of data, but in the grand scheme of things, it is not very much.

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.

I have been using Microsoft Azure Cosmos DB for around a year to a year and a half.

The latency and availability of Microsoft Azure Cosmos DB are fantastic. It provides resiliency and business continuity without having to do much. Having it already built in is a big selling point.

I am not working with any customers who are going to have any problems with scalability. We are not going to push the limits of what it can do. My customer base does not have to worry about scaling because none of their applications are ever going to struggle with something as global and as resilient as Microsoft Azure Cosmos DB.

Microsoft Azure Cosmos DB’s dynamic scaling helped decrease the overhead costs for our customers. They have spikes, but most of the time, they have a pretty low baseline. Rather than overprovisioning to handle those spikes, they are able to settle in and ride the waves of their utilization throughout the days and weeks. They have seen a decrease in costs and expenditures. It is still early for a lot of it because a lot of new functionality was added. They did not necessarily have a true baseline to compare against, but they like the idea that it is so elastic.

The onboarding process was relatively quick, taking about six to eight weeks, as the team adjusted to using Microsoft Azure Cosmos DB.

We have not run into many challenges during the migration or implementation of Microsoft Azure Cosmos DB other than being novices and unfamiliar with it. We need to understand all the different components of it, but we have not necessarily run into any technical problems or issues with timelines or things like that.

It takes only a couple of months to onboard customers with Microsoft Azure Cosmos DB. We are able to go pretty quickly. Our onboarding path is about six or eight weeks.

There is a bit of a learning curve for the customers who have only worked with traditional Azure SQL VMs and are not familiar with having a fully managed or PaaS instance. There is some learning curve for them to understand that they do not just have x number of cores or memory available, and it just grows as they use it.

In a couple of use cases, Microsoft Azure Cosmos DB helped decrease an organization’s total cost of ownership. Oftentimes, when we are implementing some of these features, we do not have a baseline to compare against. In my own experience, there definitely is an opportunity if we are able to use the model to reduce cost instead of provisioning a VM or something like that, as we would historically do. It is hard to provide metrics, but when I have done comparisons or cost calculations, I have sometimes personally seen as much as 25% to 30% savings.

Most customers like the flexibility of the pricing model, and it has not been an issue. They can start small, and the cost grows with adoption, allowing efficient management of the budget. Its pricing model has not been a concern at all for any of our customers. They understand it. It is simple enough to understand. Oftentimes, it is hard to forecast the RUs, but, in general, it has been fine.

I would rate Microsoft Azure Cosmos DB a nine out of ten. There is always room to grow, but it is a highly capable solution. I am looking for more opportunities to use it as we help customers move toward more cloud-native technologies, rather than always defaulting back to what they are familiar with, which is sticking with Microsoft SQL Server or Azure SQL.

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.

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 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.

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.

I have been working with Microsoft Azure Cosmos DB for approximately two years across seven projects. I started by creating basic containers at the free tier level that Azure provides, and when requirements grew, I moved them to the paid version. Azure typically provides two containers for free, after which you need to upgrade to the paid version. Of the seven projects, five were small projects and two were mid-sized projects. We created approximately 20-30 containers in total.

It works similarly to MongoDB when using NoSQL. When deploying on Azure, the communication is rather easy without many steps and complications, though this is more a benefit of Azure rather than Microsoft Azure Cosmos DB specifically. The queries take a similar amount of time compared to other databases, but the database management system provides a better-looking UI for viewing data compared to other solutions. 

The queries in Microsoft Azure Cosmos DB are faster when trying to fetch specific fields from JSON or run particular queries on a container.

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.

I have been using Microsoft Azure Cosmos DB for approximately two years.

Lag only occurs when different resources are set up at different locations. When all resources are at the same point, there is no lag. In production, we have experienced minimal issues. The project has been live for two years without any database problems. We decreased the timeout for connections and queries to two seconds, and it works efficiently. Our project remains at mid-scale without requiring a load balancer at the Microsoft Azure Cosmos DB level.

Given the RU size, it can scale up significantly. If the user base increases, increasing RUs to handle more database calls is not problematic. Azure has done an excellent job making everything more scalable, including Microsoft Azure Cosmos DB. The plans allow for easy upgrades based on user growth, supporting parallel queries and increased call volumes. You can move to a better plan if you are going to have more users.

The response time you experience mostly depends on the specific service you are using. For instance, For Azure AD-related issues, their support was quite fast and effective. However, with Azure AI speech service, I faced some challenges. They didn't provide a precise answer to my issue, but they did share some documents for reference. It took about 48 hours for them to respond, and even then, the solution they offered wasn't exactly what I needed.

On the other hand, my experience with Azure Cosmos DB was more positive. I had a specific inquiry regarding partitioning, and their support team was helpful. One representative reached out to me, and we discussed the issue. They were able to guide me in implementing different hierarchical IDs to structure the data better. Our goal was to optimize our queries and reduce API calls. Overall, their response took around seven to eight hours, and I felt they effectively resolved my concerns.

Overall, I would rate their support an eight out of ten. Specifically, if I focus on .NET, I find their support to be excellent. However, for other services, such as Azure reports, there are still issues that prevent me from giving a higher score, so in those cases, I would rate it a seven.

Positive

I previously used MongoDB. The choice depends on requirements. Microsoft Azure Cosmos DB is optimal for simpler structures with fewer containers and less complex data partitioning, offering faster queries. For more complex database structures, MongoDB might be preferable. However, when using other Azure services and hosting on Azure, Microsoft Azure Cosmos DB works best. The choice ultimately depends on the entire application architecture and hosting environment.

The onboarding process and learning to run queries is straightforward. It requires only a connection string for the database and container name to run queries. Migration from SQL to NoSQL is relatively simple due to easy syntax and connection process. The initial setup took approximately 5 minutes using the emulator on the local machine, and the Azure subscription setup required only about a minute. An API was used to create all containers efficiently.

The pricing is calculated per query with specific calculations, though I cannot provide detailed information about this aspect.

I have worked with Azure AI services including translation, transcription, and speech synthesis. We used Microsoft Azure Cosmos DB for storing links to storage accounts for AI-generated data, utilizing NoSQL queries for data retrieval. Azure AI services can be somewhat challenging to integrate, in my opinion. I find that integrating Microsoft APIs is generally harder compared to others. In this case, we weren't using the Vector DB explicitly; instead, we utilized Microsoft Azure Cosmos DB. We relied on standard containers, and I believe we had about seven or eight containers in total.

We generated our data using AI services and then stored it in these containers. The links to specific storage accounts for each request were saved in Cosmos DB. When we needed to retrieve that information, we used queries to fetch the data.

In a banking project, we used the Vector DB capabilities of Microsoft Azure Cosmos DB, though limitations were due to our API standards rather than database limitations. The team later discovered and implemented the inbuilt vector DB features when the database grew.

Overall, I would rate it a nine out of ten with the only significant issue being the partitioning key functionality. It's a good alternative to other NoSQL databases.

We mainly use Azure Cosmos DB across different projects in our service-based organization. It has been consistently used in projects that require maintaining and creating NoSQL databases. Our team leverages Azure Cosmos DB for these needs.

Azure Cosmos DB is efficient and manageable. These are the advantages of Azure Cosmos DB.

There is a lot of reusability. For instance, for integration, we can copy code snippets, and the connection is taken care of from Azure itself. Creating connections from an application to the database is easy. Doing recalls and running some queries is easy. We did not have any trouble integrating with applications. The only challenge was to apply the search over the large database in real time.

Our use case required minimal usage of the vector database, but there are a lot of personalization opportunities when it comes to the vector database. We can create as many vector embeddings as we want and customize the structure. There are no rigid rules about the structure. It is customizable. It is also AI-driven, so there are enhanced search capabilities. In terms of relevance or context of search, it is quite good to use a vector database over other databases. 

Scaling is very easy. With other databases, we have to take care of a lot of things, such as schemas and how things will transform, whereas with vector databases, scaling is hassle-free. We do not have to worry about a lot of parameters.

With Azure, resource usage is always optimized. Azure automatically takes care of a lot of things. There are many features. It can autoscale and has efficient indexing. You get asset transaction capability as well. 

The latency is quite low when it comes to search. Searching is very easy, fast, and efficient. Using vector databases means that we want to search for specific parameters.

Azure Cosmos DB offers numerous data connectors that provide a platform for seamless integration with various platforms and visualization tools such as Power BI. It allows connection via multiple data connectors to integrate data in any desired format. 

Additionally, its distribution and low latency features are beneficial. We do not need to rewrite things. We can copy a schema from a template.

It offers efficient indexing and low search latency, making searching fast and efficient and ensuring peace of mind in database operations.

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.

We have been using Azure Cosmos DB for the last 12 months.

Azure Cosmos DB provides low latency and reliable availability. As long as instances and databases are configured correctly, stability issues are unlikely. Azure Cosmos DB would be a good choice if you have to deploy your application in a limited time frame and you want to auto-scale the database across different applications. From the availability and latency point of view, Azure Cosmos DB is good.

Scaling workloads with Azure Cosmos DB is straightforward. It has auto-scaling and global distribution features for handling dynamic, high-demand workloads. You just need to configure it correctly. 

It has a feature for multi-region scaling to scale across different regions or applications. You can also conduct horizontal partitioning. You can distribute the data across multiple partitions depending on your use cases. Handling workloads is easy.

Personally, I have not needed to contact technical support. The Azure Cosmos DB community and forums have been helpful in finding solutions without requiring direct support.

Neutral

I have used MongoDB for personal projects, but professionally, I have only used Azure Cosmos DB due to project dependencies.

Setting up Azure Cosmos DB initially was easy. We were able to deploy effectively while ensuring continuous operation and handling transaction queries without failures within one or two days.

It took us some time to realize the benefits of Azure Cosmos DB because when the platform went live, we were using it in-house and had a team of three to four people. The search quality was efficient and it ran fantastically in a small test case. After that, we rolled it out to a larger audience. We took the feedback. People liked the quality and relevance of the search. The quality of concurrent searches was also good. Over a period of one month, we observed the performance and found it to be performing well. We knew we would not have any problems from an infrastructure standpoint.

Its maintenance is quite easy. I have not faced an issue with that. Sharing it across user groups is also easy.

We formed a team and took about four to five days to become familiar with Azure Cosmos DB, given our experience in infrastructure and databases. We were able to work on our use cases within a week. 

Azure Cosmos DB's pricing is competitive, though there is a need for more personalized pricing models to accommodate small applications without incurring high charges. A suggestion is to implement dynamically adjustable pricing that accounts for various user needs. There should be smaller subscription options or a lighter version with a limited set of features for small applications.

Its learning curve is a little bit steep for those who are new. If you have a little bit of experience in infrastructure and databases, becoming familiar with Azure Cosmos DB does not take much time. 

It is easy to use if you have knowledge of NoSQL databases in general. If you know how to create schemas, then setting up the infrastructure in Azure Cosmos DB is no hassle. The basic requirement is to know about databases. That is it. Many things are managed by default in the Azure platform. You just need to take care of the specifics of your project and the regions you will be working in. These are the things that are automatic in Azure Cosmos DB.

I would rate Azure Cosmos DB a seven out of ten, considering its ease of use, efficiency, and provision for peace of mind through its features and functionalities. There is still room for improvement, particularly in pricing and feature offerings.

The use case for Microsoft Azure Cosmos DB is that some of the data we have is too large for the SQL database, but we want to be able to access it in a timely manner. I appreciate the ability to use the SQL language through a Linq type query. 

Microsoft Azure Cosmos DB helped improve our organization's search result quality significantly when we started using it about eight years ago. It greatly improved things at that time. We moved to Microsoft Azure Cosmos DB, we were in a round of product development for one particular product. Moving to Microsoft Azure Cosmos DB improved things substantially. We have been using it since then, so it could not improve anything further because we design and build our own Vector Analytics solutions.

Some of the best features of Microsoft Azure Cosmos DB are that it could scale, and we could still use SQL language through a Linq type query. 

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.

I have dealt with Microsoft Azure Cosmos DB for eight years.

Microsoft Azure Cosmos DB is stable. We did not really have any problems with Microsoft Azure Cosmos DB for the whole eight years.

Regarding latency and availability with Microsoft Azure Cosmos DB, I did not really have a problem compared to other document databases. Compared to other Mongo-style databases, it is not any slower than the rest of them.

The scalability of Microsoft Azure Cosmos DB is fine; we did not scale to Salesforce levels. Our solution was not on that type of scale. 

The environment we are using Microsoft Azure Cosmos DB in involves thousands of devices and different customers across the country. Although we did not face any issues with Microsoft Azure Cosmos DB, our Cosmos operation wasn't complex; the only issues we faced were somewhere else within Azure.

Unranked, because we don't use it, except for the training materials.

Neutral

For the last year or so, we have been moving all of our data out of Microsoft Azure Cosmos DB into RavenDB, and we have plans for a couple of other types of databases too, so we will not be using Microsoft Azure Cosmos DB in the future. The cost is a concern, as we desire to be more agnostic and not just stuck in the Microsoft frame.

The initial setup was pretty simple for me. It took the development team a couple of months to get the UI squared away, but I had already been using SQL. They made it easy for people that were pretty good with SQL, so I did not have a problem with it.

There were six people in the development team that deployed Microsoft Azure Cosmos DB. Some of their job roles included the principal engineer, two UI developers, API developers, and DevOps development.

It's expensive. I would rate it a five out of ten for pricing.

We are still in the process of moving, so we are not completely sold on RavenDB. I have just used it more in the last couple of years than anything else, but things are changing fast. I have looked into Postgres, time series databases, and others, and I have looked into graph databases as well. I do not know if we are going to use one, but they are definitely impressive. We have to prepare for scale, but we do not have to have it to be successful, so I have looked at Apache Ignite, as well as adding open-source pub/sub on top of Postgres, and I have looked at Couch and Mongo, though we are not going to use those.

Microsoft Azure Cosmos DB is pretty easy to use compared to other document database types out there, but I prefer RavenDB more. RavenDB has better automated indexing that makes things really nice. With Microsoft Azure Cosmos DB and RavenDB, the main differences are that with RavenDB, I can move completely off and just use RavenDB while still having SQL type, relational capabilities, whereas with Microsoft Azure Cosmos DB and other document DBs, we are not really getting that. RavenDB is a great solution; it can also have costs that can get out of control, but it has built-in ETL and time series features for your vector analytics, and its automated indexing means it indexes as well as any SQL database without manual work, although you could do it manually if you wanted. Whatever combination of solutions I end up with is going to give me those opportunities as well as having the pub/sub capability, which I do not think Microsoft Azure Cosmos DB has. We never used it if it did.

I did not use Microsoft Azure Cosmos DB with Azure AI services. The core thing is that I did not want to use any Microsoft products. 

I would rate Microsoft Azure Cosmos DB a seven out of ten. It is better than MongoDB and Couch, but not as good as RavenDB.

I have three different products using Azure Cosmos DB. The most extensive use is in a survey platform we are developing as a SaaS product. Azure Cosmos DB serves as the primary OLTP database for this platform. We do not have any other RDBMS for this use case.

We also use it to store configuration information for campaigns for the other two products, but it is used extensively for the survey platform.

Azure Cosmos DB offers horizontal scalability, making it easy and cost-effective without additional effort from a DBA or DevOps team. Configuration for scaling is user-friendly through the UI.

It is easy to use and optimize once you understand the basics, partitions, and indexing. By default, it indexes every field and attribute, but you can customize it. The documentation is good. It makes logical sense. I have had some experience with other NoSQL solutions. It is easy to use. We do not find anything challenging. The way it indexes and does the filtering of data is easy.

The fact that scalability can be achieved by simply configuring availability zones is very attractive. We aimed to avoid managing a NoSQL database, especially when we did not have an upper limit on how much audio we would need while doing the initial development. The ability to easily scale with the increase in usage and adoption of our product is the most valued feature.

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.

I have been using Azure Cosmos DB extensively for the last four years. Before that, it was more of hobby research.

We have an account manager. We reach out to that account manager wherever we need level 2 or level 3 support. We have also followed the normal process of raising a ticket, but sometimes, it helps to speed up the process.

Ordinary issues are resolved through standard processes, but for complex matters, we leverage our account manager to access senior engineers. We have received great support. Support has been responsive and effective. I am very happy with their support.

Positive

We have not replaced any solution with Azure Cosmos DB for this use case, but we have used MongoDB, Elastic, and other NoSQL databases.

Almost anything that you can do in Azure Cosmos DB can also be done in MongoDB, but one of the things that I like about Azure Cosmos DB is called change detection. Changes in each document can be persisted in some other technologies. It could be in fabric or SQL Server. This feature gives Azure Cosmos DB an edge over others in use cases where you need to detect a change and then connect it with other things. I also like the functions and stored procedures that Microsoft has implemented in Azure Cosmos DB, but the change detection feature is probably one of the best features. It works natively within the platform and Azure.

The initial setup is very easy and seamless. An instance can be deployed in minutes, and the UI allows for easy configuration and scaling without disrupting operations.

I recently needed to upgrade an Azure Cosmos DB instance. In the UI, I clicked the option to scale it higher. It said that it could take a couple of hours. I thought it would take four or five hours, but it finished in two or three hours and notified me when the upgrade was completed. All this while, things were working and operational, and behind the scenes, it was upgrading to a bigger instance. It finished the upgrade in half the time. It can spin up a small instance in just a few minutes.

It took us about two weeks to do the PoC to make sure that Azure Cosmos DB was the right one for our use case. After the PoC, we started leveraging Azure Cosmos DB within a month. Our use cases have become more and more sophisticated because we are still developing software, which requires us to create different documents and different structures of those documents in Azure Cosmos DB. The onboarding itself was simple and natural. We did not feel that using Azure Cosmos DB slowed us. In fact, it was seamless because the JSON that our APIs needed could directly be persisted in Azure Cosmos DB. No other transformation was needed.

Its learning curve is small. It is easy to learn. The documentation of Azure Cosmos DB is good.

It does not require any maintenance, but a couple of times, we had to change our partition scheme and write a separate utility to transition from one partition scheme to the other. It was more of a migration that we had to do of the Azure Cosmos DB document that we had created. Because we changed the partitioning scheme, we had to migrate the old data to the new partition design. Azure Cosmos DB does not require any maintenance work. That is the beauty of how NoSQL, and Azure Cosmos DB in particular, have been designed.

All implementations were done in-house without any external consultants. It is a one-person job.

The horizontal scalability helps lower the overall cost of ownership as compared to managing MongoDB or any RDBMS solution. Because of its ease of use and the fact that the scaling, configuration, and backup are managed in Azure, we do not need a dedicated DBA. We do not even need the DevOps people to manage it.

The management of Azure Cosmos DB is easy because of the UI and the way it scales. We have availability zones and multi-region load balancing. When you take all that into consideration, the total cost of ownership is much lower than others.

Azure Cosmos DB is costly, especially if you have not optimized it. However, we are very satisfied with it. It provides the value for what we are paying.

Its price is very good for the basic stuff. When you go to a more complicated use case, especially when you need replication and availability zones, it gets a little costly.

It represents the biggest cost item for us. However, the cost is aligned with the value provided. It has served our needs perfectly, aligning with our scaling and development requirements, so the cost of ownership seems justified.

We did a number of PoCs to decide which NoSQL database to use, and we settled on Azure Cosmos DB. We could see its benefits when we incorporated the partition key with indexing. The performance started improving when our engineers started exploring some of the complex concepts.

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