Microsoft Azure Cosmos DB Reviews

We would have the product at the edge, passing it off to another service like Postfix. It was a platform that allowed us to sell a service to customers, enabling certain clients to email us securely. We used it to take everything through email security, which included policies allowing specific emails from certain domains.

It provided a platform to sell a service to customers.

The logs are easily readable and help diagnose problems, although they can be difficult to find initially. The solution addresses our email security, but for the rest of our security, we would use multiple vendors. It covers everything through email, like antivirus, IDS, and IPS. 

We've got policies that only allow us to receive from certain domains and emails within those domains. We pass that on to Postfix. That sorts out anything attachments-wise. It eventually goes through a Palo Alto firewall for the traffic. Anything malicious is picked up across all of the vendors in that solution.

The user interface needs massive improvement. While the device works fine and it's not complicated to write policies, renaming menu items and showing policy flow in conjunction with the application could help.

I used the solution for about seven years.

Considering it was a Cisco C170 before I joined the company, it had hardly any issues with the IronPort.

Cisco's tech support can be hit or miss, depending on the engineer you get. But ultimately, if there's an issue, we can contact the account manager or another engineer.

We did not use a different solution before this one. We chose Cisco Email Secure because we're a big Cisco house with familiarity with the product stack.

I personally did not see any form of return on investment, as I am just an engineer.

The licensing is a mess and needs sorting out. I am not really concerned about the pricing because I only make recommendations, not buying decisions.

I would rate Cisco Email Secure about seven out of 10. Get used to the user interface and always click the save button to ensure changes are applied. 

I am building an extension app for DocuSign. One of the ways for me to demonstrate this is by using a third-party database. I read and write data from Cosmos DB using DocuSign tools.

We wanted to use Azure function apps and Cosmos DB because Cosmos is serverless and non-relational, so it's easy to set up and simple to scale up and down. Overall, it was a good fit. 

I like the way you can create and delete records. You pass a JSON, and then it creates a record. It is easy to use because you don't need to know much about Cosmos DB or have prior experience. 

Cosmos DB does a pretty good job of searching. I've never had trouble as long as I search for a unique key or value I'm looking for. If my query is right, it returns the value.

Once you create a database, it calls the container, and then items show up. A better description and more guidance would help because the first time I created it, I didn't understand that a container is similar to a table in SQL. 

I have been using it for six months.

My use case is like a proof of concept, so the data set is not extremely large, but I know from reading about it that it can scale up well. It should do a good job on large amounts of data. 

The initial setup was simple the first time I used Cosmos DB. It took just a few hours for my small technical team to get used to how Cosmos DB works.

The pricing model has aligned with our expectations. In Azure, setting it as consumption-based or serverless keeps the cost low, but we had instances where automation increased the cost significantly. It was more of a configuration problem, where options to keep it minimal are still present.

We wanted to go with Azure function apps and Cosmos DB to keep it serverless and non-relational, making it easy to set up, scale up, and down.

I rate the product as eight out of ten.

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.

We handle JSON data and it is compatible with Microsoft Azure Cosmos DB. 

I have found Microsoft Azure Cosmos DB different from other SQL databases like RDBMS. It is non-SQL and helps to manage and manipulate data from the coding, rather than direct data and complex queries. It is quite flexible and offers a complete concentration on the coding part only. Even if one lacks expertise in complex queries, JSON and Microsoft Azure Cosmos DB are quite compatible with each other and makes the database options more enhanced and easy to operate. The additional SQL features allow you to go to Azure's portal and get the queries solved. 

I have been a devoted Microsoft fan, but Redis DB's memory caching capabilities are really making progress. Even if Cosmos DB is continuously improving and is quite advanced in the field of internal memory optimization, I would still recommend Redis DB to a customer. My dilemma still lies in the price of both solutions. I believe if Redis DB is superior and pricier than Cosmos DB, customers will be reluctant to use Redis DB.  

Memory streaming and various optimizations contribute to higher costs but also increased speed. Currently, there's nothing specific I can pinpoint that needs to be added – I haven't made any purchases yet. However, I am inclined to recommend working with it. 

I have worked with Microsoft Azure Cosmos DB for one year.

It is a stable solution. I rate the stability a nine out of ten.

It is a scalable solution. I rate the scalability a nine out of ten. 

We haven’t faced any issues that would make us contact service support or raise tickets

Positive

The solution's initial setup is easy. The deployment took almost one day. We migrated the services from the CRM system, converted them into JSON, and deployed it. I would rate the initial setup an eight out of ten. 

If a customer needs to store JSON data, and the solution doesn't require complex structure and reporting like BI reports and RDBMS, opting for a NoSQL database could be ideal. NoSQL databases are suitable when data isn't structured in a relational manner and when extensive normalization isn't a priority. For efficiently handling JSON data for UI purposes or other needs, a NoSQL database like Cosmos DB is the way to go.

However, in the NoSQL landscape, various options like Redis DB, CouchDB, MongoDB, and Cosmos DB exist. If a preference leans towards Microsoft technologies, then Cosmos DB becomes a logical choice. Comparing Cosmos DB with alternatives like Redis DB is advisable before making a final decision. Thus, my typical recommendation involves considering these factors.

I would 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.

At the end of the day, Cosmos DB is a database. It is a wrapper over different APIs.

We use Cosmos DB both internally and with our customers. Our internal use is quite extensive. The usage with our customers depends on whether it is an approved technology within their ecosystem.

Because Cosmos DB uses multiple APIs, it is the go-to database for us internally.

Cosmos DB makes life easier because if we want to use Mongo-type data, or Cassandra-type data, or maybe even just a simple cable storage-type data, then graph, there are multiple ways to do this. With Cosmos DB, we can put together a holistic solution when it comes to Azure security policies, Azure Monitor, and access control.

By design, Microsoft Azure Cosmos DB provides multiple APIs. You have to decide where to write to. Will you write to Excel, Word, PPT, or OneNote? You have to do the homework properly. If there is no tool, then there will be no provision, then there is no database.

I would like to see Cosmos DB introduce a feature that would convert machine language to human-readable queries. For example, if we want to generate a simple diagram that shows the relationship between devices and how frequently have they failed at various locations, we have to consider that the IoT data that is put into Cosmos DB, called byte codes, is not readable to humans. This is a machine language type of data. So when we push that type of data it looks like gibberish, because it is not meant for us, meaning we can't write a normal query. We have been asking for years for them to work with the IoT partner to provide a feature to convert the machine language to readable human queries.

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

The solution is stable. I would give it a five out of five for reliability.

The architectural decisions will tell you how the scaling will happen. 

Scalability is based on the requirements that are set. Configuration decisions can be implemented pretty fast, so the solution scales well. We are predominantly in the US and India, so it is easy to decide which geographies we need to have and which data we need to synchronize. 

For some of our customers, there are data residency rules like the UAE for example, where patient data must stay within the UAE, making it only one geography. When this is the case, we go for multiple replicas. 

Internally, we have more than 150 developers who use Cosmos DB. Overall, the scalability of the solution is a five out of five.

Product support is pretty good. They have a very good roadmap and the team provides regular patches and regular service updates, and they have a very good release plan.

Microsoft's technical support is good, I rate it a five out of five.

Positive

The initial setup depends on the type of setup you require. You have to design it properly. The architects need to do some homework to ensure the purpose and the requirements are clear. There are many design decisions that must be made first. Once those decisions are made, the initial setup is quite easy. 

Deployment of the solution was completed within a week.

Overall, I would give the solution a four out of five for ease of setup.

The deployment of Cosmos DB was completed internally, we managed it ourselves.

The cost is intricate, the calculator is complex because the cloud is all about counting every penny. It may look like small numbers, $0.001 per GB per day, but when we are talking of terabytes of data per day and the numbers will stack up. One month, we had over 500 terabytes. That's why you need a database expert to design it carefully and spend ample time number crunching. If done properly, the ROI will be good.

I would rate Cosmos DB a four out of five in terms of ROI.

Cosmos DB is expensive compared to any virtual machine based on conventional RDBMS like MySQL or PostgreSQL. The reason it is expensive is that it is scalable, reliable and there is no latency. So while Cosmos DB is considered expensive, what a lot of people miss is that the cost includes reliability, scalability, and responsiveness.

Cost also depends on the number of databases, number of replica locations, synchronization, number of queries per minute, and storage. Every client will have a different usage pattern. 

Overall, I would rate Cosmos DB a three out of five in terms of affordability. It is easy to over-provision, and it is easy to under-provision the solution.

Prior to choosing Microsoft Azure Cosmos DB, we did try other tools extensively. Because we have servers, we tried MongoDB, SQL Server, MySQL, and PostgreSQL. We settled on Cosmos DB internally because we didn't want to go for machines and trojaning. We wanted to adopt a platform as a service.  

Cost also ended up being a driving factor.

Overall, I would rate Microsoft Azure Cosmos DB a 10 out of 10.

We have a massive quantity of data that we need to maintain, and we can't put it in a relational database since we need all of the data and want it to be queried quickly.

We maintain it in non-relational databases such as Microsoft Azure Cosmos DB.

It's not a specific feature that I value, but the scalability of this system is the most impressive aspect.

The UI should be improved since if you provide the option to query directly when signing into the Azure portal, it makes no sense if you have such a poor UI for querying that you can't even feed the reports correctly. 

It should offer a simple user interface for querying Microsoft Azure Cosmos DB.

I have been using Microsoft Azure Cosmos DB for a long time, almost forever.

We are always working with the latest version.

It's fairly stable. I have no complaints about the stability of Microsoft Azure Cosmos DB.

Microsoft Azure Cosmos DB is fully scalable.

Users do not connect to Microsoft Azure Cosmos DB directly. Our APIs connect to Microsoft Azure Cosmos DB and are then used by the front end. 

Estimating the number of users is impossible.

Because our complete setup is in Microsoft, we have access to the most premium Microsoft assistance, available 24 hours a day, seven days a week. We have never had a problem with technical support.

The initial setup is straightforward.

The RU's use case determines our license fees. It fluctuates based on how many RUs we have. It's not a fixed-line.

Because our whole solution was hosted on Azure, this was the default option for us. We didn't look into any other possibilities.

I would recommend this solution to others who are interested in using it.

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