Microsoft Azure Cosmos DB Reviews

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.

Microsoft Azure Cosmos DB can be used for various purposes. The query language used for Cosmos DB is very similar to SQL, which gives it an advantage. It's a globally distributed multi-model database service, meaning it supports multiple data models, including documents, key-value pairs, graphs, and time series data models.

It's highly scalable and supports consistency, security, and multiple security options, such as REST and transit encryption. It also provides automatic support for these options. These are some top-level benefits of using Cosmos DB, making it a highly versatile and useful tool.

The multi-model database is the most valuable feature. 

One thing that concerns me is the cost, especially for smaller workloads. Cosmos DB is a little more expensive than other database services, particularly if you have tight-traffic models. However, it does have a few advantages, such as being a multi-model database. The biggest problem is the learning curve and other database services like RDS. 

Additionally, advanced analytics capabilities like real-time analytics and machine learning are not embedded in Cosmos DB. Vendor lock-in is a big concern. Cosmos DB is a proprietary database service offered by Microsoft that might not be compatible with other databases. 

I have been using this solution for three years. I am using the latest version.

From a stability perspective, it's a pretty robust solution designed to offer high availability and fault tolerance. It provides multiple levels of redundancy and automatic failover to ensure data availability and reliability. 

It is a scalable solution and has built-in backup and recovery capabilities. We developed it for one of our clients with around 20-25 users.

When compared to other cloud platforms like GCP and AWS, I think Microsoft needs to work on its tech support.

There is some learning curve associated with this software. It becomes relatively easy to implement if you have an expert to work with. 

The deployment process and maintenance depend on the size of the product and what you're trying to migrate. Generally, one cloud solution architect and one big data developer with Azure experience should be sufficient.

We could see an ROI. The whole idea of migrating to the cloud was for a better ROI, and we can see that now that the customer has moved to the cloud.

As your data grows, the licensing cost can be expensive.

If your existing infrastructure already uses Microsoft services or is more of a Microsoft-dependent solution, it's best to be on Microsoft Azure cloud. This is because it integrates very well, and there is a smooth integration with other Microsoft products that are already running on our products. 

You can also leverage some of your existing licenses, saving you a lot of costs when you move to the cloud. That's one solution I would suggest for anyone who is moving from on-premise to the cloud. 

Overall, I would rate the solution an eight 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.

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 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 use Cosmos DB for geolocation identification.

If you pass by a market on the street, it sends me your location. My application will then send you a personalized notification about relevant products you can buy at the market.

The best feature is the velocity of making queries. 

I would like to see better documentation for this solution. 

The pricing of the solution should be reduced. 

I have been using Cosmos DB for one year. 

I would rate stability an eight out of ten. 

I would rate scalability a five out of ten. 

I would rate technical support a ten out of ten. 

The initial setup is straightforward. It's very easy to start a function or application with Azure. 

The solution is very expensive. 

I would overall rate the solution an eight out of ten.

We use Microsoft Azure Cosmos DB for faster databases.

The most valuable feature of the solution is that it is scalable with multiple master files. The performance of the solution is also good.

Microsoft Azure Cosmos DB's pricing model is complicated, which people don't understand. So, the pricing model should be improved.

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

Microsoft Azure Cosmos DB is a stable solution.

Microsoft Azure Cosmos DB is a highly scalable solution, and 15 to 20 people use the solution in my organization.

I rate Microsoft Azure Cosmos DB’s technical support an eight out of ten. They do take some time to get to the root of a problem.

Positive

The initial setup is straightforward and needs a few tools to upload.

We have had an ROI with the solution.

The pricing model of Microsoft Azure Cosmos DB is a bit complex.

We are using Microsoft Azure Cosmos DB as a cloud-based solution. Two admins and one manager are required for the deployment and maintenance of the solution.

New users must keep an eye on its pricing models and configure them properly.

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

Primarily, people do not have a clear understanding of the cloud and cloud services. Customers are a little bit scared about taking their data onto the cloud, and they think and they assume that it is not safe. So we just make them understand that databases or services on the cloud are more secure than on-premises infrastructure.

The performance point can be improved because when we run a search query on our on-premises machine and develop connectivity, a response comes in. But sometimes, the response gets delayed, and it can be due to network latency or something else we are yet to figure out.

Performance and high availability are two features I want to be added in the next release because that is the basic requirement of customers. Mostly, we have customers with the bank and banking institutions, and they want their databases perfectly integrated with the high availability feature.

I have been using Microsoft Azure Cosmos DB for less than a year.

It is a stable product. I would give it an eight out of ten. 

It is a quite scalable product. I give it a nine out of ten. There are more than ten users using this product. 

The initial setup was difficult. I would give it a six or seven out of ten.

The pricing depends on the budget allocated to the client; for some, it can be high, and for some not high. But mostly, when the prices are moderate, they are not very high. I would rate it a seven out of ten.

It's a highly scalable, highly robust, and very user-friendly solution. It is easy to set up; the most important point is that it is on a cloud. The solution is also very easy to deploy. Only some connectivity features need to be developed.

I give it an eight out of ten.