Microsoft Azure Cosmos DB Reviews

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Negative

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

The provided templates help us deploy Cosmos DB quickly.

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

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

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

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

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

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

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

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.

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.

The primary use case is focused on advanced analytics. We use Microsoft Azure Cosmos DB for storing results from OpenAI models, acting as a temporary information repository for APIs, and for log systems. We also experiment with its Vector Search capability.

Microsoft Azure Cosmos DB has helped to improve efficiency, providing good response times and allowing the storage of AI process results, which is crucial for feedback loops. 

The tool makes it easier for us to store data in a database. Our company is a Microsoft shop using Azure, and our big data ecosystems are oriented to solve needs in the Azure architecture. We are looking at maintaining the tools within the same ecosystem without breaking the whole scenario of the solutions we have to set up. Cosmos DB helps us do those types of operations. 

The performance is so good it creates an ecosystem that allows data scientists to develop applications without clashing too much or losing the security and governance over the information.

Microsoft Azure Cosmos DB offers the response times needed for advanced analytics applications. It supports multiple use cases, including storage of AI model results and temporary information repositories. 

Performance and security are valuable features, particularly when using Cosmos DB for MongoDB emulation and NoSQL. The platform's ability to efficiently tokenize AI models for later consumption is also a benefit.

Within the layer, we're using it with OpenAI. That is the main one. If we use document intelligence from the entire database layer,  it is where we have our developments deployed on Kubernetes pods that connect and leave data.

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

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

We have used Microsoft Azure Cosmos DB for about two years.

We haven't experienced significant stability issues with Cosmos DB. Occasionally, latency occurs between applications, but it has not caused major problems.

While the scalability of Microsoft Azure Cosmos DB is theoretically simple and efficient, there is a degree of uncertainty. Dynamic scalability doesn't instill full confidence and can lead to increased costs if not managed correctly.

The initial setup requires a steep learning curve due to the differences between the query language in MongoDB and NoSQL, making it a demanding task for developers.

It requires an educational process that can't be achieved quickly. It took us about four to six months. It's an adaptive process that's not difficult, but it is time-consuming. 

The training for using Microsoft Azure Cosmos DB has been ongoing for four to six months, indicating a lengthy adaptation process for the development team.

Cosmos DB is expensive, and the RU-based pricing model is confusing. Although they have a serverless layer, there are deficiencies in what I can define and assign to a database. Estimating infrastructure needs is not straightforward, making it challenging to manage costs.

I rate Microsoft Azure Cosmos DB seven out of 10. 

My company developed an anti-money laundering compliance platform specifically for the gaming industry. This multitenant platform utilizes Microsoft Azure Cosmos DB as its core operational database.

We have a high-throughput, large-volume data ingestion process, with substantial data flowing into our environment. We needed to solve two problems: ultra-high volume, requiring speedy reads and writes of hundreds of gigabytes of data per day, and the ability to distribute our platform geographically. Azure Cosmos DB's geo-replication features and the ability to host and scale our database across multiple regions, keeping data close to our customers, were primary deciding factors.

Azure Cosmos DB is quick to adopt with a shallow learning curve. The average user can be operational within hours or days, handling small to medium data volumes. However, optimizing for ultra-high throughput scenarios involves a steeper learning curve, requiring substantial knowledge to master Azure Cosmos DB. Nonetheless, most users can leverage it as their operational data store with minimal effort.

Our platform boasts several extensive language model features, particularly around summarization capabilities. We use vector searching in Azure Cosmos DB to facilitate the retrieval of an augmented generation model with our LLM implementation. It's a standard RAG implementation using Azure Cosmos DB. Compared to other options, a key advantage of vector indexing in Azure Cosmos DB is the ability to query documents alongside vectors. This pinpoints the precise information required for RAG in our LLM solution, granting us greater flexibility than vector searching in other Azure services.

We integrated the vector database with the Azure OpenAI service for our LLM solution.

The Azure AI services were simple to integrate with the vector database. There was a slight learning curve, especially as we were on the private preview of vector searching. This led to some hiccups with our existing database configurations, specifically regarding continuous backup. We couldn't enable continuous backup and vector searching simultaneously. However, this was solely due to our participation in the preview, and I'm confident this issue won't persist in the general availability release.

Azure Cosmos DB is fantastic for searching large amounts of data when the data is within a single partition. Over the last two weekends, we ingested over 400 gigabytes of data into our Azure Cosmos DB database and saw no change in querying performance compared to when our database was only 20 gigabytes in size. This is impressive and powerful, but the scope is limited to those partition queries.

The first benefit we've seen is increased developer productivity. Azure Cosmos DB is an easy database to work with. Its schema-less nature allows us to iterate quickly on our platform, develop new features, and store the associated data in Azure. Developers find it easy to use, eliminating the need for object-relational mapping tools and other overhead. Geographic replication and the ability to scale geographically is another advantage. This is challenging with other databases, even other NoSQL databases, but Azure Cosmos DB makes it easy. Cost optimization is a major benefit as well. We've been able to run our platform at a fraction of the infrastructure cost our customers incur when integrating with us. This allows us to focus resources on feature development and platform building rather than infrastructure maintenance.

Azure Cosmos DB helped reduce the total cost of ownership. We don't need DBAs, system administrators, or typical IT staff to run the infrastructure because we can use Azure Cosmos DB as a platform or a software-as-a-service data storage solution. This makes the total cost of ownership significantly lower than any comparable solution using relational databases or other NoSQL solutions like MongoDB.

We enable auto-scaling on all of our Azure Cosmos DB resources, which helps us achieve cost optimizations.

The querying language and the SDKs they've provided over the years have been phenomenal, giving us a significant advantage. Being a NoSQL database with a schema-less design allows us to optimize costs and reduce the infrastructure we need to manage. While we don't utilize every feature, auto-scaling has been invaluable for optimizing both cost and performance on our platform daily.

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

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

Over the four years we have been building, Azure Cosmos DB has not caused us one second of downtime.

The latency and availability of the Azure Cosmos DB is excellent. We have single millisecond latency point reads, which is the majority of the queries that we run on our platform. So, it's an ultra-high performance, ultra-high throughput platform for managing data.

We are confident in Azure Cosmos DB's ability to scale and meet our needs even with massive data volumes. We ingest hundreds of gigabytes of data into Azure Cosmos DB daily, reinforcing our confidence in its scaling capabilities.

Our experience with technical support has always been great. We've been lucky enough to connect with the product team resources at Microsoft around Azure Cosmos DB, and we've received fantastic support from the Azure Cosmos DB team.

Positive

I've used MongoDB extensively, both self-hosted and through their SaaS solution, Mongo Atlas. I've also worked with relational databases like PostgreSQL, SQL Server, and MySQL. Additionally, I've experimented with non-document data stores like Cassandra, but not in a production environment. All the other databases have been used in deployed production applications.

Azure Cosmos DB offers a minimal total cost of ownership. No database administration or dedicated teams are needed to manage it, which increases developer productivity compared to relational database solutions. Azure Cosmos DB also provides higher levels of data consistency without the traditional data migration problems of relational databases, and its schema-less nature makes versioning easier. However, there is a steep learning curve for building large-scale applications and optimizing throughput with Azure Cosmos DB. Additionally, its analytical capabilities are not as strong as other solutions.

The deployment was straightforward to initiate. While numerous configuration items are needed for production workloads, particularly key management, getting started remains simple and accessible.

We deployed our infrastructure as code, initially using Azure CLI scripts to deploy AzureCosmos DB alongside other infrastructure components. We have since transitioned to Terraform for this purpose. From an implementation strategy perspective, we are a multi-tenant platform using logical tenancy, meaning a single Azure Cosmos DB database accommodates multiple tenants. We have a relatively large number of collections, approximately 40, within our Azure Cosmos DB database. To optimize cost, we share throughput where feasible and provide dedicated throughput for containers with high read or write volumes.

One person is enough for the deployment.

For the first three years of our company, we were able to run a production environment while spending less than $10,000 a month on our database. In contrast, our customers pay tens of thousands of dollars for the systems we integrate. Therefore, Azure Cosmos DB is a highly cost-optimized solution when used correctly.

I rate Microsoft Azure Cosmos DB ten out of ten.

We use Azure Cosmos DB extensively for searching alongside Azure AI Search, which offers full-text Lucene syntax-compatible querying. While a significant portion of our searches leverage these dedicated search indexes, we still conduct a fair amount directly in Azure Cosmos DB. Although it might not be entirely fair to say that searching isn't Azure Cosmos DB's strong suit, it's worth noting that its capabilities are constrained by partitioning requirements. This limitation places a ceiling on its overall effectiveness for specific scenarios. While Azure Cosmos DB can be extremely valuable for querying within partitions, alternative solutions are often better suited for queries spanning multiple partitions.

I've built tools around the Azure Cosmos DB SDKs to make them incredibly easy to use. My team had no learning curve and could leverage our shared libraries. It took me less than a week to achieve a production-quality implementation for accessing and saving data within a platform.

We have 20 people in the organization who interact with Azure Cosmos DB, consisting of 15 engineers and five others.

Azure Cosmos DB typically requires minimal maintenance, but if data partitioning is not done correctly, some overhead may be incurred due to the need to replicate containers and move data. Thus, while generally low maintenance, some maintenance can be required in certain situations.

For anyone thinking about implementing Azure Cosmos DB, first, understand your data and invest time in understanding the partitioning in Azure Cosmos DB. If you get your head wrapped around the partitioning, everything else will be straightforward.

In our project, I used Microsoft Azure Cosmos DB primarily for storing new or updated JSON documents.

With SQL Server, we have to use a lot of joins when a lot of tables are present in different databases. When we join tables present in different databases, we first load a table in memory and then apply join on them. With Microsoft Azure Cosmos DB, we do not have to do that. It solves the problem of joining different tables.

We did not have to convert JSON files to a relational database format. We did not have to separate the JSON file into a data model. We could directly use those files. We did not need any primary-foreign key relationships or any relationships between tables. We just needed a partition key. Based on that, we could simply save data into Microsoft Azure Cosmos DB.

Its performance is good. Integrations are very quick. In my project, Microsoft Azure Cosmos DB was at the center of the business. Everything was running around Microsoft Azure Cosmos DB. Performance-wise, it solved all the latency problems that they were facing before.

Microsoft Azure Cosmos DB is very fast. Data retrieval and data storage are very quick. It is known for its speed and efficiency, with quick data retrieval and storage operations without latency. You can do a lot of operations in real time.

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

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

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

I have been using Microsoft Azure Cosmos DB for three years. I last used it about six months ago.

I have not encountered any stability issues with Microsoft Azure Cosmos DB. Its stability is commendable. I would rate it a ten out of ten in terms of availability and latency.

There was a challenge concerning scaling related to RU limits, but Microsoft has introduced dynamic RUs to tackle this issue. I am not sure about its recent effectiveness, but earlier, I manually increased RU capacity to address concurrent access.

It is capable of quickly searching through large amounts of data, but our project was not very extensive. We did not have a lot of records. However, it can support a large amount of data. From this aspect, it is a brilliant product.

We had about 40 people on our team using Microsoft Azure Cosmos DB.

I rarely needed to reach out to Microsoft for technical support regarding Microsoft Azure Cosmos DB. After it was up and running, we did not require much support.

Neutral

Other than Microsoft Azure Cosmos DB, I have used SQL databases. I have not used any NoSQL database.

It was a PaaS solution. I was not involved in its initial setup, but it is simple and quick, taking about five to ten minutes. If you want concurrency, some documentation is available, but it would be helpful to have some hands-on examples.

We used the ARM templates available in the Azure portal for deployment. We had CI/CD pipelines, and we deployed them using ARM templates. That is the strategy we use for the deployment of Microsoft Azure Cosmos DB.

It does not require any maintenance from our side.

It takes about three months to train someone on it. They only need to learn how to query the database.

It took me around one and a half years to understand the real benefits of Microsoft Azure Cosmos DB. It is a nice product.

In terms of performance, Microsoft Azure Cosmos DB benefited us greatly by solving latency and data retrieval issues, but I cannot comment on cost savings as the financial aspects were managed by others.

The pricing is perceived as being on the higher side. However, if you have large data operations, it might reduce costs due to performance efficiencies.

I did not evaluate other NoSQL databases; the client chose Microsoft Azure Cosmos DB based on its performance.

I would recommend Microsoft Azure Cosmos DB if you are looking for performance. I am not sure about the pricing, but if you have a large number of users, Microsoft Azure Cosmos DB is helpful.

If you are using proper indexes, data retrieval is fast and search is easy. Otherwise, it will take a lot of RUs to get the results.

If you are migrating from traditional or legacy workflows to Microsoft Azure Cosmos DB, it would require a lot of rework. For new implementations, Microsoft Azure Cosmos DB is advisable.

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