Microsoft Azure Cosmos DB Reviews

We primarily use Microsoft Azure Cosmos DB as a transactional data store and for some event-driven applications. We utilize the change feed, and the function app triggers quite a bit. MPerks, our customer loyalty application, uses it. It has become our go-to database, and we hardly touch SQL Server for new stuff.

Our developers find Microsoft Azure Cosmos DB easy to use and more scalable. The whole cloud model of only paying for what you use fits our organization well. 

The features most valuable to us in Microsoft Azure Cosmos DB are the auto scale and change feed. These features allow us to do some operations that are not possible with SQL Server. It is super configurable, allowing us to pick and choose the different Cosmos databases we need, whether or not dynamic scaling is the right thing for that workload.

Latency and availability are incredible. Given that our data is partitioned and indexed correctly, we can run queries and get results in less than five milliseconds. This has resulted in happier customers.

Cosmos is super-easy to use. It adopts a whole document database strategy with no relational data, so what you see is what you get. It's straightforward to understand, and you no longer need to worry about entity diagrams.

One of our biggest pain points is the backup and restore functionality needs improvement. They've gotten a little better in this area. SQL Server's long-term retention is amazing, and you can restore data from years ago. You need to open a support Microsoft ticket to restore your Cosmos DB backup, and it comes in on a different Cosmos account. It's just kind of a headache to restore data.

CosmosDB's ability to search through large amounts of data isn't great. It kills the RUs if you're using the transactional store. We use Synapse Analytics for our more analytical workloads. We love Synapse for that purpose.

I have been using Microsoft Azure Cosmos DB for about six years.

There are no critical scalability issues with Microsoft Azure Cosmos DB. It scales well with RUs, and it is never an issue for us. Our issues usually lie more on the application side.

The support experience has been pretty good, and I don't have a lot of complaints.

Positive

Previously, we used SQL Server. Microsoft Azure Cosmos DB was chosen because it is the go-to document data store, and our developers are familiar with SQL syntax.

New developers are able to get jumpstarted on Microsoft Azure Cosmos DB quickly. Although we learned some lessons on how to structure and partition data, the initial setup was not problematic.

I can't specify the exact ROI, but Microsoft Azure Cosmos DB has decreased our total cost of ownership.

We pay for what we use, with the flexibility to reserve our use. Autoscaling is a premium option, but it helps when our database isn't in high demand. It provides flexibility in configuring our RUs, whether we want to do it at the database or container level. We have lots of options to configure and pay for the solution. 

We evaluated AWS solutions, but ultimately chose Microsoft Azure Cosmos DB.

I would rate Microsoft Azure Cosmos DB a nine out of 10. Both Microsoft Azure Cosmos DB and Cosmos SQL DB are familiar to our developers who come from a SQL Server background.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

We use it as our main database for our network access control software, and we use it to store all of the information we need to authenticate different devices and users to the networks of our customers. It maintains all of the necessary data for our SaaS product.

It is pretty easy to maintain and to optimize. The main thing that we have to deal with is the RUs. Probably the number one topic of Azure Cosmos DB in the world is how to make sure you have the right RUs set in place for each of your different collections, but the tools that are available in the Azure portal make it very easy for us to check how the performance is going. We can check if we need to adjust anything within the system to ensure that we have the right scale and the right split of our different indexes so that we are getting the most throughput for the data we need. In general, it is very easy for us to maintain. We just need to use the Azure tools to let us know when we need to pay attention to the different throughput variables that are important in the general maintenance of the product.

We use Azure AI Search for all of our search needs. The integration that Azure AI Search has with Azure Cosmos DB is very good. We heavily utilize the integration with Azure AI Search for a lot of the features on our website. The search works very well. I do not know if we have what one would consider large amounts of data because each one of our customers is searching through just their own set of data. On average, each customer has data in the range of only gigabytes, so the search does very well, but I do not know if you would consider what we have as very large amounts of datasets. We are dealing in the few gigabytes range rather than anything huge like terabytes.

The benefits of its global availability and the response time were noticed right away because we immediately had customers who were globally distributed, so the latency was noticed right away. We got a good performance that way. We did not notice any of the other benefits until we got a lot more customers and had a lot bigger scale. As our scale has increased dramatically over the past couple of years, we have noticed that we have not had to do much with Azure Cosmos DB. It just takes all of our additional data and additional queries and all of the additional throughput that we are throwing at it. It does not need very much in terms of maintenance and performance tuning because it handles everything we need pretty much out of the box, so it is a low-maintenance solution for us where we just check on things every once in a while as a best practice. In terms of scalability, we have doubled, tripled, and quadrupled our customer size or number of customers, and we have not had to do very much with it architecturally just because it has been able to handle that scale.

For onboarding, the documentation is very good. As soon as I joined the company, I read a lot of the Azure Cosmos DB documentation so that I understood it. It is well documented, and there are support forums and Microsoft experts. We have a Microsoft Solution Architect dedicated to us, and we have been able to ask him questions. The community surrounding it and Microsoft's ability to answer all of our questions, my questions specifically, have been really good. The documentation is great. I have been able to find all of my answers during my tenure. Everything is generally answered in the documentation, and for what is not, Microsoft has been very quickly able to get to us through our Solution Architect.

Within the first week, I was already executing queries against the database and monitoring its performance. Within a week, I had a basic understanding of how to interact with the database and understand different performance metrics and structures within the database. It is pretty easy to learn if you are familiar with other databases. Because I was familiar with other document stores and SQL-based databases, there was not a lot to understand. There are some differences in the SQL language that you are allowed to use with Azure Cosmos DB, so there was a little bit of a learning curve there, but the documentation was really specific. It is not a sharp learning curve if you are familiar with any other database systems. If you are familiar with SQL Server, MongoDB, MySQL, or Postgres, a lot of the concepts are exactly the same.

We chose Azure Cosmos DB initially because of the type of data that we needed to store. We have a schema that is very nondeterministic and flexible. It is always changing based on whatever data we need to acquire from different devices, so we needed a document store with a flexible schema. 

In addition to that, our customers are globally located, so we needed a database store that could be globally accessed and had minimal latency, good throughput performance, good query performance, as well as scalability. All of the things that you look for in a good piece of software about performance, scalability, high availability, and disaster recovery are available in Azure Cosmos DB. Because of that and because it is a flexible document storage, we went with Azure Cosmos DB.

The one thing that I have been working on with Microsoft about this is the ability to easily split partitions and have it do high-performance cross-partition queries. That is the only place where either our data size or our throughput has grown beyond one partition, so being able to do cross-partition queries efficiently would be my number one request.

The request unit architecture that they have in place is understandable but could be better. What you get out of some solutions like SQL Server or MySQL is a lot more understandable. The request unit architecture of Azure Cosmos DB is not as easy as pure SQL solutions. They could do better in making the RUs more understandable and more flexible because changing your partition keys and your indexes is a larger batch of work than it necessarily needs to be.

The company I have been working for has been using it for more than five years, but I have been with the company for just over two years. I have been working with Azure Cosmos DB during my entire two-plus years at the company.

We have had only one incident where Azure Cosmos DB went down. It was about two years ago in the East US. They had an incident where the update they made caused some downtime for us. I forgot what the duration was, but luckily, we had global replication for our main Azure Cosmos DB setup, so while the East US was down, the West EU region picked up. The majority of our operations continued without issue because of our use of the global replication option available within Azure Cosmos DB.

Latency and availability are great. You can, of course, write code that does bad things for it, and we have had to fix our own code sometimes. Whenever we have written our code properly, latency and availability have been great.

The scale has been wonderful. Our ability to add request units as we have needed them has been easy. We do not have to do much other than tell the system we want more, and then it automatically scales for us, so we do well there. 

The only limitation is around the partitions. Each physical partition maxes out at 10,000 request units as they have documented. We have had to deal with that while designing our data structures to make sure that we take into account that physical partition limitation.

The quality is top-notch. We have been able to talk directly to some of the Azure Cosmos DB experts at Microsoft. We have been able to get extremely detailed answers with very specific recommendations for all of our different questions.

Their speed has been definitely acceptable. Within a day or two, I get at least an acknowledgment of my question. We have not had any high-severity questions to be answered right away. Most of our questions are during the design phase where we just need to know specific recommendations based on our needs, so there has been no real-time pressure. Answering or acknowledging our question within a day or two has been an acceptable time frame. We generally get our answers within a week, which has also been acceptable for us. We have never needed a super fast answer, but I am also clear about that in my communication with them. I tell them that it is not an emergency, and we are just in the design phase and need these questions answered.

I would rate their support a ten out of ten. There is nothing that I would ask for more from the support. They are responsive. They give accurate answers, and they are easy to deal with. That is all that you want from a support experience.

Positive

Historically, in my career, I have used SQL Server, ClickHouse, Postgres, and MySQL. ClickHouse is probably the closest equivalent, but we had to maintain everything in-house, so it was a lot more intensive to maintain. SQL Server was nice, but it does not have the document flexibility, or it did not have that at the point in time we were thinking of using Azure Cosmos DB. So, I am very familiar with all the SQL-based servers historically. They just did not have the necessary document flexibility that we were looking for when we selected Azure Cosmos DB.

It was already in place when I joined.

It does require some maintenance as we grow. Each one of the collections scales up by request units. We use the autoscale feature, but it has a bounded range, so as we grow, we watch the RU maximum, and we adjust the RU maximum of our different containers as we scale up. The maintenance is minimal. We change the RU scale maybe once per quarter. Otherwise, everything goes fairly without maintenance.

I do not know if it has helped us decrease the total cost of ownership, but certainly, it has helped in our DevOps maintenance. Our DevOps people spend a lot less time worrying about or dealing with Azure Cosmos DB. Because of that, we do not spend a lot of person-hours on Azure Cosmos DB. However, Azure Cosmos DB does come at a premium price in terms of being able to do all of its features. It has an appropriately associated cost with it. Because of that, we have not done any formal calculations to see if it saves us more than some of the other solutions such as SQL Server or Postgres. We have not done a cost comparison. What we do know is that it satisfies all of our needs. We do not spend a lot of time thinking about it. As we add features and datasets to it, we do not have to do a lot of performance testing, so we are just able to add things to it. It just works, and we do not have to spend a lot of development time, QA time, or DevOps time worrying about whether it is going to be able to satisfy what we need it to do.

As opposed to running our own VMs or our own databases, it would have reduced our overhead costs. All we have to do is go into the Azure portal, click a couple of buttons, and type a couple of numbers, and then it just happens without any other effort. It takes us seconds to minutes to change things, whereas other solutions might take days or hours to process. From that perspective, there is certainly a reduction because it only takes us a few seconds to scale our Azure Cosmos DB without any other effort. However, you pay for that with the actual price of Azure Cosmos DB itself. That is somewhat built into the price where Microsoft takes on that maintenance cost, but you pay for it.

The pricing and licensing model was initially difficult to understand, but as soon as I learned what was going on and how it was priced, it was pretty easy. What is more difficult is to understand how your system is going to behave specifically with the specific partitioning and querying that you are doing. Some of it is reactive because you cannot always predict what your customers are going to use in your product and in what specific way. So, while we have understood the pricing model, what we have not understood is which parts of our system would end up being the most expensive, costing us the most, or needing to scale the most. It is not necessarily an issue with Azure Cosmos DB itself. It is about understanding your individual software or our individual software when it is running on top of Azure Cosmos DB. It is about understanding what the behavior is going to be.

I would advise taking advantage of all of the features that are available. Especially if you are a globally distributed business, make sure that you have all of the high availability and backup options enabled so that you are not surprised in case of a problem.

Like almost all of the recommendations that you see in different Microsoft videos, make sure that your partition keys are set up properly from a RU perspective so that you know that you will be able to scale your individual containers effectively without running into the limitation of 20-gigabyte physical partition size or 10,000 RU physical partition throughput. Be aware that those exist and design your partition keys for the future so that you will not be limited when your system starts to get heavily utilized in the future.

I would rate Azure Cosmos DB an eight out of ten. There are some improvements that I would like to see around the physical partitions.

Our primary use case is mirroring the data for reporting.

Cosmos DB has helped us by providing faster response times for everything, which significantly improved our search results quality.

Azure Cosmos DB's graph queries are its most valuable feature. Although I have not yet explored vector search, it's coming to Cosmos DB, and I plan to look into it. Having data in a flat-file format in a document database speeds up processes, which is the primary purpose. Additionally, Cosmos DB's use of the Mongo platform makes it intuitive and cost-effective.

I use Azure AI services, including cognitive services and OCR. I recently built a chatbot using the model. Cosmos DB integrates well with other apps. 

There are no specific areas I believe need improvement as I am happy with what I am getting currently. However, I am open to new features in future versions, like possibly integrating AI features natively into Cosmos DB. Any improvement would be beneficial.

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

I have not encountered any issues related to the stability of Cosmos DB. The challenge does not lie in the technical aspect of Cosmos DB but in the non-technical aspects.

Cosmos DB has impressive scalability. We have been able to scale workloads as needed during peak hours without any issues, effectively meeting our expectations.

The initial setup was quite quick, taking only a few days for the team to be onboarded with Cosmos DB. The primary challenge was non-technical.

The implementation involved just the normal onboarding process for any human resource.

Our organization's total cost of ownership has been reduced by 20 percent due to the backend data mirroring for setting up the repository for reporting purposes. Dynamic scaling has also helped decrease our organization's overhead cost by automating the scaling process and reducing the need for human intervention.

Our experience with the pricing and setup cost is that it aligns with what we expect based on the pricing we see. However, I would absolutely like it to be less if possible.

I rate Azure Cosmos DB eight out of 10. There is always room for improvement, and the company could develop new features that could make it even better, but I am very satisfied with the current performance.

In our setup, we rely on Azure Cosmos DB primarily for cloud-native applications that demand global scalability. We use it for connecting web apps and implementing search functionalities.

Cosmos DB's low-latency data access has greatly improved our application performance. It is a game-changer, allowing us to move workloads from on-premises to the cloud, thanks to the reduced latency, and freeing us from the constraints of on-premises environments.

The most valuable features for our organization with Azure Cosmos DB are multi-master capability for applications, automatic failover ensuring high availability, scalability, support for multiple data models, and low-latency access. Additionally, the seamless integration with microservices running in containers adds another layer of efficiency to our operations.

In terms of improvement, slight enhancements in integration interfaces, expanded dashboard functionalities, and broader use-case support would be beneficial.

I would rate the scalability of Cosmos DB as a nine out of ten.

The technical support is quite good.

It is a relatively affordable solution.

For those considering Cosmos DB, my advice is to embrace its versatility. Cosmos DB can handle various data models like documents, wide columns, and graphs seamlessly. You can consolidate your needs into one database, Cosmos, eliminating the need for multiple databases. It simplifies management and offers a comprehensive solution for a wide range of use cases.

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

This is an event-driven solution. Most oil and gas companies have folder source systems, where they cannot scale, but they still want to provide real-time data to their end consumers for various analytical use cases and AI/ML processing; this is where we input raw data into the Azure environment of this solution. Then, eventually, we built the API on top of Microsoft Azure Cosmos DB because it's highly scalable. The solution is a little bit expensive, but the businesses are ready to accept it. 

In terms of performance versus scalability of this solution, you don't need to worry as long as you have your initial numbers in place. This product works by using performance currency, which is the number of request units per second. Once the data is ingested, based on that, we can know how many users are going to access across the world in every day, hour, or minute. Once you have the ingestion versus consumer pattern identified, you can use this product to input all those numbers, like the volume of data for migration. 

The built-in integration of the solution is tight. It can be used in conjunction with Synapse, Microsoft has also created a Synapse link. In this solution, the OLTP workload will never affect the OLAP workload. Therefore, the solution does data replication asynchronously without affecting the OLTP source system. No specific pipeline is thus required, which is not easily found in other services. 

In the server, there are two ways in which you can provision a call, one is serverless, which has a pay-as-you-go model, and another is a dedicated provision throughout. So, irrespective of what you allocate and whether you use it or not, in this solution, the charges are accounted for the request unit per second. This is a big drawback of the solution.

This is an expensive solution and if you get the initial calculation wrong involving how much you are going to ingest, how many people are going to query and more, then you are going to receive a very large bill at the end of every month.

Additionally, on the serverless option, there is a limitation regarding the amount of data you can ingest; this doesn't allow you to upgrade beyond a point, and the limit cannot be utilized for many use cases. On the execution side, whatever you create as a container, that container cannot be used as a destination when using serverless mode. This is another key limitation of the solution. 

I have been using the solution for one and a half years. 

I had minor issues while using the solution, but they were actively solved, and eventually, a justification was also given. Ninety-five percent of the time I used this solution, there were no issues. Microsoft's service in the cloud market is still growing and so there are some feature limitations. 

The solution is highly scalable. We use the solution in our enterprise both internally and externally, including integration for clients. We created our solution end-to-end by considering different audiences, people who can directly onboard Azure but might not need Cosmos DB.

There are vendors and individuals who cannot directly consume data on the Azure environment and will have a dependency on data. However, we cannot expose the source data for its performance issues and limited scalability, so we deliver this data by using Microsoft Azure Cosmos DB. The parent company Reliance has multiple subsidiaries like Ajio, manufacturing supply chain, Oil and Gas, and more; we used to use the same API for all subsidiaries, which was built on Cosmos. 

Technical support was good. I would rate the customer support an eight out of ten. They were fast and responsive, but the support team runs from different locations within or outside India, so whoever is working during the particular shift will take care of the case initially and then some other individual will take over.

So, my team had to re-explain the same thing over a call or meeting. But it was only a few times, they were able to get all the information based on the previous conversations most of the time. 

Positive

Deployment of the solution was very easy. Once the initial numbers are in place based on request units, only the instance creation was a time-consuming process. The time was consumed due to the dependency on other teams like DevOps, who are responsible for provisioning. So, it was a one-time process, but migrating and running the same workload between different environments was not much of a hassle. 

It took less than a week to configure and install this solution. To complete the setup, it took five to six professionals from our team. One key solution architect, two people from the DevOps team, and two solution architects from Microsoft were needed for the deployment of this product.

Maintenance of the solution is very easy because the solution follows a Platform-as-a-Service type of model. There is actually no need for any downtime or a patch upgrade because it is taken care of by Microsoft. I never have to worry about downtime for this solution. They perfectly deliver on the key characteristics of the product. 

Our business need was to deliver or provide the source data without any latency issues, in less than five or ten minutes latency, to be precise. We had to provide the data to the end consumer without overwhelming our source. We got the business confidence in the initial three months of using Microsoft Azure Cosmos DB. 

The solution is a bit on the expensive side. 

We tried to compare this solution with MongoDB, which is open-source. But we choose this solution because Microsoft is the first implementation partner for us. 

I would rate the solution an eight out of ten. My advice to other people will be first to identify the purpose of availing the solution. There is also a product called Azure Data Explorer, which is a more extensive service used for similar use cases.

Also, in terms of Cosmos, the user should be clear about whether they will be able to use the serverless deployment model or whether they need the dedicated provisioned throughput Model. They should also first use the price calculator by inputting the numbers to decide if they need it. I would also advise you to get in touch with a Microsoft Specialist and walk through all the doubts. 

The solution has a very good service, but the user should be clear about how to start using the product. For the initial three months, we did a lot of trials to get the components and RUs right and check how the calculation is happening. However, after the trials, we were very clear about how we wanted to move forward with the solution to get the maximum ROI. 

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 use Microsoft Azure Cosmos DB in our loyalty platform, which is based on our proprietary technology, Synapse LX. In loyalty, we need to enroll, score, and deliver rewards communications in near real-time. There are significant volume spikes in those activities, so our use case is to support the writing of information into our database. Cosmos DB is a no-SQL database that allows us to scale quickly and handle large volume spikes. It allows us to auto or manually scale in many different ways. It gives us much flexibility to handle that requirement and ensure we deliver the right customer experiences.

Cosmos DB is not difficult to use, but like anything, it requires careful planning and consideration of use cases. This is especially important when planning to implement it. From an optimization perspective, Microsoft has made significant efforts in the past 12 to 18 months to facilitate changes after initial implementation and optimize cost.

Cosmos DB provides excellent search result quality. Since implementing it, we have not encountered any issues with our searches.

After deploying Cosmos DB, we initially experienced some performance gains, followed by additional benefits that required a learning curve regarding tuning and configuration. As our understanding deepened, we were able to optimize it further.

In the last three months, Cosmos DB has helped reduce our total cost of ownership. Microsoft recently implemented a feature that allows us to achieve savings of up to 50 percent.

The most valuable aspect of Cosmos DB is its performance. It serves as the foundation for OpenAI's infrastructure, providing us with similar functionality. This not only prepares us for AI use cases but also efficiently supports our loyalty use cases. We can share information with our customers and deliver experiences without concern about performance.

For our Disaster Recovery plan, we currently use geo-replication. We'd like to avoid full DR replication if possible, as this would result in significant cost savings.

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

We have not had any stability issues with Cosmos DB.

Cosmos DB's scalability is excellent, which is the whole reason to use it for scalability and performance.

The dynamic scaling helps decrease our overhead costs.

The initial deployment was straightforward and consisted of two to three people.

Cosmos DB's pricing structure has significantly improved in recent months, both in terms of its pricing model and how charges are calculated. This has led to substantial cost savings for both us and our customers.

I rate Microsoft Azure Cosmos DB seven out of ten because of the disaster recovery requirements.

Cosmos DB presents a steep learning curve. I would rate it a five out of ten. The challenge lies not so much in understanding its concepts as in utilizing them effectively and efficiently.

It took us 12 to 18 months of focused attention to fully onboard our team. At that point, we began to understand. However, it wasn't until we went live and observed actual user activity that we truly grasped the whole picture. Testing is one thing, but experiencing real-world interactions provides invaluable insights and a deeper understanding.

Cosmos DB requires minimal maintenance, but monitoring its performance and optimizing it as needed is crucial.

Potential users should plan accordingly, as Cosmos DB is a NoSQL database that uses similar design principles. Consider the design and apply those principles beforehand to optimize performance from the start. Understanding your read-and-write ratio is crucial due to cost implications, so ensure you understand the balance between reading and writing to the database. All these factors matter as they can impact your costs, so consider them carefully.