Microsoft Azure Cosmos DB Reviews

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

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.

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 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 mostly use it for NoSQL use cases. We use it for web applications, mobile applications, and social applications in the financial sector.

It is deployed on-premises and on the cloud, and we are using its latest version but not the one in the public review.

Its wide support to the ecosystem is valuable. We can use this database with a lot of use cases, and that's one of the reasons why we prefer it. We have a lot of vendors, databases, and use cases, and wherever possible, we are trying to standardize databases. It is also secure.

At this stage, we would like more enterprise support. We use MongoDB a lot, and we're trying to get rid of MongoDB. So, I would like to see more features in the Cosmos DB API for MongoDB space.

I have been using this solution for almost two years.

It is stable. It has 99.999% availability, and it is backed by SLAs.

We have thousands of users.

We use the cloud version and the on-prem version. We have our on-prem database engineering team. For the cloud, we are okay with their support.

We use MongoDB a lot, and we're trying to get rid of MongoDB.

It is easy to install. I tried it in a testing environment, and it was easy. Database experts should be able to do it easily.

For the cloud, we don't pay for the license, but for the on-prem versions, we do pay.

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

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.

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.