Microsoft Azure Cosmos DB Reviews

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. 

We use Cosmos DB as our entire storage database solution for our application. We don't use any other relational database. We have a file that we use for configuration, but we use Cosmos for user data.

We have about 100,000 users a week who visit our website. We have plans to increase usage to four times what we're using now.

The biggest benefit it offers is scalability. It's easier to work with concurrency and updating data. We don't have to worry about locking cables or the speed of reads or query searches because we've structured our data around a key value. Everything is super fast, and it basically removes any bottleneck related to databases in our application, and we just use reference keys. One document will reference the key of another document that we need, so we don't have to rely on searching.

Partitioning is helpful because we use it heavily. Partitions are really nice because they help with the collection of data. Not only is it fast to recall the data, but when you partition it, you can pull the partition and then query the exact document from that partition. It helps with data recall.

There's another feature that we just started implementing, which is partial updates of documents. It doesn't require the entire object to update, but updating documents across applications becomes difficult because you have to pull the entire document, which means you have to support the entire model to update it. So, that application has to know about every single parameter that may or may not have been added because if it reads and writes the document again, you'll lose data elements.

An improvement would be a more robust functionality around updating elements on a document, or some type of procedural updates that don't require pulling the entire document. Otherwise, you have to keep all of your apps up to date with the models, and that can be cumbersome and lead to errors. Usually, you don't always remember, and then it leads to some type of bug, but you won't realize why. You'll lose some value because you don't realize that you have some application that doesn't run often. You forget that it writes to that same document and you didn't update the model.

It would be nice to have some type of functionality for less common updating applications and to not always have to worry about keeping that model up to date.

There's some integration with Entity Framework and it's nice, but it's not robust and it would be good to have something like that when it comes to pulling data.

Occasionally, you have to query the database for values because we save our appointments and we don't have an index on appointments. We don't have a manual lookup for appointments, so we don't save it in another file. We have to run a query to get appointments that occur on a specific day and the downside of that is you have to use strings just to hardcode the string values. It would be nice to more easily integrate with a tool like Entity Framework, and I know that they do, but it's not an easy process. It would be nice to have an easier way without relying on text to query the database.

I have used Cosmos DB for a year and a half.

There have been some configuration issues, but we haven't hit any thresholds or roadblocks when it comes to throughput. That was one of the reasons that we leaned toward it and not a relational database, especially at scale. We haven't run into any issues when it comes to that.

We look at community answers because we can usually get answers faster than messaging support directly. We don't usually resort to a customer service type of support unless it's a fundamental issue. 

When we had an outage in the middle of the night, the turnaround time was within a few hours.

Previously, I used Couchbase. I've also used Neptune, which is a different type of database. I've also used SQL.

We chose Cosmo DB because it's more tightly integrated. One of the reasons we chose this version of a non-relational database was because of the speed of development. We also chose Cosmos DB over other types of NoSQL databases because it's so tightly integrated with Azure, it's easily managed through deployment templates, and it's very easy to scale. If you're using Azure already, it's a very easy tool to pick up and integrate into your applications.

Cosmos is pretty straightforward. There is more complexity, so you just have to be mindful. We had a small issue with making sure that the disaster recovery settings were set up correctly. We found out that there was some type of outage in the middle of the night, but we noticed that the failover didn't run properly. It was because of some configuration that should have been caught earlier, and it wasn't obvious that we got it wrong.

There are some infrastructure teams that manage some underlying resources that are related to Cosmos and some of the configurations, but for our specific implementation, we have three developers at most. We usually only need two people for maintaining and managing the solution.

We deployed the solution in the cloud, but we configured everything in-house.

We have seen ROI. There's no active management when it comes to that. When I've worked on relational databases, there's a lot that goes on, like indexing, upgrades, and store procedures. I've managed relational databases for years while working on an application and worked with people who managed them. Cosmos is nearly maintenance-free and very easy to use.

The pricing is really good. I would rate the cost as 9 out of 10. There may be some more complicated use cases that are more expensive. When we've budgeted for our resources, it's one of the more expensive ones, but it's still not very expensive per month.

I would rate this solution as 8 out of 10. 

When it comes to ease of use, spinning up and working at scale, our specific use case, and the scalability that it offers, the solution is definitely very good.

My advice is to use containers as single objects and create manual indexing to improve efficiency.

I used to work for a bank in Turkey and used Microsoft Azure Cosmos DB in the bank for reporting. We used the solution for customer relationship management (CRM) and cost management.

Microsoft Azure Cosmos DB is easy to use and implement for application programmers.

The integration of the on-premise solution with the cloud can be difficult sometimes.

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

Microsoft Azure Cosmos DB is a stable solution if you use it on the Azure cloud.

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

Microsoft Azure Cosmos DB is a scalable solution. Currently, 10,000 users are using the solution. They use the dashboard application, but the dashboard application calls the data from Microsoft Azure Cosmos DB.

The solution's initial setup is straightforward if you use it on the Azure cloud.

We use a Microsoft subject matter expert (SME) to integrate Microsoft Azure Cosmos DB with the cloud or banking application. Microsoft Azure Cosmos DB can be deployed in one day. The solution's implementation is very easy in the Azure portal, but the most time-consuming step is to define the old data model in Cosmos DB. The security and the integration between Azure and on-prem are also time-consuming.

Microsoft Azure Cosmos DB is moderately priced, where it is neither expensive nor cheap.

The solution's licensing is usage-based. You will have an enterprise agreement if you use the solution in a cloud environment. The enterprise agreement is complex, where it is usage-based in addition to a base price. They decrease the solution's cost for an enterprise agreement, calculate the usage, and charge monthly bills.

Microsoft Azure Cosmos DB was deployed on the cloud in our organization. Only two or three people are enough to deploy and maintain the solution. Microsoft Azure Cosmos DB is the best solution for customers needing high-quality technical support.

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

Our current project primarily relies on the file system to handle incoming source tests. Within this setup, we capture both metadata and result data from these tests. We extract metadata information from these files and store it in Azure Cosmos DB and we have several software services in place to facilitate this process.

It is one of the simpler databases to work with in terms of code management, tracking, and debugging due to its straightforward data storage and retrieval mechanisms.

There is room for improvement in their customer support services.

In one of our recent projects, we stored metadata information and log data within Cosmos DB.

It offers good stability capabilities.

It offers impressive scalability, both in terms of throughput and storage. Its ability to scale dynamically allows us to align the database resources with the specific demands of our applications. Given its scalability and performance capabilities, we highly recommend it for use in large enterprises and organizations.

There were instances where their customer support services were slow. As previously mentioned, when it came to setting up Azure Cosmos DB, not everyone was proficient in cost considerations, and our team lacked extensive prior experience. Our main support was provided by Microsoft's documentation and we were able to successfully navigate these challenges. I would rate it eight out of ten.

Positive

The initial setup presented some challenges and required us to delve deeper into understanding the daily implications. Microsoft documentation proved to be a valuable resource in navigating this process.

The initial setup, planning, and configuration took approximately one to two weeks to complete. The timeline for implementing the solution varied based on the specific use case and the discussions held with the client. We conducted regular reviews, documented our progress, and established a static attack system. Due to some design-related confusion, the overall implementation process was extended to about one to two months. Still, Cosmos DB and related components were set up within one to two weeks.

Its pricing structure is quite flexible. It operates on a pay-as-you-go model, which means the cost is directly tied to the resources you consume and the throughput you require. Initially, our expenses were relatively low because we didn't store a significant amount of data, but as our storage needs increased over time, our expenses naturally grew in proportion to the resources and capacity we used.

Initially, we encountered some challenges in understanding it, as it wasn't as straightforward as managing an SQL Server database or setting up environments within Azure Data Factory and DevOps. This complexity is related to the fact that Cosmos DB offers a range of additional features and capabilities. Our initial difficulties could also be attributed to our team's limited prior experience with Cosmos DB. Considering these factors, I would rate our experience with it at an eight out of ten. Beyond these initial hurdles, we found it to be a valuable and capable solution.

I work for a retail company that uses Cosmos DB internally for access management. You have a graph with a hierarchal model that goes from owner to manager to assistant manager to employee, etc., and you provide access based on this hierarchy. Our workshop manager uses Cosmos DB to track requests for access and who needs to approve them. 

Employees who want to access specific resources will submit a request, and the application owners will approve it. Within the applications, there are often multiple levels of access. So the owner of those processes or files must authorize access. We have nearly 500 users. The security and access management teams mostly use Cosmos DB. 

The company is considering a switch, but that might take many years. Many others have switched and will continue to switch to other solutions. However, after you've invested a couple of years into it, it becomes more challenging because you need to rewrite many things. 

I don't think Cosmos DB has improved our organization. People are using it, but I'm not sure it's the best solution. For one, it's costly. Also, there are other issues with it. You cannot get all the records simultaneously. You can only get it in chunks of 1,500 maximum.

Cosmos DB is a graph database. I could see the advantages when we implemented it because it didn't have much competition. MongoDB was doing it, but it wasn't a popular solution for graphs, structures, and hierarchy. The only competitor was Neo4j.

I have been using Cosmos DB for nearly a year.

I rate Azure Cosmos DB eight out of 10 for stability if you allocate the necessary resource units. It is based on the concept of a resource unit. There are three settings: auto, manual, and another one I can't remember. You can manually set a limit on what goes to the resource unit during a specified time. or it will automatically send and continuously increase. 

This can create some instability. For example, if I limit my resources to 30,000 RUs, I expect to consume, but if the load is higher, it will fail and continue to fail. I will get an error that says, "Too many requests."

If you set it to "auto," you'll have to pay for it. You can adjust the limit, but it will not automatically do it. It requires someone who can think in terms of RUs, not the other databases we usually use. The person should always think in terms of resource units because you're paying for each resource unit. It isn't simply writing queries and pulling the details from the database. That is a steep learning curve. Many assume Cosmos DB is like any other NoSQL or graph DB. 

Cosmos DB is scalable, but there are some limitations on the amount of data you can hold in this partition. I think the maximum is 50 GB. That is a lot of data, so it is scalable, but there is a limit. It isn't infinite. Only 99 partitions are allowed with 50 GB each, then the maximum amount of data is under 5,000 GB.

However, it isn't simple because you need to define each record. You have to decide which partition the records should go to. Suppose I have 100 GB of similar records and want to put them in one partition. That isn't possible. 

I rate Azure support nine out of 10. They respond quickly and will help you manage costs. However, they mainly give you an overview of the issue, so they'll never have an in-depth idea of what you're doing. They aren't the owners of our product, so they don't know much about it, but they can ask you generally: What are you doing? Are you doing too many updates? How can we reduce the cost? 

They usually make common suggestions, but so few technical people understand Cosmos DB, and they will be costly. 

Positive

I have used multiple NoSQL databases. The most common is Neo4j, but people also use MongoDB, which is a little easier. You have optimization and all those features there.

I rate Cosmos DB nine out of 10 for ease of setup. The setup is easy, but backing Cosmos DB takes a little more work. It isn't difficult, but you have to raise a request to Azure support. It isn't in your control. The documentation is good enough that most application developers can handle it by following the steps in the documents.

We did it in-house. Two developers should be more than enough. One person could do it alone, but it's always good to have an extra person to verify that your actions are correct. After deployment, it doesn't require any maintenance. When you want to make a copy, you submit a request to the support team and within 24 hours. 

We haven't seen a return. You could benefit from this, but few engineers know how to use it correctly, so that's a problem. It depends on the company. I believe only large organizations can afford it. 

You also should be ready to invest in developers because it has a considerable learning curve. In other databases, you have something called "data cutover." You can change the whole concept of your data to make it more efficient. That is not possible in Cosmos DB. It's too big and will take years to change, whereas that might take you only two or three days in other databases.

For example, let's say you are paying a hypothetical amount for a mistake you made. We'll say it's $1,000. After a couple of years, you realize that you will only need to pay $200 after fixing that mistake, but it will require too many changes in multiple places to fix that error. You might need to discard your old solutions entirely, and it takes years to rewrite everything. Cosmos DB isn't going to reduce the number of people. Conversely, it's going to increase problems and create more confusion.

I rate Cosmos DB one out of 10 for affordability. It was expensive. We pay almost $1,000 daily to use it. It doesn't work traditionally — it works on resource units — so it's costly. It's a graph DB, which has advantages and disadvantages. Neo4j and MongoDB do the same thing, so it depends on your environment and costs.

There are also issues with how you design it. You cannot create the traditional way like you would in other databases or graph databases. Typically, you would pay a fixed subscription yearly. With Cosmos DB, you pay monthly based on the source unit. That's what is expensive. 

It's harder to find designers and developers based on that. Many solution architects will set something up using the traditional way of thinking. Once you start using it expensively, it's challenging to change that. You end up with millions of records, so it's impossible to change all of them. 

We are considering changing from Cosmos DB to MongoDB.

I rate Azure Cosmos DB six out of 10. I wouldn't recommend it. I suggest using other products like Neo4j and MongoDB. If you must use it, you should hire an expert who understands how to design the tables, indexing, and partition keys. The setup is effortless, but how will you write the code? It should be predetermined.

We mainly use it for products that are based on graph concepts. We are using it for mobile applications and real-time analytics.

We have scaled it from 400 users to more than 1000 clients. We were able to scale efficiently during COVID-19.

The graphical representation of data is the most valuable feature of the solution. We did not face any glitches.

The support tickets are not cheap.

I have been using the solution since 2017.

I rate the tool’s stability an eight out of ten.

We had around 300,000 users. They were distributed globally. I rate the tool’s scalability a nine out of ten.

The support team is not competent. We end up with the wrong agents sometimes. Sometimes, we must buy support tickets. It is not a good idea to have tickets that cost a lot.

Negative

It is a cloud-only solution.

We have also used MongoDB and SQL Server.

We had some challenges at the beginning because our team did not know how to optimize the tool. They made some expensive applications. However, we were able to cut it down by 95%. Overall, I rate the product an eight out of ten.

I use Microsoft Azure Cosmos DB for data engineering.

Microsoft Azure Cosmos DB is fast, and its performance is good compared to normal SQL DB.

Sometimes, the solution's access request takes time, which should be improved.

I have been using Microsoft Azure Cosmos DB for one year.

Microsoft Azure Cosmos DB is a stable solution.

Microsoft Azure Cosmos DB is a scalable solution. More than 100 users use the solution in our organization.

The solution's initial setup is straightforward.

The solution's deployment time depends on how complex the job is. Learning-wise, it takes a few weeks to get your hands on, and then you can get started from there. The solution was implemented through an in-house team in our organization.

Microsoft Azure Cosmos DB is deployed on-cloud in our organization.

I would recommend Microsoft Azure Cosmos DB to other users.

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