What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
For how long have I used the solution?
I have been using Cosmos DB for nearly a year.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and support?
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.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
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.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
We are considering changing from Cosmos DB to MongoDB.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Microsoft Azure
Disclosure: I am a real user, and this review is based on my own experience and opinions.