Microsoft Azure Cosmos DB Reviews

We have a very large team of developers who develop a solution for our customers. In the part where they need some infrastructure on Microsoft Azure, we deploy entire environments of different types such as development, testing, production, and pre-production to Microsoft Azure and configure it, monitoring that infrastructure, one of them being Microsoft Azure Cosmos DB. Later, we hand over those resources to our development team and they can start to use it.

For example, we have one application which is for one of our post offices where they host their main application for tracking packages, for sending packages, and for everything they provide to their customers. The main database for this solution is Microsoft Azure Cosmos DB.

In production, we definitely are using automatic scaling because of the workload, since some days there is a workload which is very high and some days it is not so high. For non-production environments, it's a minimal setup with minimal SKU on Microsoft Azure.

Availability is for sure better with Microsoft Azure Cosmos DB, but it's also the biggest cost for that setup. We are a very small country from Slovenia, so our customers don't require so much high availability for their applications. This leads us to set up resources only in one region for most of them, while for the most critical workloads, such as those from banks, we use the multi-region setup and auto-scaling.

About the performance, I monitor everything that's going on, what is possible on the resource level in Microsoft Azure, and we also do the FinOps solutions for our customers, utilizing different metrics to optimize resources and the entire setup.

Overall, I think Microsoft Azure Cosmos DB works fine. I don't remember any case where our developers or our clients have been disappointed with it.

The benefits we and our clients have seen from using Microsoft Azure Cosmos DB are similar to those most platform-as-a-service solutions provide, where you don't need to take care of the underlying infrastructure, which is the main reason.

I have not utilized Microsoft Azure Cosmos DB multi-model support for handling diverse data types.

I'm not in the position to decide if clients will use Microsoft Azure Cosmos DB or any other database. However, I notice that there is more and more Microsoft Azure Cosmos DB setups in different applications.

The only problem I face is more with infrastructure as code templates that don't cover everything that can be set up or configured on the portal, requiring some manual work which is additional work for us. Some resource providers don't provide certain configurations, which I think is on Microsoft's side because they need to change Azure Resource Manager and the version of templates. Other aspects involve different providers for those templates including Azure Verified Modules with pre-configured templates on the community and the team working on them.

I have been using or working with Microsoft Azure Cosmos DB for the last year and a half.

I usually use Microsoft support, and I would evaluate them around one to ten as very bad for the first level. They have some instructions and procedures they follow without listening to customers, primarily seeking to get their checkboxes rather than fully understanding the customer's needs. However, upon reaching the product group or a higher level, the support was great. I currently have one critical ticket open for another solution and it has been handled excellently.

Based on my experience with Microsoft support, I would rate them around eight on a scale of one to ten. To make it a ten for me, they need to listen to customers more instead of just going through their automatic process.

Our clients see metrics in terms of ROI after some time, but not at the beginning. They usually observe cost saving and time saving post-optimization when we find the right SKUs because most of the time, they don't know what they need regarding the required SKU or size of some resources. After time, for sure, they see ROI.

On average, the kind of savings we see ranges from 15 to 25 percent. The savings I refer to are in money saving.

In my opinion, the main difference between Microsoft Azure Cosmos DB and other types of databases is hard to say. It's mostly how developers see everything, as it depends more on the development side—what they want to use and what features they need, such as relational databases or document databases. This leads us to select the right database based on those inputs. The selection is based on the use case.

We are implementing other Microsoft Azure solutions like Azure SQL and Postgres. We focus only on Microsoft Azure and do not work with other vendors like AWS. I gave this review a rating of ten out of ten.

Azure Cosmos DB is our database of choice for new applications and cloud-native applications. I use it anywhere.

Because it is NoSQL, it has the capability to adapt to changes. As compared to Azure SQL or other SQL databases, Azure Cosmos DB is schema-less. We can add new columns anytime, and the application will not break. It is very efficient for application-facing scenarios.

The most valuable feature of Azure Cosmos DB is its scalability. That is the biggest reason I use Azure Cosmos DB.

I also like its developer-friendliness. It is very easy to begin with. Microsoft and Azure are good with that. With all the getting started information and all the introductions, it is very easy to begin with. Optimization is where it gets a bit trickier. That is where you need to be more active and understand why things are not performing as they used to. Most of the time, performance is not a problem. It is always fast. The problem is more around the cost consequence of that performance.

Its vector capabilities are new. They were implemented just months ago. There are probably three things that we were looking to address by using the vector database. The number one is the cost of Azure AI search and indexing. Before this feature came out in Azure Cosmos DB, the alternative for me was using AI search, which is way more expensive if using it as a vector database. Now with Azure Cosmos DB, that price point becomes much more accessible. That is number one. 

Number two is the developer familiarity aspect of things. AI search is more around enterprise use cases or enterprise search and requires more specialized skills to begin with, whereas Azure Cosmos DB is more or less a commoditized developer platform that is much more accessible to a wider developer audience. That is another aspect that it has addressed. For example, if I have a new starter in my team, it is easier to train that person on Azure Cosmos DB than the AI search. With the explosion of LLMs, AI agents, and things like that, the vector database on Azure Cosmos DB is a good place for developer onboarding. It is just way easier. 

The third part is still related to the developer experience, but in terms of the SDK aspect, the libraries available for Azure Cosmos DB are already well-established in the ecosystem. With the vector database capability, it is just a matter of adding an extension of those existing libraries. That means if the applications that are already using Azure Cosmos DB want to jump to the vector database, the jump would not be that big. It is just a matter of implementing it directly with their existing Azure Cosmos DB that they are already using.

We have used the vector database with Azure AI services. The other aspect is using the vector database with document intelligence. We use document intelligence to process a raw PDF document and things like that. From there, we convert that into embeddings, and then those embeddings will be stored in the vector database. It is something we use as a landing spot for new LLM applications.

The quality has improved because, traditionally, we did things in batches. We processed documents once a day or every twelve hours or so. With this new capability, we are very confident to run those processes in real-time. As new documents come in, the process and the workflow can get triggered. It is not a batch anymore. It is in real-time.

Azure Cosmos DB’s ability to search through large amounts of data is yet to be determined. Large is subjective at the moment. I have only tested it up to 2 gigabytes, and for that, it is working pretty well.

Azure Cosmos DB is our default. We do not question it anymore. After migrating out applications from an SQL database to Azure Cosmos DB, the change in the organization is massive. Especially on the application side of things, app developers are much more productive and lean. Previously, we had to go through a very rigorous process. To add new columns, tables, and other things, we had to work with DBAs. With Azure Cosmos DB, we can have a PoC and POV in weeks, sometimes days, instead of six months. That is how the whole NoSQL ecosystem changed our life cycle and productivity.

Azure Cosmos DB has changed our total cost of ownership for old applications, but not for new applications. For those who are still using SQL Servers or other databases, there was an added TCO because different projects are using different databases, whereas about 10 or 15 years ago, we had just Oracle, SQL Server, or IBM. For new applications, it is the default for us, so there is no change in TCO.

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

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

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

I have been using Azure Cosmos DB for over a decade. I have been using it since it was announced.

The solution is very stable, and I cannot recall a time when Azure Cosmos DB let us down. I would rate it a ten out of ten for stability. I never had issues with it.

Its scalability deserves a ten out of ten. I have never hit a limit with Azure Cosmos DB.

We have multiple locations and multiple departments. We are in different countries and regions. For our one project, we have multiple Azure Cosmos DBs. We have about seven developers, and we have tens of thousands of users or consumers. Our clients are enterprises and SMCs.

Early on, about a decade ago, when I started with Azure Cosmos DB, I just played with it and created many things. I ended up having a $10,000 bill. Because it was an accident, I had to send a support ticket. The support team was able to waive that cost for me. That left a very good impression on me up until today. I did not have to pay that money, especially when I was just starting. Now, there are very good partners out there, us included, who are well familiar with Azure Cosmos DB. That ecosystem is well supported now. It is not like you are going to a niche database and hoping for the best. That ecosystem is quite mature.

I would rate customer service and support a nine out of ten. The only reason why it is not a ten is because a lot more triaging is required when raising a support ticket. That is the problem I have.

Positive

Before using Azure Cosmos DB, we primarily used MongoDB and Postgres. I have a mixed experience with both of them. There are also Azure flavors of those. You have MongoDB Atlas on Azure and you have Postgres on Azure. That is why sometimes I am very conflicted about which one to use. Both MongoDB and Postgres have captured the audience around the open-source community and the non-Microsoft enterprise or developer ecosystem.

The deployment is a one-off. It is straightforward. For provisioning Azure Cosmos DB, everything is there. It has been straightforward so far.

Its deployment is done in minutes. In terms of maintenance, Azure Cosmos DB itself does not have any maintenance. However, the application that we are supporting and developing needs maintenance. That is it. Azure Cosmos DB does not require migrations like SQL Server where you have to manage a migration from version 17 to 19 and so on.

We achieved a strong return on investment. Using Azure Cosmos DB enabled us to bring a project to the MVP stage in six weeks. With one recent application that we had, if we had gone through another approach, the project could have taken six months in an enterprise setting where everything is slow and challenging. Getting an MVP of that project would have taken six to eight months, but because we had an active choice of using Azure Cosmos DB and other related cloud-native services of Azure, we were able to get to an MVP stage in a matter of weeks, which is six weeks. That was a very measurable impact that we had. If we went another route, just defining the tables, entities, and other things would have taken us a big amount of time. We had already identified base entities. We knew we could add more columns or remove some columns as we went along. That gave the agility to our project.

We do not have to look at it periodically. I do not get support calls that our application is down.

From a startup point of view, it appears to be expensive. If I were to create my startup, it would not have the pricing appeal compared to the competition, such as Supabase. All those other databases are well-advertised by communities. I know there is a free tier with Azure Cosmos DB. It is just not well advertised.

For mid-tier customers, its pricing is justifiable. The enterprise tier is where it is subjective. For organizations that have built a lot of capabilities around SQL Server, Oracle, or so forth, because of the lack of skills, understanding, and capabilities around Azure Cosmos DB, it would appear to be expensive. The professional services aspect of Azure Cosmos DB is what is driving the cost, not the platform itself. The skills required to manage the service can drive up costs more than the platform itself.

I would recommend Azure Cosmos DB for its scalability and performance. Do not be frightened to give it a try. Because there is no local way of doing things, Azure Cosmos DB will always be considered expensive. It is not very developer-friendly when you have to pay upfront, but there is a free tier. Microsoft needs to do better in terms of communicating that it is free to get started.

I would rate Azure Cosmos DB an eight out of ten because of the lack of local development and so on. It also gets confusing with so many APIs. There is a mixed messaging problem around that. The vector database and so on are also confusing. There is a vector database, but depending on which API you choose, there is a different implementation. It is just a bit confusing. I use this every day, so I know it by heart. I know where it is going, but it is just not very easy to get started for others. Messaging and product categorization are not clear. The way they are bundled or packaged is confusing.

Public Cloud

We use Microsoft Azure Cosmos DB mostly for maintaining our user databases in the document databases. Our firm has an app where each individual user's home screen is personalized according to their preferences, web searches, and metadata. For this, we maintain tags, and those tags, associated with each individual customer's mobile number, are stored in Microsoft Azure Cosmos DB to drive personalization and hyper-personalization on the app's home screen.

In terms of how Microsoft Azure Cosmos DB has improved my organization, the latency for API calls is pretty good.

The best features of Microsoft Azure Cosmos DB are the way it maintains the data in partitions and its retention policies. 

Their new feature, dynamic data masking, is very cool and useful for us. 

Since we are one of the largest NBFCs in India, maintaining customer data in a DB, we have to take care of their personal information related to their identity. Microsoft Azure Cosmos DB rolled out this feature about six months ago. Though it's not GA yet, we are running our POC on that feature where you can hit a particular API which Microsoft has provided. Whatever fields you define in JSON, when hitting the API, it will automatically mask all personally identifiable information for each customer in the database. If you have 100 million data points for customers, according to that JSON set of rules, it will automatically mask everything. This is really helpful in our business.

Regarding search capabilities through large amounts of data, Microsoft Azure Cosmos DB performs well when using combinations of primary keys. If we want to search through one of the instances or databases, it works efficiently. The performance largely depends on how optimized your SQL query is and how effectively you use the primary keys.

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

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

I have been using Microsoft Azure Cosmos DB for the past three years since I joined my organization. This is my first organization, and I have been using Microsoft Azure Cosmos DB throughout this period.

In terms of stability for Microsoft Azure Cosmos DB, we sometimes face problems, and I would rate it a seven out of ten. 

There were instances where the DB was not responding, and we lost some part of our business due to that. My impressions of the latency and availability are that most of the time it's up and running. 

Issues typically occur at month-end when the load is measured due to the nature of our business, as we have to process huge chunks of data during that time.

I would rate scalability for Microsoft Azure Cosmos DB as eight out of ten. It's straightforward to scale Microsoft Azure Cosmos DB. You just have to go over the portal and set your configurations for DB or different subscriptions. While scaling is easy, we were facing some stability issues.

Technical support for Microsoft Azure Cosmos DB is great. Recently for the dynamic data masking feature, Microsoft provided us with an entire support team of three or four people who were present in our office. For any doubts or issues, we could approach them directly, and they would raise tickets accordingly. I would rate the support as eight point five to nine out of ten.

Positive

Previously, we were using Postgres for a document DB before switching to Microsoft Azure Cosmos DB, which is also a document DB.

The deployment was good. I was responsible for a few parts of the installation. Microsoft Azure Cosmos DB requires maintenance. The infrastructure team sometimes switches the data center and geolocation. I cannot provide much information about this since I'm not on the infrastructure team. The DB maintenance is handled by their team.

The solution has reduced costs, although not dramatically. The cost reduction is between 6% to 10%. The actual figures in my organization don't flow to my level, but according to my seniors, they were able to save between 6% to 10% after two years of optimization, not year-on-year.

I would recommend Microsoft Azure Cosmos DB to other users due to the latest dynamic data masking feature. If a company's infrastructure primarily uses Azure products, it makes sense to use Microsoft Azure Cosmos DB for better integration. However, if your business requires a very stable DB, you should explore other options as we faced some stability issues.

On a scale of one to ten, I rate Microsoft Azure Cosmos DB a seven overall.

Public Cloud

Microsoft Azure

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.

Public Cloud

Microsoft Azure

We built a chatbot for one of the clients, which is a trading-related chatbot that assists with trading queries. We use Microsoft Azure Cosmos DB to store customer interactions.

It performs very well, especially under high load where it automatically scales up the RUs. The main advantage of Microsoft Azure Cosmos DB is its low latency, with response times in milliseconds, making it great for chatbots.

I am a part of the NLP team. We primarily use Azure Cosmos DB and MongoDB, specifically leveraging their NoSQL capabilities for storing unstructured data, such as JSON formats. This is crucial since we need to access data in milliseconds and handle all operations, including storing, writing, and reading. The client's expectations for response time are quite high. Large Language Models (LLMs) can be time-consuming, so we aim to minimize latency. This serverless architecture helps us significantly in achieving shorter response times compared to other services.

The best features of Microsoft Azure Cosmos DB include its support for asset properties, which makes it more secure and easy to understand. The auto-increment feature is particularly good, and overall, it remains user-friendly and supports multiple SDKs effectively.

Microsoft Azure Cosmos DB demonstrates good capabilities for searching through large amounts of data. It is easy to maintain, offers good quality, and is straightforward to understand and deploy. Its scalability is excellent, supporting all asset properties. 

Microsoft Azure Cosmos DB is quite easy to use. It offers five to six types of inference options such as Python and NodeJS, or REST APIs, and we primarily used Python. Python was very helpful because it is easy to read, easy to understand, easy to implement, and easy to maintain.

The initial deployment of Microsoft Azure Cosmos DB, particularly involving managed identity and service principal, is quite challenging due to insufficient documentation. However, deploying via key access works and is easier. 

I expect improvements in Microsoft Azure Cosmos DB, particularly in the vector database area. In comparison to Databricks, there’s a functionality in Databricks that allows direct updates of the data structure. For instance, we have a use case to display live dashboards to customers where a chatbot is used by around 200 end-user customers concurrently. When wanting to display the queries and responses, along with evaluation metrics, all this information is stored in Microsoft Azure Cosmos DB. However, to show this in real time, we need a live connection that automatically updates in response to new records being inserted. This automated updating feature is lacking in Microsoft Azure Cosmos DB compared to Databricks.

There’s a lack of proper documentation regarding service principals and managed identities, which necessitated referring to various resources to implement these features, making it challenging.

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

I would rate the stability of Microsoft Azure Cosmos DB as eight out of ten. 

I would rate the scalability of Microsoft Azure Cosmos DB as very high, around nine out of ten. One of its best features is the auto-scaling ability, which has no delay. It automatically scales RUs in milliseconds, ensuring a robust security level with Entra ID, managed accesses, and service principals that help with internal products. Utilizing all Azure services with managed access keys provides added security against data leakage, alleviating concerns about key exposure.

I would rate the technical support for Microsoft Azure Cosmos DB an eight out of ten. 

Positive

The initial deployment of Microsoft Azure Cosmos DB, particularly involving managed identity and service, was quite challenging due to insufficient documentation. However, deploying via key access works and is easier.

Onboarding with Microsoft Azure Cosmos DB is straightforward, as the learning process is simple to understand due to comprehensive documentation.

Maintenance is required when using key-based services in Microsoft Azure Cosmos DB. If we use service principals, the maintenance needs are reduced, but some overall maintenance is still necessary. Regular checks are optional for system status, and we prefer to keep resources minimal.

Only one person was required for the deployment of Microsoft Azure Cosmos DB.

In terms of budget, Microsoft Azure Cosmos DB offers multiple selection options from Azure, allowing us to choose services such as auto-scale and select how many RUs we need at any time. We typically recommend going with auto-scale, as it automatically increases RUs during high load and decreases them during low load. 

The pricing is quite competitive, providing some free GBs to practice before implementation, alongside a good backup system. The backup duration is around 90 days, differing based on the tier we select. 

I am not entirely sure about the exact costs. Before presenting the solution to our client, we compared RU costs on Azure and AWS. The client specifically required a secure platform, prompting us to choose service principals, meaning we commit to all Azure services such as Azure OpenAI, Azure Cosmos DB, Azure Applications, Azure Monitor, Azure App Services, and Azure Kubernetes. Overall, we find the storage costs comparatively high. Comparatively, AWS offers similar features, but at a slightly lower cost, and I would rate their support a seven.

We have not used the AWS marketplace for purchasing; we exclusively go with Azure. Upon comparing costs between AWS Cosmos DB and Azure Cosmos DB, the pricing in Azure tends to be higher.

Vector database capabilities exist in Microsoft Azure Cosmos DB. They allow us to store vectors in NoSQL or other containers such as tables, although we only utilize a few features. While it is possible to store vectors, we can’t search for them directly since vectors have multiple dimensions; thus, we can only store them.

Microsoft Azure Cosmos DB has helped improve our search result quality, although there is no perfect searching technique here. We need to utilize SQL queries, which are not standard SQL queries, requiring us to create specific SQL queries after reviewing the documentation. This includes reading samples provided in the documentation to access the data effectively.

I would recommend Microsoft Azure Cosmos DB to others who seek solid security and wish to protect their data without exposing keys and values. API-based authentication mitigates risks associated with lost keys. Using service principals and managed identities is advisable for enhanced security. However, if the effort to manage keys is unappealing, I suggest exploring other platforms that may not offer the same level of data security. 

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

Public Cloud

Microsoft Azure

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.

Public Cloud

Microsoft Azure

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.

My main use case for Microsoft Azure Cosmos DB is to support application workloads that require a highly scalable, low latency NoSQL database. I primarily use it to store and manage semi-structured application data, user information, configuration data, and frequently changing records. Microsoft Azure Cosmos DB provides the scalability, availability, and flexibility my organization needed to support applications as their data volume grows.

The data stored for my business application that handles user activity and operational data is crucial. The application stores user profile, session information, application events, configuration details, and frequently updated records in a flexible document format. The application continuously reads and writes this data, so low latency access and the ability to handle changing data volumes are important.

Microsoft Azure Cosmos DB has positively impacted my organization by reducing the operational effort required to manage scalable NoSQL workloads and making it easier to support applications as data volumes and users grow. The flexible data model has also reduced development effort when application data structures change. It has saved approximately five to ten hours per month by reducing manual database administration, capacity management, maintenance, and infrastructure related tasks.

The time saved has allowed my team to spend less effort on routine database administration and more time on application development, performance improvement, and other infrastructure initiatives. Instead of spending several hours on capacity planning, maintenance, and troubleshooting underlying database infrastructure, the team can focus on high-priority business requirements. It has also helped us improve our response time when application requirements change because we can scale or adjust the database environment without lengthy infrastructure provisioning activities.

The best features Microsoft Azure Cosmos DB offers for my use case are its global scalability, low latency performance, flexible NoSQL data model, and high availability. The ability to scale throughput and storage as application demand changes is particularly beneficial.

The feature that has made the biggest difference for my team is scalability with consistently low latency access. My application workloads can grow in terms of both data volume and user activity, and Microsoft Azure Cosmos DB allows me to scale without having to provision and manage additional database infrastructure manually.

Another feature that stands out for me is the combination of a flexible data model and global availability. Microsoft Azure Cosmos DB allows me to work with application data that changes over time without requiring extensive schema changes and helps support applications that need reliable access as they grow.

Microsoft Azure Cosmos DB could improve cost and performance management to be more straightforward, particularly for teams managing workloads with variable traffic. More detailed and proactive recommendations around throughput, partitioning, indexing, query performance, and capacity would be beneficial. It would also be helpful to have clear visibility into the relationships along with stronger built-in troubleshooting and performance diagnostics.

An additional improvement would be making day-to-day cost and resource management more transparent. More proactive alerts for unusual throughput consumption, partition hot spots, storage growth, and performance bottlenecks would help me identify issues before they affect the application.

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

I rate Microsoft Azure Cosmos DB ten out of ten.

I chose a rating of ten out of ten for Microsoft Azure Cosmos DB because it provides the combination of scalability, low latency performance, flexible data modeling, high availability, and managed operations that my application workloads require. What makes it stand out is that I can support growing data volumes and changing application requirements without having to manage the underlying database infrastructure myself.

I consider the governance and security capabilities around Microsoft Azure Cosmos DB in my use case to be strong. Its integration with Azure Active Directory and access management, encryption, networking, monitoring, and auditing provides a solid foundation for protecting data used by AI-enabled applications.

I find the AI-related output associated with Microsoft Azure Cosmos DB to be generally accurate and useful, particularly for tasks such as analyzing application data, identifying patterns, and assisting with query or performance-related tasks.

I recommend Microsoft Azure Cosmos DB for organizations that have applications requiring scalable, low-latency access to semi-structured or rapidly changing data. Before adopting it, teams should carefully evaluate their data model, access patterns, partition key strategy, throughput requirements, consistency needs, and expected data growth.

Public Cloud

Microsoft Azure

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.

Public Cloud

Microsoft Azure

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.

Public Cloud

Microsoft Azure