Microsoft Azure Cosmos DB Reviews

We use it for our internal operations, including order history and other things related to e-commerce.

We do not use the built-in vector database capabilities since they are driven by another team in our organization. We just access through the API.

We find Microsoft Azure Cosmos DB easy to use. We are provided APIs for each and every write or edit access, even for read operations. We don't directly query the database. API-based access makes it easy.

Previously, we used to have maintenance or server issues. We don't have those issues anymore.

The best feature of Microsoft Azure Cosmos DB is API access, which makes it very easy to interact with the database without needing to write queries. It's also fast. As it's Microsoft-provisioned, the cloud is very accessible and reliable as well.

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

I've been using Microsoft Azure Cosmos DB for more than one year.

In the past year, I have only been using Microsoft Azure Cosmos DB for a year, and previously we encountered Microsoft issues such as maintenance or server problems, but these days we are not observing that as much.

For stability and impressions of latency and availability, I would rate it an eight or nine; we have not seen significant issues recently.

I rate scalability as pretty good. Because it's in the cloud, scaling is easy.

We are a very large organization. It is hard to know how many teams use Microsoft Azure Cosmos DB or still rely on the older systems. I am in India, and our team uses Microsoft Azure Cosmos DB, and I believe teams in the U.S. use it as well.

I would rate the technical support a nine out of ten.

Positive

Before using Microsoft Azure Cosmos DB, we had a different database system in place. The main factor for switching was cost-related. It was a leadership decision, and as a fresher, I wasn't involved in these discussions.

We were not part of the deployment. We were involved in migration activities, but I'm not very sure about the deployment experience. We aren't seeing any major issues now.

Maintenance of Microsoft Azure Cosmos DB is ongoing. There is a Cosmos DB team in our organization conducting maintenance, though not very frequently.

I'm not aware of the exact costs. We received one report a long time ago regarding savings after we started using Microsoft Azure Cosmos DB, but I don't remember the details. It seems to have helped significantly. We were using a different database system previously, and one of the reasons for acquiring Microsoft Azure Cosmos DB was cost.

I definitely recommend Microsoft Azure Cosmos DB, although I'm still learning. It's been just two years, but I've taken courses on Microsoft Azure. I recognize the advantages in scalability, availability, and cost factors, with maintenance issues being minimal as well. 

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

Our corporate mission is to help companies achieve more with their data, which often means unifying your data. We have a SaaS solution and have built a Copilot with Copilot Studio on top, as well as some of the Azure AI services, which is now Foundry. We are starting to use it to allow people to use natural language to ask questions of their data. We are early in our journey, but I suspect it will work well for us.

By incorporating Cosmos DB into our Azure ecosystem, we have streamlined costs and improved efficiency. The integration has allowed us to manage Cosmos alongside our other services, providing a comprehensive view of resources. The inclusion of advanced capabilities has been beneficial, positively impacting our internal operations and the services we offer to clients.

We're early in our journey, but I believe it will improve the quality of our search results. We're having a lot of success with Copilot and are excited to see how it'll work in a traditional sense as well. We're in analytics, so we work with a lot of massive data and look at tens of millions of rows. We haven't had any capacity challenges or thresholds. We started with small data, so having a tool that will grow with you is great. 

We love the ability to land data with Cosmos DB easily. Cosmos is native to Azure, so everything works seamlessly with it. You need good data to have good AI, and Cosmos makes it easy to land the data.

The recently added ability to mirror to Fabric has been beneficial. Cosmos DB enables us to handle transactional and analytical workloads in the same database. 

Cosmos DB is easy to use. You can set up a database with a couple of clicks, and it's simple to scale it up and down based on your needs. Within Azure, the Explorer UX has been great for us, too. You don't have to install another tool to run a quick query or explore some data. Additionally, the ability to estimate your Cosmos costs through the portal and manage features has been useful.

Like most database tools, it takes some time to understand. If you come from SQL or even from the Mongo world, many concepts will be familiar to you. While it takes some learning and expertise, it's not a large hill to climb. You must learn the advanced capabilities, but they make your solutions more powerful.

The vector database requires an additional engineering step to move the data from a transactional database to a vector store so that you can query it and use it in AI. However, because the vector capabilities are built in, it saved us engineering time and allowed us to get our solution out faster. 

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

We have used Cosmos SQL for more than five years.

There have been no challenges with Cosmos DB's stability. We have both our SaaS app and the analytical side running without throttling issues.

The scalability is great, both horizontally and vertically.

In the past, we've worked with traditional SQL Server and MongoDB. However, Cosmos being native to Azure and the seamless integration prompted our switch.

The onboarding process was relatively quick for us. We were up and running within two weeks, including a pilot test.

The dynamic scaling during peak times has been crucial in cost management.

The integration of Cosmos with our other Azure services allows us to manage costs proactively. The built-in capabilities help control costs in line with our growth expectations through the portal. 

I rate Cosmos DB eight out of 10.

We use Microsoft Azure Cosmos DB to store document-type data, graph data, and key-value type data. It is a globally distributed database, which we mainly utilize to store document-type JSON data. 

In my project, I work with core SQL-type queries. Using the API, we are storing JSON data in Microsoft Azure Cosmos DB with a database and container-level architecture. This involves storing items using a partition key for optimized query performance.

We get data from BLOB storage. After some processing, we are storing it in the JSON format in Microsoft Azure Cosmos DB.

Microsoft Azure Cosmos DB automatically indexes documents. By indexing every field in the document, it is easy to get fast performance to retrieve the records. While fetching, it fetches only specific fields required for further processing, which makes it efficient. Fetching all the fields from a document takes more time.

Storing data with a partition key makes data fetching easier and faster.

Microsoft Azure Cosmos DB helps in fetching data faster. There is a single-digit millisecond response to fetch those records.

Microsoft Azure Cosmos DB supports scalability. At a peak time, it will automatically scale the RUs. When there is less data, it will decrease them.

In Microsoft Azure Cosmos DB, one valuable feature is its ability to store data in multiple regions. If one region fails, it automatically switches to a healthy region, ensuring minimal latency and disaster recovery without impacting data latency in applications. It scales automatically based on query performance and peak traffic.

Microsoft Azure Cosmos DB is very easy to use.

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

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

Microsoft Azure Cosmos DB provides high availability with 99.9% reliability. When we store documents in Microsoft Azure Cosmos DB, it stores them in multiple regions, not only at specific regions. If one region fails, it automatically switches to a healthy region. 

There is low latency. The partition key helps achieve low latency by ensuring data is stored and accessed efficiently.

Microsoft Azure Cosmos DB offers both automatic and manual scaling. The automatic scaling feature adjusts RUs based on peak demands, which helps manage workloads efficiently. The dynamic scaling feature has helped reduce overhead costs by automatically managing resource utilization.

Our application is being used globally, and we have ten members in our team.

When I joined the organization, Microsoft Azure Cosmos DB was already in use. I have not worked with other NoSQL databases before.

It is a Platform as a Service. It was already implemented before I joined.

I started working with it in the first month. I had the support of the senior developers of the time.

It does not require maintenance from our end.

We monitor the cost daily through Azure Monitor to evaluate how much it is costing for documents, thereby keeping track of the return on investment.

Microsoft Azure Cosmos DB pricing is based on RUs. Reading 1 KB document costs one RU, whereas writing one document costs five RUs. Pricing for querying depends on the complexity of the query. If you increase the document size, it will automatically increase the RU cost.

I would recommend this solution. For e-commerce applications, it is more beneficial because it can store semi-structured data. It is the best option if you want to get data quickly because it organizes the data in a good way. When a region fails, it automatically switches to a healthy region. It has backup storage, and it scales automatically based on the peak time or low time.

I would rate Microsoft Azure Cosmos DB an eight out of ten. It is a good solution, but the cost can increase with cross-partition queries due to data distribution.

We are using Cosmos DB in several different ways. We receive unstructured and semi-structured documents from partners, and we use Cosmos DB to push the data in and scale it to kick off internal processes. 

We receive notifications from our customers to take action quickly regarding the energy grid. Cosmos DB is also used in a different project for our settlement system, where it is used as a queuing engine for the change notification portion.

The ability to scale efficiently improves our performance and scalability. Although we haven't yet used Cosmos to improve search result quality, we believe it can be useful with vector search and data architecture improvements. We are exploring AI, but I don't think our focus will be generative. We do a lot of ML models, and we plan to restructure our data to use the data lake or leverage the efficiency of already created models to reduce our resource costs and improve efficiency. 

Change notification works well, and the ability to process documents in a scalable way is important. This means we can efficiently thread out different operations and meet our organizational performance and scalability needs. 

Cosmos DB is pretty straightforward. I'm not 100 percent an expert. I have three or four different developers up to speed on it and working on it. They do most of the daily operations, while I do a lot of the prototyping and conceptual aspects.

While we don't use the vector database system, some interesting features might benefit our future data architecture. In one of the workshops, we learned about its capabilities and how it's used as part of Copilot and the backend database. I'm thinking about AI, our data, and some performance benefits.

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

I started dabbling in Cosmos before COVID approximately four or five years ago. Initially, I just wanted to test some concepts and figure out its benefits, using the Cosmos local engine to better understand its functionality.

We have not encountered any issues with latency or availability. As we continue to grow and scale, we will keep assessing to ensure our expectations are met.

Scaling the workloads is one of the key advantages of Cosmos, preventing the database from becoming a performance bottleneck.

We assessed other databases like MongoDB but chose Cosmos for its object-style database capabilities, user-friendliness, and ease of access. It aligned well with our needs, and a Microsoft conference initially piqued our interest.

Onboarding to proficiency took a couple of months. The transition from a traditional relational database programmer to an object database was straightforward. The learning curve was manageable and engaging.

I don't know how much money Cosmos DB has saved us. We're still using some of the old databases, but when phase them out, we'll see a significant cost reduction.

The pricing model aligns with our budget. It's expected to lower overhead costs, especially as we phase out older databases. Cosmos DB is great compared to other databases because we can reduce the cost while doing the same things.

We considered Mongo DB among other databases, but Cosmos had the desirable capabilities we were seeking.

I rate Cosmos DB eight out of 10.

We have numerous healthcare AI use cases, including utilization management, documentation, letter generation, and voice call creation. These are both real-time and non-real-time use cases. My team is the platform team that enables the services. The ML teams are the practitioners who work on these products. 

The vector database has had a significant impact by making everything searchable, and the number of potential use cases exploded when GenAI was added. We've transformed many tasks into AI machine-learning problems. We have a ton of institutional expertise across the enterprise. It's crucial to be able to bring all of that into one place, ask questions, and get answers.

The most valuable feature of Microsoft Azure Cosmos DB is its real-time analytics capabilities, which allow for turnaround times in milliseconds. This is crucial for applications like fraud detection. 

Using and optimizing Cosmos DB is relatively straightforward. We talk regularly with the Microsoft team, and hands-on help is available when needed, so the experience was seamless. 

We have migrated to Cosmos' vector database search from Azure AI Search.  We don't face too many challenges with interoperability because everything is built on Azure, and we don't have any multi-cloud applications.

Azure AI services integrate and perform well with the vector database. Sometimes, we struggle to customize the RAG pipeline instead of using the embedded settings. Those are rare use cases, but they are useful for most use cases. 

The search capabilities work well once you have your data set up. It's more of a challenge in the knowledge-based integration than the modeling side. Our data is scattered. SharePoint, Confluence, and meeting minutes data are separate. We are working actively to make all the data flow. 

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

I have been using Microsoft Azure Cosmos DB for about two and a half years.

The latency numbers of Cosmos DB are satisfactory and align with expectations for clinical decision support engines.

While I have not personally tested it, the information I have suggests that Cosmos DB has robust scalability capabilities.

We have regular connections with the Microsoft team, which provides hands-on support and makes the use of Cosmos DB straightforward.

Positive

We previously used Azure AI Search, but we are transitioning to utilize built-in capabilities in Cosmos DB.

The platform team is responsible for enabling the services, while the ML teams use these products.

The pricing model aligns with our budget expectations, and we get a significant corporate discount from Microsoft because we're a partner.

I would rate Microsoft Azure Cosmos DB eight out of 10.

As the technical lead of the Microsoft Azure Cosmos DB team in my previous company, I helped our customers. We had a team of around 20 people. We addressed any issues our customers faced when using Microsoft Azure Cosmos DB or related services. Once resolved, I worked directly with our operation manager to engage with customers, checked their user experience, gathered feedback, and made improvements. This work was primarily managed by a manager who collects feedback and monitors KPIs to improve our service.

Microsoft Azure Cosmos DB is very easy to use once you understand the process, and we have a very good team. Because it is more costly compared to other services, the Microsoft product team takes customers very seriously. If any issue arises, they immediately join calls with customers to troubleshoot problems.

Microsoft Azure Cosmos DB has significantly improved the quality of search results, making searching easier compared to other services such as ADF, data factory, or SQL databases. Compared to AWS, Microsoft Azure Cosmos DB is user-friendly and offers robust features.

The Microsoft product team is proactive and engages with customers, helping to update features and resolve issues promptly, demonstrating a commitment to customer satisfaction. The learning curve for Microsoft Azure Cosmos DB is manageable, as it didn't take much time for me to grasp the basics. With the right information, even new users can learn the fundamentals in about two to three months.

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

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

The stability of Microsoft Azure Cosmos DB is generally good, though there are instances of outages. I would rate the stability at seven because there is room for improvement. 

The scalability of Microsoft Azure Cosmos DB rates at six. We have documented guidelines to help customers scale, but there are still some issues where customers struggle with scaling down after scaling up. It is straightforward, but some customers might need more guidance on using the Cosmos capacity calculator before scaling up. Customers should be able to scale down easily without needing detailed formulas.

In our organization, about 100 users specifically worked with Microsoft Azure Cosmos DB. This technology is utilized across almost every organization today, and Microsoft provides robust support that is taken very seriously. 

Our clients ranged from small to enterprise businesses, and we managed support requests from various types of customers, including premier customers who required extensive assistance.

The technical support of Microsoft Azure Cosmos DB deserves a rating of eight because I have experience with other services where assistance takes longer. In other services, there are multiple layers to check, but with Microsoft Azure Cosmos DB, we can directly reach out to the Microsoft product team members who are developers, and within a day or two, we can get on a call with the customer to help them with their issues and suggest best practices. This quick support is not seen in other services, where it can take five to ten days.

Positive

I observed many customers migrating their data from native MongoDB to Microsoft Azure Cosmos DB, indicating significant improvement.

Microsoft Azure Cosmos DB stands out in comparison to AWS, specifically with DynamoDB. Microsoft Azure Cosmos DB offers unique and cost-effective features that AWS does not. Additionally, it supports various configurations beyond just SQL or Mongo, such as the Table and Gremlin APIs, which many customers prefer.

The deployment of Microsoft Azure Cosmos DB is very easy. With the right approach, migration can be done smoothly and quickly.

I was using the built-in vector database when I was with the previous organization. There are vector search capabilities and other related features.

I recommend Microsoft Azure Cosmos DB to other users because it has significantly improved, especially concerning visible outage scenarios. The portal now provides clear workload choices for production and testing accounts, making it easier for customers to decide what they need. 

I would rate this solution a seven out of ten.

I am using it to store our data. We are using Azure Cosmos DB to store our JSON-based documents.

The high speed of Azure Cosmos DB compared to other competitors is remarkable. It is one of the most powerful features, offering high availability and high speed. Its benefits can be seen immediately after the deployment.

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

I have more than two years of experience with Azure Cosmos DB, whereas with Azure, it has been more than four years.

Choosing the correct partition key is crucial, as it affects our database speed and related operations.

Latency and availability depend on the consistency level.

It is a Platform as a Service, so we are concerned about the underlying interface. We can move to a higher tier as all Azure cloud resources are open to easy scaling.

It offers an option alongside the Azure SQL database. Azure SQL database has its own capabilities, whereas Azure Cosmos DB supports all major big data requirements like Cassandra and Gremlin. Azure SQL database is more focused on transactional data instead of analytic data. Azure Cosmos DB covers a wider area.

I have not personally deployed Azure Cosmos DB, but DevOps pipelines provide options for this. It should be easily deployable with the help of Microsoft's documentation.

It takes a couple of minutes to be up and running. It also depends on how we are deploying, whether it is via an ARM template, Azure pipeline, or directly via Azure release.

Azure Cosmos DB is generally a costly resource compared to other Azure resources. It comes with a high cost. We have reserved one thousand RUs. Free usage is also limited.

It is not like a traditional database. Choosing the partition key needs an understanding because it will affect the database speed. By making your partitions in a logical and efficient way, you can improve the speed of search analysis.

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

We are basically a system integrator, so we use Microsoft Azure Cosmos DB in multiple projects for different things, often when migrating from other hyperscalers. We do many AWS to Azure migrations. It's our go-to solution, given its flexibility on the SQL driver and the MongoDB driver. When running a NoSQL database, it's our preferred choice. Recently, with the AI wave, we've been using it as our backing store for many things, from vectors to structured or somewhat structured data. 

One of the scenarios in which we have used the MongoDB driver on Microsoft Azure Cosmos DB was an AI project with the NFL. It was called the NFL Combined Copilot, and we needed to ground data and provide real-time insights to scouts and coaches on the sidelines. It had to be fast and precise, with significant stakes involved. The experience was fantastic in terms of performance. One of the most critical aspects was that there was no room for error - it's five days in February with 350 athletes and 32 NFL teams present. It needs to work, scale, be precise, and bring the required results, or you must wait a year. This has been one of the places where we have pushed it to the limit regarding availability, scalability, and the whole concept of search and grounding for AI applications.

Using Microsoft Azure Cosmos DB and getting started with it is super straightforward. As you scale and adapt along the way, it remains fairly easy to work with. However, as the complexity increases, one challenge is that you need to be mindful of properly structuring your data for world-scale applications. Fortunately, there is plenty of guidance, documentation, and examples available to assist with this.

As a developer or development firm, one of the aspects we appreciate most is the ability to prototype effectively. We can take a project from the initial prototype stage to production-ready status without the need to redeploy the database or switch products. This approach allows us to use the same tools for both prototyping and scaling. It's important to note that you don't have to face a super complex scenario to benefit from this product. It is well-suited for prototyping and remains capable when transitioning to world-scale applications.

With the current AI wave, the built-in vector database capability of Microsoft Azure Cosmos DB for model grounding or the RAG pattern is crucial. Previously, we had to consider alternatives such as Pinecone and other third-party software, dealing with all the problems of designing, scaling, and maintaining the database. Microsoft Azure Cosmos DB enabling this feature allows us to get it out of the box with familiar tools and context, along with the benefits of its scalability and elasticity, providing excellent support for the highly relevant RAG pattern for AI search.

We have developed several AI scenarios, one of which was recently highlighted in Gartner research. This scenario involves discovering multimodal media within the context of sports, showcasing how organizations like the NBA and NFL use Azure to locate specific pieces of content through interaction with an agent. This was built using the vector database functionality we have integrated.

The peace of mind that Microsoft Azure Cosmos DB provides regarding global distribution is invaluable. In traditional databases, you need to consider how to scale, whether horizontal scaling is possible, and handle multi-regions, multi-masters, redundancy, and other concerns when building a world-scale solution. We get most of these features with Microsoft Azure Cosmos DB essentially included.

I would discuss two separate streams. The first concerns the local developer experience. Microsoft Azure Cosmos DB is a complex cloud platform service, and when developing applications, the most legitimate way to test it is by using the actual product. The ability to run an emulator locally would reduce development costs and improve accessibility, eliminating the need to provision it for each developer. When developing an application, developers typically run everything on their own machine. With Microsoft Azure Cosmos DB, to get the exact same experience and features, we end up using it in the cloud on Azure and paying for it during development. As we add or remove developers from the project, we need to provision new databases or instances. Having the ability to run an emulator or replica in the local development environment would be fantastic for cost savings and developer onboarding.

The second area involves tooling around projected costs for queries. Microsoft Azure Cosmos DB has a unique way of using units to charge for CPU or compute while running queries. Having a calculator to determine query efficiency and expense based on current data structure and projected volume would be really interesting. However, if I had to choose one improvement, it would be the local development experience.

We have been using Microsoft Azure Cosmos DB since its release, approximately eight years ago, and we have witnessed its entire journey.

The resiliency aspect makes Microsoft Azure Cosmos DB our go-to solution for databases. It has the ability to run in multiple data centers. If there happens to be an outage, which is unlikely, you still have spare nodes and replicas available. The SLA ends up being extremely high from an overall service perspective. Having the flexibility to continue operations even if one Azure region goes down is significant, as you can still write to it and restore functionality when the region returns. With traditional database engines, you would need to implement complex workarounds, such as restoring backups in another location and attempting to sync back to the original location. The stability is excellent, and its resiliency in globally distributed deployments is outstanding.

The scalability is excellent, though it comes with associated costs. When you need more replicas, regions, or additional resources, you will need to pay for them, but you maintain the ability to scale. This contrasts with deploying your own database, where you would need to handle maintenance, and scaling to required volumes might not even be possible due to engine design limitations. Microsoft Azure Cosmos DB has been built with scalability in mind, which is evident throughout the product deployment. The ability to configure regions and replicas is crucial, and it feels unlimited in potential. As long as you can accommodate the costs, you have the opportunity to expand and improve the SLA without re-architecting the entire solution.

I have used MongoDB and AWS Aurora in different combinations, such as self-hosted MongoDB, MongoDB Atlas, Aurora, and Postgres. Compared to others, what stands out about Microsoft Azure Cosmos DB is its scalability. When working with MongoDB or traditional SQL databases, horizontal scaling and multi-region/multi-master scenarios are complicated topics that require significant work and planning. With Microsoft Azure Cosmos DB, it's simply a matter of flipping a switch. Though there is a cost involved, it removes many complexities and saves our team considerable time.

It's really straightforward and easy to get started with Microsoft Azure Cosmos DB. One of the main advantages is its compatibility with various drivers. For example, if you are migrating an application from MongoDB, you can use the same MongoDB driver to interact with it. The same applies if you're using SQL or DocumentDB; you can leverage the existing code with minimal changes. This is a significant benefit, especially in scenarios where you might be considering a switch in database engines. Often, developers worry about having to revise their entire application when changing databases, but with Microsoft Azure Cosmos DB, that's usually not necessary. For developers familiar with DocumentDB or MongoDB, the ability to use the same libraries and code brings a sense of familiarity, which is a major time-saver. Additionally, provisioning through the Azure portal is a breeze—it's as simple as clicking a button to get started.

The initial setup took less than an hour to do properly, approximately half an hour.

It does not require any maintenance, but as software systems are living and breathing things, you might need to adjust usage patterns and queries for efficiency. Compared to running your own database, there is no maintenance - you don't need to worry about indexes, drives getting full, or CPU scaling.

The implementation was completed by one person.

The pricing for Microsoft Azure Cosmos DB is good, but there is a developer factor to consider. It could be economical or expensive depending on usage. Guidance about query consumption of Request Units (RUs) would be beneficial, especially since costs can escalate if not used properly. When building solutions on Microsoft Azure Cosmos DB as intended, following guidance and documentation, it works well. Compared to traditional databases, it has a different pricing structure that factors in multi-region capabilities, number of requests, and multi-master functionality. While traditional managed databases simply consider CPUs, memory, and bandwidth, Microsoft Azure Cosmos DB's pricing involves more variables. When used properly, it can be more cost-effective, offering better value due to the included multi-region capabilities, which are quite expensive to implement in traditional database settings.

My advice is to start with the drivers you are most familiar with. If you have experience working with MongoDB, begin using Azure Cosmos DB with the MongoDB driver and the code you already know. From there, you can gradually learn about specifics such as request units (RUs), indexing, and partitioning—elements that contribute to what makes Microsoft Azure Cosmos DB powerful and scalable. By leveraging SDKs and libraries you are already accustomed to, you'll have one less thing to worry about: how to use the platform effectively.

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