Microsoft Azure Cosmos DB Reviews

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.

The main use case for Microsoft Azure Cosmos DB is as a key-value store where we store all the user data that we have and perform lookups. We use it at a significant scale, with storage of unique data reaching 12 terabytes and handling up to 3 million requests per second.

The scalability of Microsoft Azure Cosmos DB has significantly aided us in managing workloads efficiently.

We were able to realize the benefits of Microsoft Azure Cosmos DB immediately after deployment, making it quite easy to get started.

The most valuable features of Microsoft Azure Cosmos DB include the TTL, the ability to scale up and down as needed, and geo-replication, which comes out of the box. We do not have to do anything for geo-replication. We just have to enable it.

The indexing policy is also very good, and the overall metrics and monitoring system are also quite good.

Microsoft Azure Cosmos DB is fairly easy to use.

Microsoft Azure Cosmos DB can be improved by providing more fine-grained control over certain aspects, such as connections and threads. There could be more control over how many connections are made. I am not sure if it is a knowledge gap issue. A regular connection with the Azure Cosmos DB team might help in addressing knowledge gaps. Being able to fine-tune these features would be helpful for us.

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

Over the last two years, Microsoft Azure Cosmos DB has been very stable. It has very good latency and availability. Latency is good on the server side and the client side. We have had only one significant issue that affected our production system. Overall, stability has been excellent.

The scalability of Microsoft Azure Cosmos DB is one of its best attributes. We can scale very efficiently and adjust workloads as needed, which is more challenging with other systems.

We have contacted their support many times. The quality of customer and technical support has improved over the years. Initially, it used to take quite a while for issues to be resolved, but now the support is seamless and very efficient. We have not needed much support in the last couple of years due to the system's stability. It is pretty stable now. I would rate their support a nine out of ten.

Positive

I have used Redis briefly and Aerospike extensively before switching to Microsoft Azure Cosmos DB.

Both Microsoft Azure Cosmos DB and Aerospike have their own advantages. The biggest advantage of Microsoft Azure Cosmos DB is that it is very easy to get started with and it does not require too much effort. It takes just one click to deploy Microsoft Azure Cosmos DB and put it into multiple regions. It does not require too much maintenance, whereas Aerospike requires a lot of maintenance effort. It requires a dedicated team. In this aspect, Microsoft Azure Cosmos DB is very good. However, Aerospike provides control over a few things, which we do not have in Microsoft Azure Cosmos DB. If we want to run or use the maximum amount of resources, Aerospike helps a lot. Both have their advantages and disadvantages.

The initial setup was easy. It was not difficult.

It took us a quarter to be able to use it efficiently. It is fairly easy and straightforward.

We had set up our own autoscaler. There was a pipeline that ran on top of Azure Cosmos DB to see how many RUs were provisioned. It did require a little bit of maintenance because we built custom software on top of that, but that was it. Our autoscaler performed better than Azure Autoscaler. However, because of some billing benefits, we have started using Azure Autoscaler. The Microsoft team said that if we used Azure Autoscaler, they would give us a discount, so we started using that, but our autoscaler performed better.

Initially, the deployment required an entire team, but now, it can be managed by a smaller team of two to three engineers.

It has decreased our total cost of ownership by approximately 20% compared to other alternatives such as Redis.

Its pricing is higher compared to solutions like Aerospike. However, it is justified because of the out-of-the-box features that are provided. The availability and resiliency that we have make it worth the price.

To new users, I would advise first knowing their data. They should know whether it fits their solution, which Azure Cosmos API to use, and what scale they intend to run it.

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

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.

Microsoft Azure Cosmos DB has helped improve the search result quality of our customers' organization. The customer gave us the feedback that they are able to easily find the data they are looking for. It is very quick. That is the best feedback. They have a large amount of data, and they can find it quickly.

Our customer is very satisfied with it. Our branch does not use it yet. We used it for a customer, and the customer is very satisfied so far.

There are no particular factors that need improvement. There is a little bit of a learning curve with scaling workloads, but it works smoothly.

I am still learning it and have only used it for one application so far. 

No issues have been reported regarding the stability. It is very fast.

There was a little bit of a learning curve with scaling workloads, but overall, it went smoothly.

I have not had any challenges. However, the configuration done in a session at Microsoft Ignite looked complicated. It would be a bit challenging to do the same configuration. 

There is a little bit of a learning curve. The onboarding process for the team took about two weeks.

The only feedback the customer gave us was that it was way cheaper than they expected. 

The customer had a high budget, but it turned out to be a little bit cheaper than what they expected. I am not sure how much they have spent so far, but they are satisfied with the pricing.

I would recommend this product. I would like my organization to develop and explore it further. I would rate Microsoft Azure Cosmos DB an eight out of ten.

Cosmos DB has multiple use cases. For instance, we recently developed a custom application for a customer in India. We used Cosmos DB to store data fetched from the initial front end to reduce access times to the application, which is significant for improving user experience. 

For example, when creating a virtual machine through our custom portal, it is essential to check whether a VM with the same name exists in the same or a different subscription. 

Additionally, we needed to enforce naming conventions and limitations on the number of VMs that can be created within the same network. These conditional parameters were managed using Cosmos DB, allowing the initial provisioning process to validate data and configurations instantly. 

This enables us to inform the user right away if there is a duplication or if the creation adheres to predefined rules, offering suggestions based on the UI. This demonstrates the real-time application and benefits of Cosmos DB.

We use Cosmos DB for its key-value storage capabilities. For structured data, we always use SQL Database.

The low-latency data access provided by Cosmos DB improved application performance.

Application performance improvement depends on what kind of optimization you're looking for. Do you want to improve latency or efficiency? Performance tuning depends on that specific goal.

Here's an example: A customer with an application running in an internal system noticed their outbound data flow and charges increasing every month. They were exporting a lot of data for users in Excel format, which was heavy.

I suggested they export the data in CSV format instead. It's lightweight and users can still open it in Excel. This optimizes data usage and costs without compromising user experience.

Cosmos DB now supports unstructured data. It's a key-value store, so we can send data without worrying about strict structure, data types, and so on. Since it's unstructured, it's lighter than a structured database.

We use Cosmos DB for its key-value storage capabilities, while SQL Database is used for structured data.

There is room for improvement in terms of stability. 

I have been using it for a year. 

In my experience, Cosmos DB is definitely stable. But, for any service or application, I wouldn't give it a perfect score. There's always room for improvement. A perfect score would mean no room for improvement. So, I always consider some buffer for improvement.

I would rate the stability a seven out of ten.

Since it's a managed service, Azure backend handles scalability. From a user's perspective, we don't need to worry about scalability.

Right now I'm dedicated to customers of one of India's largest certificate authorities, Reliance Jio. They have a lot of customers and two dedicated Azure data centers in India. I focus on those two data centers, and I see at least 10 to 15 customers heavily using Cosmos DB there.

From the user's perspective, it's a managed database service, so all scalability is managed in the backend. Users shouldn't worry about scalability itself, but they might need to consider if paid region support is needed or if other regions are available. Otherwise, scalability shouldn't be a concern for them.

But if you're configuring Cosmos DB in a non-Azure solution, you'd have to manage scalability yourself. In that case, you'd have to be more conscious about it.

We have dedicated technical support in India for each Azure service, including Cosmos DB. Since I provide the framework, design, and initial implementation, I'm involved in most calls to ensure everything is deployed as designed. 

But for any issues or troubleshooting, there's dedicated support that gets involved and fixes them. I also stay engaged with the product team.

The product team is very proactive.

Positive

I predominantly work on Microsoft SQL Database, among others. Sometimes, we use Cosmos DB for specific adaptations or APIs within Azure.

We've also assisted some customers in migrating from MongoDB to Cosmos DB.

If you're familiar with it, it's not complex at all. But for someone new, it can be a little tricky.

Cosmos DB itself is a cloud-based solution. However, I'm currently working primarily with a hybrid solution: Azure Stack HCI with software-defined networking for the environment.

We don't directly deploy Cosmos DB itself; it's a service within Azure. We use our DevOps pipeline to deploy the entire environment, which includes the application, database, environment (including the virtual network), and any connected service endpoints. 

Everything gets incorporated into the provisioning source or the DevOps pipeline and then deployed from there. It's a pretty streamlined process for us.

If the cost is affordable and you're looking for a managed service for unstructured data, I would definitely recommend using Cosmos DB from Azure. It also has seamless migration options from MongoDB, MySQL, and others. 

So, a managed service is the best way to go if the cost is affordable.

Overall, I would rate the solution a seven out of ten. 

Our company uses the solution to develop a certain sort of products for our internal companies. We have some child or franchise companies and are developing software for them. 

We use the solution where transactions display to provide views or reports for the console. We also use the solution for an online learning application or portal. 

We have 20,000 to 30,000 users across multiple products, franchise companies, and customers at the backend. Centralized data is global and accessed from all over the world including India, the US, South America, and Asia. 

We have several new projects with the same backend, so our user volume will definitely increase day by day. 

The solution's read capacity and write access functions are very fast so users don't have to wait when fetching or displaying data on a screen. The main feature of an application is how it behaves toward the user. Users get uncomfortable when having to wait a long time. The solution's high-value data processing helps application performance data. 

The solution easily integrates with the Microsoft cloud and other Microsoft products like Azure Active Directory. We use cloud storage for databases so this integration is very beneficial. 

The solution cannot join two databases like Oracle or SQL Server. Joins have to be done programmatically through our sysHUB. We use .NET code so need the middleware to join databases. 

There are certain restrictions for inner classes or employee roles. 

Data retrieval is slightly more difficult than in SQL Server or other SQL databases. 

Documentation needs some improvement to help end users. Documentation for joining includes some generic or peculiar cases but needs to be more comprehensive. It should lay out how to join databases and what procedures to use. 

I have been using the solution for more than three years. 

The solution is stable. We haven't received news of any issues with platforms.

Stability is rated a nine out of ten. 

There are a lot of things we still have to fight out such as joining databases. Most probably for the high-transactional use cases, the solution cannot be used at all. 

Currently, scalability is a seven out of ten. 

Our infrastructure team handles all communication with support and reports that they are good. We have a premium account with Microsoft so support always helps us. 

From 2009 to 2018, we used Oracle at our company. We switched to the solution for various projects due to the needs of users. We needed a product that met our business and users' requirements with the lowest cost possible.

The setup is very easy so I rate it a nine out of ten. 

In the initial days in 2018, setup was uncertain and coding was needed from our side. Now, we use the library to access the database or read and write. Things become so much easier over time. 

Two members of our core infrastructure team handle all implementations. 

On average, deployments take three to five hours. We have to deploy the DevOps side and the data backup. If we consider all things, deployments hardly take a full day. 

The solution doesn't require any ongoing maintenance. 

Obviously, we want to be on the profit side as a business or we can't grow. Money and usability are the most important things for us. 

The solution has already realized some ROI. The pay-as-you-go usage methodology helps us because it saves money. 

At this point, I rate ROI a six out of ten. 

Pricing is one of the solution's main features because it is based on usage, scales automatically, and is not too costly. As usage scales up or down, the price moves accordingly. 

For example, we might have 30,000 users and the requirement is high so the solution automatically scales up. If the requirement lowers because the application isn't being used all the time, then the usage automatically grades down and so do our costs. 

Technical support is included as a free service.

I rate pricing a seven out of ten.

We still use Oracle for some projects but it is costly to acquire. 

We are using SQL Server for an ongoing project. 

The solution is less expensive than Oracle, especially with all of our DLLs. It is easier to work on from a developer's perspective and we realize a good cost savings. 

We choose the best database based on a customer's budget and need. 

Everyone can use the solution where the database hits or the transactional data is placed. 

The solution is not a good fit for companies in the banking industry who have a high volume of transactions every second. The solution always needs a proper SQL database like Oracle.

Companies with non-transactional applications must use the solution because it helps users and achieves a lot of success in terms database costs.

I rate the solution an eight out of ten. 

We are streaming some data from Azure Stream Analytics, which will be stored in Microsoft Azure Cosmos DB. Our application will be taken from Microsoft Azure Cosmos DB.

The solution's most valuable feature is its global distribution. We work globally and currently have Azure operating in fire regions. From a global distribution perspective, Microsoft Azure Cosmos DB is good and easy to handle. Since Microsoft handles the solution's main operation, we don't have many headaches regarding its operation.

The solution’s pricing could be improved.

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

Microsoft Azure Cosmos DB is a stable solution.

I got instant technical support from Microsoft during an outage issue.

Positive

We use Terraform scripts for the initial setup of the solution, which doesn't take much time.

We implemented the solution through an in-house team. We select which region to host Microsoft Azure Cosmos DB based on the resource group. We use Terraform scripts in the deployment process. We create a database and a document inside the database.

The solution is pretty good in terms of support, but we have some pricing issues with it. We are currently evaluating MongoDB and Apache Cassandra. Apart from the pricing, we didn't face any issues with the solution. We once faced an outage issue with Microsoft Azure Cosmos DB because some back-end updates from Microsoft changed the settings.

Microsoft Azure Cosmos DB is a cloud-based solution. Based on our experience, the solution is pretty good because we operate in multiple regions. There will be a lot of machines sending IoT data, dashboards, and alarm messages. Customers need to be updated simultaneously, which should not take much time. The solution's processing is pretty good.

I would recommend the solution to other users. The solution's usage is pretty good, but users should be careful about the IO threshold value, which is a little bit high.

Overall, I rate the solution eight and a half out of ten.