Microsoft Azure Cosmos DB Reviews

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. 

In my role, I use Microsoft Azure Cosmos DB fairly extensively across various platforms. At ASOS, we utilize it for order processing to record incoming orders and for commercial integration platforms. Overall, we have numerous use cases.

Overall, Microsoft Azure Cosmos DB is easy to use.

Microsoft Azure Cosmos DB has provided benefits compared to SQL databases, particularly in terms of availability.

Microsoft Azure Cosmos DB has helped to improve our total cost of ownership.

Microsoft Azure Cosmos DB offers a relatively easy learning curve due to its limited programming service area compared to SQL Server. This streamlined functionality allows users to quickly grasp the SQL query language.

The autoscale feature is the most useful for us.

There should be parity between the various APIs. I often work with the Mongo API, and features for it sometimes lag substantially behind the core API, such as the Analytical Store feature. Additionally, I am waiting for the full fidelity change feed that would surface all changes, including deletes to documents.

While Microsoft Azure Cosmos DB is generally easy to use, it has some limitations. Certain areas are more restrictive, and we are awaiting features that will simplify development. For example, currently under development, the full fidelity change feed will expose all document changes, enabling tasks like synchronizing collections while accounting for deletions. This is challenging because the existing change feed doesn't provide information about deleted documents.

I have been using Microsoft Azure Cosmos DB for around seven years.

Cosmos DB demonstrates good stability and great reliability, with technical issues arising approximately once per year.

While Cosmos DB offers good latency and availability, careful consideration must be given to selecting appropriate consistency levels.

The scalability is excellent, and as long as the data can be partitioned, the scalability is nearly infinite.

Cosmos DB's ability to scale workloads is a significant advantage, as evidenced by our successful management of multiple terabytes of data without encountering any issues.

The quality of customer service and support varies. We always get an answer eventually, but the speed of resolution depends on the reason for the support ticket. If there is a bug in the product, we have to wait for it to be fixed.

Positive

The initial setup of Microsoft Azure Cosmos DB is straightforward. Even someone with no experience can easily deploy the solution.

The deployment can be completed by one person on the same day.

The deployment can be done entirely in-house. Whether we are doing it manually in the portal or deploying it through Terraform, it is straightforward. We do not require help from an integrator or consultant, although there are considerations about partitioning collections when creating resources.

The pricing for Cosmos DB has improved, particularly with the new pricing for Autoscale. Previously, we were charged according to the busiest partition across all regions, but now, each partition is only charged for what it uses. This change has substantially reduced our costs.

When evaluating new projects, we determine whether data storage is best suited for a relational database, such as Azure SQL Database, or a non-relational database like Cosmos DB.

I would rate Microsoft Azure Cosmos DB eight out of ten.

Understanding some of the subtleties of Microsoft Azure Cosmos DB can take time, and some individuals at ASOS still find concepts like partitioning unclear. However, getting started with Cosmos DB and developing functional applications is quick and can be achieved in a short timeframe.

We require minimal maintenance to validate that we've configured, for example, the correct indexing policies as required by our queries.

New users should make sure they understand partitioning because once it's selected, it is difficult to change it. Otherwise, you would need to migrate everything over to another collection.

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.

We use it as a data storage platform for several proprietary applications that we have designed and built and now support. We generally use it to be able to scale so that our customers can search a sizable amount of data. We have millions of records that include an extensive amount of text.

We implemented Azure Cosmos DB for our tokenization process. We had originally built a data dictionary to be able to tokenize different words within our MongoDB collection, but over a period of three years or so, we found that there were some limitations to doing that. The data dictionary needed to be updated, so we turned to the vector search feature because it essentially allows us to measure the similarity between words. Those sorts of comparisons could be done very easily. There is the ability to tokenize words, which we then use in the search functionality provided for the users of our applications. It has helped us improve the search functionality of our applications.

I landed on it as an architectural component of one of our first solutions. I went in expecting its benefits. It delivered the benefits of being able to quickly scale and being able to support semi-structured, unstructured, and structured data sets or data properties. All of these aspects are supported. We were able to realize its benefits early on.

We have used the vector database with Azure AI services. It works fine. They are embedded vectors. We are running some text through Azure AI. It then returns these embedded vectors, and we store those. We are able to use those vector values or vectors to determine the similarity between various words that are being searched in our applications.

The Azure Cosmos DB's ability to search through large amounts of data is excellent. It is fantastic. We have benefited from it. It is great.

There are a number of different APIs or data storage supported in Azure Cosmos DB. Specifically, we are using the MongoDB API, so we leverage it in that way. I like the flexibility that it offers. My team does not have to spend time building out database tables. We can get going fairly quickly with being able to read and write data into a MongoDB collection that is hosted inside Azure Cosmos DB.

I found it very easy to use. We have been using it for five years, so it is quite flexible for us. The ease of use is quite high for us.

It is easy to use, but optimization has been a mixed experience. It has been more of trying to figure out how to do so. We have not found much support there, so we have to come up with our own way of optimizing it in different ways. That is one area of improvement. We would like to have more tools that support the optimization of Azure Cosmos DB. There are not many tools out there. We have had to develop our own tools internally, such as a clean plan or query plan, and look at the index usage, throughput, and those sorts of things. The portal experience for optimizing and monitoring the service needs a few enhancements.

I am looking at it through the lens of MongoDB API. There are four or five other APIs that are supported in Azure Cosmos DB. The MongoDB API experience could be improved substantially by having a more user-friendly set of administrative tools so that I can go out there and query the documents that are part of the collection. Currently, I am working around that by using third-party tools like 3T. I also use MongoDB's Compass client tool. They can make this part of managing the database or the collection a lot easier by providing some built-in toolsets, similar to what is offered by Azure with Azure Data Studio. That is a big area for improvement. 

We should also be able to better manage the cost. There have been some improvements there, but there is still room for improvement in terms of how costs are managed through the Azure portal relative to Azure Cosmos DB. To me, it is one of the more expensive services out there depending on how it is being leveraged.

One of the key limitations is that only so many vectors can be supported. It does not work very well with the large amount of text that has to be embedded in the vectors. That is one limitation we have run into with the feature set.

It has been five years. 

The SLA is pretty good. We have been able to at least get past 99.9%. We are probably closer to 99.99%. So, overall, it has done well over the five years. Just like with most things, there were a few instances where it crashed or was not available. Those instances are memorable, but they are few and very far apart.

Its latency is good. The availability is also good.

Its scalability is good. However, redundancy does not work very well. Redundancy is having a set of backups. It is also a part of high availability. We have used some of the redundancy features in Azure Cosmos DB, and it created problems for us consistently. We recently had to move away from having a redundant copy of the data and just having a single copy. Of course, we have adequate backups.

Through the lens of MongoDB API, the scalability can be better. However, the limitations are core to the actual platform. MongoDB is not designed to scale horizontally, so that is how Azure offers it. It scales vertically which means that I can go and request more compute and more memory RUs for the instance that I am using. If I was supporting multiple workloads that had different read/ write patterns, it would work, but it is not designed to do that well at its core, as I understand it. It is less of a function of Azure Cosmos DB and more of a function of MongoDB itself.

The dynamic scaling has helped decrease our organization’s overhead costs. We are able to scale up during business hours, or when there is demand, we scale automatically. There are some tools that we have built and some processes that do that. We can also scale down during non-business hours or when the demand drops for the database or the data store. It has helped to manage scaling costs.

I contacted their support this year when we had some issues. When it comes to customer service, it always comes down to the person you get on the phone or who picks up your ticket. 

Regarding Azure Cosmos DB, we felt frustrated when we needed that support from Microsoft. It has not been there because the things that we are dealing with are generally more complex than most customers would have to deal with. At times, the representatives or engineers we got or who picked up the tickets we submitted did not have the breadth of experience needed to support us or resolve the issues. So, we resolve the issues ourselves the best we can.

Negative

We use some of the alternatives because it does not solve everything. There is no such thing as one perfect data store. We use Azure SQL instances. We use SQL and VM in Azure. We have started doing a lot more Postgres, which is the flavor of the time. Everybody seems to be moving to Postgres all of a sudden.

Synapse is another tool. It is another Azure service that we use. It just depends on what type of data we are using and what makes sense in terms of the implementation of the application. Those are some of the alternatives that we have used.

Its deployment is easy. Setting up the service is easy. You make a decision around where you want to deploy and those sorts of things. There is a lot of pointing and clicking. That was very easy.

Taking it to production was a lot harder. It was a lift to get the data loaded into Azure Cosmos DB. At the time, there were about 750,000 resumes that we uploaded for a customer, so it took a lot of time. We had to build a custom app to load those documents on data records into Azure Cosmos DB. We had two people working on it for two weeks. We probably spent somewhere around 60 hours around the lift to get that all loaded up and going in Azure Cosmos DB.

It took us about 18 months to feel fully confident in working with this and reach a level where we can go and teach others. We feel that we have got a firm grasp of the service after about 18 months of production support.

Its maintenance has been taken care of by Microsoft. However, at the end of last year going into this year, there were a few disruptions with the service that hampered our customers or users. There have been times when the service went down, or the service was upgraded but the SDK or NuGet packages used to support or connect to Azure Cosmos DB were not in sync. Overall, Microsoft takes care of the maintenance.

It was all done in-house. We had two people involved in it, myself and my lead developer. It was mainly about loading data into Azure Cosmos DB. That was a big lift.

Azure Cosmos DB helped decrease our organization’s total cost of ownership. It is hard to provide the numbers, but managing the data store is easier for us with Azure Cosmos DB with the MongoDB API because there is no need for a DBA. We do not have a DBA on the team who is just taking care of the indexes and making sure that the database is healthy. It pretty much just runs. If we had a DBA in the team specifically for MongoDB, we would be paying about 150,000 dollars a year. We have to somewhere in the neighborhood of 50,000 dollars for the service in Azure. In terms of the total cost of ownership, it saves us about 100,000 dollars.

Pricing, at times, is not super clear because they use the request unit (RU) model. To manage not just Azure Cosmos DB but what you are receiving for the dollars paid is not easy. It is very abstract. They could do a better job of connecting Azure Cosmos DB with the value or some variation of that. 

Overall, I would rate Azure Cosmos DB 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.

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.