Microsoft Azure Cosmos DB Reviews

Our primary use case for Cosmos is the storage of shell-fed signs and our pricing systems. We use it as a transactional database on the back end.

The ability to scale automatically is very valuable. Additionally, multi-region support automatically synchronizing to a different region for multi-region applications is a cool feature. It's more of a lift with other databases to configure that extra region and set up replication, even if it's on the cloud. With Azure, it's just a button click. It's that simple. 

The learning curve depends on your background. It takes time to learn if you're from a relational database background like us. However, it's fairly straightforward from a scalability perspective once you get the hang of it. You need to be aware of certain concepts like partitions and partition keys. Once you get those, I think it's fairly okay.

The auto-scaling feature adjusts hourly. We have many processes that write stuff in batches, so we must ensure that the load is spread evenly throughout the hour. It would be much easier if it were done by the minute. I'm looking forward to the vector database search that they are adding. It's a pretty cool new feature. 

I have used Cosmos for about five years.

The latency and availability are good. I don't have any complaints there. It goes back to how you're retrieving data and whether it's structured correctly. 

Cosmos can definitely scale well, but it comes with a cost. One of our databases is quite large and scaled up significantly due to our needs.

We have two databases, so it was challenging to define the partition key and ensure the workloads are spread out. We have millions of records in our Cosmos database, so spreading that out was difficult. We had to spread out the load to avoid a 429 error for a request that was too large. Partition key is more of a learning experience to understand the right thing to do. The entire process took around six months. It wasn't too hard.

We have reduced our overhead through dynamic scaling. I can't say precisely how much we've reduced our total cost of ownership using Cosmos DB, but we have a similar on-prem workload running on SQL, and we only pay a fraction for Cosmos.

Cosmos is cheaper than other solutions, but you must be smart about how you use it to keep costs down. We've made mistakes where the cost has increased more than we expected. You have the opportunity for it to be cheap or costly.

We were looking for a multi-region document database, and the ease of configuring multi-region in Cosmos was a significant factor in our choosing the solution. We also wanted to bring costs down, which was the other reason.

I would rate Cosmos an eight out of ten. Be cautious about spreading out the load evenly, especially when dealing with large volumes to prevent getting errors.

We have many use cases. We are using Microsoft Azure Cosmos DB for our event streaming framework. We are using Microsoft Azure Cosmos DB to store all the event data for AI activities.

We are also using it for a RAG-based solution, though it is not entirely RAG-based. We are using Microsoft Azure Cosmos DB as a staging solution, and then we are using the AI search to index it and continue to the RAG for the LLM.

We are just using it as a staging solution. We have use cases for extracting huge documents, which can be more than 500 pages or even 10,000 pages. We cannot directly use the LLM, so we have to use a RAG-based approach. For that, we have chosen Microsoft Azure Cosmos DB and we are using the vectors there. However, instead of directly querying the vectors in Microsoft Azure Cosmos DB, we are indexing that in AI search.

The searching capability is exceptional. It is very simple and incomparable to competitors. With SQL, we have to install everything, but this is pretty quick. We have a Bicep template. Using the Bicep template to create Microsoft Azure Cosmos DB containers and partition keys makes everything convenient. Scaling is also convenient.

The RUs still appear to be a black box for everyone. Even though they explain read and write RUs, it remains unclear for many users. With Microsoft Azure Cosmos DB, we are using event streaming in the entire organization. We are using a framework for event streaming, and we suddenly reached a huge amount - the capacity of 20 GB partition key. When it reaches 100% of RUs, we face issues. We have to work on rebuilding the partition key. 

Regarding billing, we need better control. Sometimes it exceeds the forecasted budget. More clarity on RUs would be beneficial, even though documentation exists.

There is a 2 MB limitation for a document, which is a hard limit. Additionally, modeling in Microsoft Azure Cosmos DB is more challenging compared to RDBMS and other NoSQL solutions because we cannot store everything in one place. Since it's NoSQL, we sometimes need to split one document into multiple containers due to the 2 MB limitation.

I have been using it for more than two years.

Its stability is good. I would rate it an eight out of ten for stability.

Scalability is pretty good. I would rate it an eight out of ten for scalability.

I would give a low rating to Microsoft support, as whenever I talked to them, I never got a solution. I had to guide them.

If the support ticket lands in certain regions such as Sweden, they have more knowledge and the ticket gets resolved easily. At times, it moves between departments, requiring escalation to get the correct person involved.

The support team needs improvement in understanding who they are talking to. They should not ask basic questions when speaking with experienced users. I am deeply knowledgeable about Microsoft Azure Cosmos DB, which I have had to explain to the support team.

Neutral

It is very simple. We can't compare it with any competitor. We just use the Bicep template.

Its implementation takes a maximum of one hour.

Because of the lack of understanding about RUs, the costs become unpredictable. It sometimes goes over the budget.

Currently, they are implementing Fabric and OneLake solutions. Fabric appears faster. According to Microsoft representatives, querying in Fabric instead of Microsoft Azure Cosmos DB will be quicker. However, I remain confident in the querying capability of Microsoft Azure Cosmos DB.

It is pretty good, and currently, everyone wants to move from Microsoft Azure Cosmos DB to Databricks, but when I query data in Databricks, it takes considerable time with huge amounts of data. It stores in the BLOB in the backend, but when we use Microsoft Azure Cosmos DB, it retrieves the data much faster. The main consideration is being careful with fixing the partition key.

I would strongly recommend it for new projects. When you create a project from scratch, it is easy to implement Microsoft Azure Cosmos DB because the library is very pretty good. You can just use the library and create a container. I do not see any complexity at all in using Microsoft Azure Cosmos DB. 

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

I'm the primary systems architect at DocuSign. We just launched a product at called Intelligent Agreement Management, and a central pillar of that is schema understanding. We use Microsoft Azure Cosmos DB as our schema store. It's the brains of our entire system. 

It is integral to our business because it helps manage schema and metadata for all our documents and customers. The AI insights we glean based on Azure OpenAI also end up in Cosmos DB. We need a NoSQL store because the schema is dynamic and flexible, so Cosmos DB is a great fit. It has four nines or possibly five nines availability, excellent geo-distribution, and auto-scaling. 

Cosmos DB has improved search result quality, throughput, and query latency. There are trade-offs to finding the sweet spot among all of these. Having a NoSQL solution that can do that in a 100 percent Azure shop is the best fit we could want. 

The features that stand out as most valuable are the autoscaling and hierarchical partition keys. We use account IDs at a higher level and entity IDs at a lower level. That gives us optimal query performance for our workloads.

AI has been a game-changer for new people without expertise, making it easier to use and optimize. You can ask GPT or Copilot for optimization strategies. If you have queries that are not performing well, you can feed the same queries, execution plan, and other things to the AI. The AI returns reasonable recommendations for what to do. 

Cosmos DB is effective at handling large queries. At DocuSign, we're processing over a billion signers and massive agreements and contracts. These things are being used for business-critical workloads, so performance, scale handling, and latency are crucial. Without these, we wouldn't have a product that anyone would want to use. 

I have worked with Cosmos DB at my company for the past 18 months, but I have used Cosmos at Microsoft for nearly a decade.

Cosmos DB provides impressive stability due to its high availability and ability to handle massive data volumes, which is essential for our business-critical workloads.

We have found Cosmos DB’s scalability to be exceptional, enabling horizontal and vertical sharding and supporting massive scale with efficient auto-scaling.

The team behind Cosmos DB has been highly responsive, providing excellent transparency and high-quality postmortem reviews during incidents, ensuring continuous support and improvement.

Positive

The initial setup was straightforward. Cosmos DB's integration went quickly due to the team's prior experience with Azure services, allowing us to prototype within a couple of months.

The challenge for us is always scale. We needed to move all the tables in lockstep that are involved in join queries. In some cases, we came up with a structured pipeline where stage one would go to SQL, and some of the query hints for the Cosmos DB thing would come from that first stage and so on. That was a migration challenge in normalizing the data, bringing it into Cosmos, and then, again, denormalizing some of the data. 

The critical mass of internal expertise, particularly from people previously working with Azure, enabled a smooth implementation with Cosmos DB.

Cosmos DB has always met our targets. However, we've always had our schema store on Cosmos DB, so it's not like we started with something expensive and brought our TCO down using Cosmos. Still, it's an excellent option for NoSQL or semi-structured data because our agreements start as a morass of raw data from PDF, OCR PDF, or paper OCR scans. 

After that, we match the structure with a known entity and for that known customer and run queries on Cosmos DB to bring out the rest of the structure and use AI to enhance it even further. In some cases, the customer will add custom fields to their entities. Cosmos gives us a low turnaround time from when the dynamic nature kicks into when the results return from that new schema information back to the same customer. It's a rich, complex scenario, but also a massive scale of data and customers.

The pricing model for Cosmos DB has aligned well with our budget expectations. We did not encounter pain points related to costs and found it cost-effective compared to high-end SQL solutions initially considered.

When I joined, the company was already invested in Azure, so there was never a bake-off between Cosmos DB and offerings from AWS. We implemented Cosmos initially because we have a massive transaction database on SQL. On things like the total cost of ownership, Cosmos DB shines. It seems to be the correct approach for our semi-structured data and our schema and entity store. A combination of Cosmos DB and SQL Azure was how we shaped our architecture on this journey, but we didn't evaluate Cosmos DB against non-Azure NoSQL databases.

I would rate Cosmos DB as an eight out of 10 for its overall capabilities, responsiveness, and alignment with our needs.

For retail, all the backend data, such as merchandise items, is stored in Microsoft Azure Cosmos DB. This data is processed by backend APIs, and the UI can perform displays, printouts, edits, creations, etc.

Cost-wise, it is transparent. It supports traceability. Any activity happening in your Microsoft Azure Cosmos DB can be seen from the Azure portal via log events. If you have some sort of observability, you can centralize logging and create historical insights or virtualization based on the activity. By default, Microsoft Azure Cosmos DB provides all of that on their main portal.

It is responsive when you have a large dataset stored in your Microsoft Azure Cosmos DB. It is no problem. You can quickly scale it. Unlike traditional solutions, you do not have to deal with a separate team managing the database.

Search results have been good. It is a good experience because you can search results via the Azure portal, via a query, or via CLI. You have plenty of options. Aside from that, you can do quick scaling of your Microsoft Azure Cosmos DB whenever you have an issue with the workload, capacity, etc.

Traditional database solutions require back-and-forth coordination between teams which can lead to delays in implementing simple tasks. With Microsoft Azure Cosmos DB running on the cloud, the developer can do a quick query, and the operator can do technical analysis or troubleshooting. It is beneficial overall in terms of operational effectiveness.

Optimization is achieved through indexes. It is pretty similar to other SQL or database solutions. Microsoft Azure provides Data Studio, where you can explore your schema, tweak it, create a backup, and restore existing data within Microsoft Azure Cosmos DB. These tools make your life easier if you do not like working with the CLI.

Microsoft Azure Cosmos DB is a good solution for distributed application requirements. We can perform multi-modeling. For modern applications, I would recommend Microsoft Azure Cosmos DB. It caters to different types of applications and also provides an API base wherein you can perform automated updates for your Microsoft Azure Cosmos DB resources.

It provides all the common features that other database solutions offer. The difference is that Microsoft Azure Cosmos DB is cloud-hosted. You can host it on-prem, but running in the cloud simplifies everything in terms of support and availability.

Overall, it works very well and fits the purpose regardless of the target application. However, by default, there is a threshold to accommodate bulk or large requests. You have to monitor the Request Units. If you need more data for a particular query, you need to increase the Request Units.

I have only used the technology for three to four months.

It depends on how you configure your Microsoft Azure Cosmos DB. If you are using it as a standalone service, you are unlikely to gain the full benefits of having Microsoft Azure Cosmos DB running on the cloud. However, if you consider scale sets and scalability, for example, you can achieve higher stability.

With Microsoft Azure Cosmos DB, we created an availability zone to ensure that there is a replica of the primary Microsoft Azure Cosmos DB instance. If the primary goes down, there is a secondary database that they can use for the application. The backend application gets repointed to the secondary instance.

I do not see any problem with the latency. Connecting from your local client like Azure Data Studio to your Microsoft Azure Cosmos DB can take time, but if you are going to connect an application to the database in the same region, there is no latency at all.

It is highly scalable. I would rate it a nine out of ten for scalability.

We can quickly scale using Terraform. We can perform horizontal and vertical scaling with Terraform and apply it. It will automatically reflect in our Azure environment.

Excellent support always comes from Microsoft. If you have a problem with different services, you just raise a ticket, and someone will reach out to you. I can elevate the severity depending on the criticality of your issues and the impact.

Positive

We did not use any other solution previously because this is a new project for modernizing the merchandising area.

The setup is easy, especially in the cloud, so I would rate it a nine out of ten for the ease.

All our infrastructure layers are being controlled by Terraform. If we want to set up a new environment, it can be done within a day for not only Microsoft Azure Cosmos DB but also all resources required for an end-to-end application flow.

You can do it yourself. They have good documentation, which is easy to follow.

You can get an ROI in a year, provided you deploy it properly with the right baseline forecasted plan in terms of resource sizing. There are many factors when it comes to ROI, such as how quickly you can onboard your application and consume the backend Microsoft Azure Cosmos DB. For those new to the cloud, it might be hard to get the ROI quickly, but those with existing resources in the cloud can achieve their ROI in the short term.

It can save a lot if you perform regular monitoring. If you have a monitoring team for checking the overall utilization of Microsoft Azure Cosmos DB resources, it will save a lot of cost. You can react quickly and trim down the specs, memory, RAM, storage size, etc. It can save about 20% of the costs.

Its cost is transparent. Pricing depends on the transaction and data size, but overall, it is cheaper compared to hosting it on your corporate network due to other factors like power consumption. 

Current pricing is fine, and you can scale it afterward. You can start with a small size and scale eventually. That is a benefit of having Microsoft Azure Cosmos DB on the cloud.

It was the primary platform choice of the client at the time.

You can quickly learn Microsoft Azure Cosmos DB if you are familiar with how databases work.

Microsoft Azure Cosmos DB offers all you need for a particular database solution. It is better if you can host it in the cloud, applying security controls like data at rest and data in transit. You must ensure Microsoft Azure cloud is only accessible in a secure manner.

Scalability-wise, you can quickly scale your Microsoft Azure Cosmos DB, unlike on-premises, where you must request and procure additional resources. There is no such need; you can use infrastructure as code like Terraform and adjust the resource specs whenever you like. There are no capacity and workload concerns.

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

We use Cosmos DB as a database for the cache mechanism. We have a product integrating e-commerce platforms with backend ERPs, pulling merchandising data. We maintain millions of products in the ERP and store them in Cosmos DB in document format. When a query comes from the e-commerce platform, it goes directly to Cosmos.  

Cosmos is preferred because of its speed, robustness, and utilization. We have all the merchandising information in Cosmos DB, which provides concrete and optimized data when searching for new products on the site. It is faster than other relational databases.

It can query large amounts of data efficiently, depending on how you write the queries. This is a Document Database, and the system needs to read the whole document. If that is correctly clustered, then it will be faster, but if the developer makes some mistakes, it won't be optimized. 

The most valuable feature is the data writing process, where we write data into batch segments. The built-in vector database is helpful. There's one vector for the product and another for the price. I don't have much experience with vectors because we use Cosmos as a cache DB. You won't see any major challenges when you use it as a more significant enterprise application. I would rate the vector database's interoperability with other solutions an eight out of 10. 

The main area of improvement is the cost, as the expense is high. Also, when writing processes into Cosmos, sometimes the threshold is met, which can be a problem if developers have not written the code properly, limiting calls to five thousand. These aspects need addressing.

I have been using Cosmos DB for three years.

I would rate the interoperability of the vector database with other solutions as eight out of ten. It's good, but the performance depends on how well queries are written.

We compared MongoDB and Cosmos DB. Cosmos DB is easier to configure, and our team is already familiar with managing it, providing an advantage.

The initial setup was straightforward, with no major challenges. We onboarded the team in no more than three days. 

The cost of using Cosmos DB is high, which sometimes raises concerns from clients regarding the increased solution cost. While it has helped decrease the overall cost of ownership, the specific figures are not readily available.

I would rate Azure Cosmos DB eight out of 10. The solution is variously challenging but manageable once the team is familiar.

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.

Our primary use case for Azure Cosmos DB is mainly as a Document DB and vector DB.

Azure Cosmos DB is very easy to use. We do not have to spend a lot of time on its optimization.

There is a lot of reference code we can use. It is very easy. We could grab some code to interact with the database.

We have integrated the vector database with some of the IoT applications and recently, some AI-related topics because it is a cloud-native service. Our company offers professional services to help customers bring their own applications to the cloud. The cost and performance are some of the main benefits of the vector database. 

The integration of the vector database with Azure AI services is great. In most applications right now, we use the logic of vector search and the traditional way of using full-text search. It is easier for the applications to get those search results.

I am more on the presales side. Most of the time, we do a quick demo for our customers. We only spend about fifteen minutes building a simple application with the RAG functionality with the customer's own data. That is very impressive.

It provides good SLAs and requires less effort in maintenance.

The global synchronization feature of Azure Cosmos DB stands out as the most valuable for me. It is a reliable and consistent storage solution, suitable for various data types. It is always available. Additionally, it is cost-effective.

I do not have any specific suggestions for improvements at the moment. However, having more AI capabilities in the future would be beneficial.

I have been using Azure Cosmos DB for three or four years.

The stability of Azure Cosmos DB is very nice, with features like cross-region synchronization that allows fast and reliable performance.

The latency and availability of Azure Cosmos DB are very nice. There are cross-region synchronization features. The speed is very fast.

Azure Cosmos DB scales well, both in terms of capacity and performance. You can adjust the Request Units (RUs) as needed, and the cross-region synchronization allows easy scaling across different locations.

As compared to a traditional RDBMS, Azure Cosmos DB’s dynamic scaling decreases an organization’s overhead costs by half.

We previously used Redis and Postgres for vector databases before they were supported in Azure Cosmos DB. In the beginning, the vector database was not supported with Azure Cosmos DB, so we had to use the Redis or Postgres database, which was expensive. Azure Cosmos DB is cheaper.

Our company offers consulting services for Microsoft-related products. This is one of the reasons for recommending Azure Cosmos DB, but sometimes our customers use MongoDB and other solutions.

The initial setup of Azure Cosmos DB was easy. During the migration or implementation of Azure Cosmos DB, there are sometimes some incompatibility issues, but they are minor issues.

It was easy for our team to use. It took them one week to know the system and work with it. It takes our team members about four weeks to earn their certification for Azure Cosmos DB. There is a special certification for Azure Cosmos DB.

It is cost-effective. They offer two pricing models. One is the serverless model and the other one is the vCore model that allows provisioning the resources as necessary. For our pilot projects, we can utilize the serverless model, monitor the usage, and adjust resources as needed.

I would rate Azure Cosmos DB an eight out of ten. There is room for growth, but Microsoft is constantly releasing new features and moving very fast.

Some of the use cases for Microsoft Azure Cosmos DB include storing log files and generating keys for our clients inside Microsoft Azure Cosmos DB. It helps us solve the problem of generating unique identifiers for our clients in Brazil, as we have many clients in our company. The system serves to generate unique keys for client attendance.

We are at the beginning of use, about 2 months in production, but it has been working well so far. We have not faced any problems.

Microsoft Azure Cosmos DB has improved our organization because there are various plans we can choose for different situations. We can scale and improve when needed, and the solution can be provided very fast when we want. The solution we use operates without problems.

We could see its benefits quickly because we can provide Microsoft Azure Cosmos DB very fast and when we want.

With Azure being our main cloud, the valuable features of Microsoft Azure Cosmos DB include integration with other Azure products that we're using and governance inside Azure. For integration with other products inside the Azure cloud, it was a better choice. 

It was easy to use and optimize Microsoft Azure Cosmos DB, as it was not difficult to configure. 

We are at the beginning of production, and everything is working very well. The price can always be lower, but currently, it's not a problem.

My experience with Microsoft Azure Cosmos DB is less than one year.

My impressions of the latency and availability of Microsoft Azure Cosmos DB are good, as we haven't faced any problems until now.

We have not scaled workloads with Microsoft Azure Cosmos DB yet, as we don't need it.

It's a large enterprise.

I would rate the support for Microsoft Azure Cosmos DB as excellent because the support team was very nice and helpful. We just send an email or call on Teams, and they quickly answer our questions.

Positive

I would rate the ease of setup for Microsoft Azure Cosmos DB as a seven out of ten. The setup was not very difficult because of the SaaS deployment, as we just needed to configure some things, such as the network and type of billing.

We did a detailed research on the solution we needed and decided to go with Microsoft Azure Cosmos DB. It took us one hour to set up the environment, tables, and connections.

In terms of the learning curve, another team is using it more extensively. I don't know if they have had any challenges. The learning curve seems to be pretty good.

For the deployment of Microsoft Azure Cosmos DB, we required two people. The roles involved in the deployment included one person from the network team and one person from the infrastructure on the cloud team.

We have seen a return on investment with Microsoft Azure Cosmos DB because we can have more control over our NoSQL solution. More control over our NoSQL solution helps us manage fraud, which can save money. We can better understand our data using this solution since we can integrate with other data and create views to understand the information.

We are not consuming so much yet since we are at the beginning of using this solution. I would rate the pricing of Microsoft Azure Cosmos DB a six out of ten.

We needed this kind of product. We are using NoSQL for the first time. We previously looked at MongoDB, but we switched to Microsoft Azure Cosmos DB because we preferred to use a native solution from Microsoft. The main difference is that Azure Cosmos DB is a Microsoft-native solution, and we prefer it because we have the support.

My advice to people considering using Microsoft Azure Cosmos DB would be that if they are using Azure and need a native solution, it is a nice choice. If they use MongoDB, they would need some APIs to integrate. 

As it is our first time using a NoSQL solution inside the company, we will probably continue using Microsoft Azure Cosmos DB. 

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