Microsoft Azure Cosmos DB Reviews

We use Azure Cosmos DB as our data storage or database technology platform, and we use it as the backing storage of our metering and billing back office system.

We have an energy metering and billing solution, a SaaS billing solution, which is responsible for the whole back office for district heating and cooling suppliers. Our platform is responsible for the ingestion of time series data, and at the end of the processes, we generate invoices, which are sent out to customers. On top of that, we provide a consumer portal where consumers can view their energy usage and consult their bills. 

They are two separate products, and both are using Azure Cosmos DB. The B2C or the consumer portal is using Azure Cosmos DB serverless because of its very spiky nature. It is very unpredictable how many users will be using the B2C portal, and the back office application is using Azure Cosmos DB with provisioned throughput with auto-scale configured, which makes it very scalable and still cost-effective.

The uptime is very good. Over the six years that we have been working with Azure Cosmos DB, it has not let us down even once. We never had any downtime with the service. There is a very high SLA. We do not use the multi-region scale and multi-region deploys, but what we do use is the availability zone setup on Azure Cosmos DB, so we have West Europe and North Europe paired, which makes it very cost-effective to have a failover to a different data center in the same availability zone on Azure. That is the most important part.

Its performance is outstanding. It is very fast. Its evolution and the approachability of the product team have also been good. I have been working with their product team for a while. They have sent over a lot of questions and we have had a lot of interviews, calls, conversations, and discussions on how to best approach certain architectural decisions. We can also discuss and understand how to adapt new features to our infrastructure or architecture to use those features to the fullest. I appreciate it. They are very reachable.

With regards to optimization, it might sometimes be a black box. It is not like SQL where you have indexes, for example, and you have a query plan with indexes, so you can set up and tune to improve your query performance. In Azure Cosmos DB, by default, everything is indexed, which can be good, but it can also be bad because it can impact performance. It is difficult to understand which indexes you really need. You have the basic indexes, all fields being indexed, but then you have composite indexes, which are not created automatically. You need to create them manually. It is difficult to get insight into what type of composite indexes you need, so there is some work there. On the other hand, you can easily follow the resource usage. You can monitor whether your databases are nearing their full resource availability. You either need to scale up or adapt auto-scaling. That is useful with regard to usage. If you are used to NoSQL, you should be able to get up to speed with that pretty fast. We use Azure Cosmos DB for NoSQL. That is a specific provider. We do not use MongoDB, Cassandra, and so on. That means that the syntax to query is SQL. You use a sort of SQL syntax, so the step is really small to go from a different NoSQL provider to Azure Cosmos DB. Of course, if you go from a relational database to a NoSQL database, that is a different story.

We could see its benefits immediately after we deployed it. Immediately after we started, it became very clear that it is very accessible and very user-friendly. It is a managed service. It is not like you set up a SQL and you need to do everything yourself. It is a managed service, and you have global distribution automatically. You set a checkbox, and you have a globally distributed database with high availability and continuous backups set up. It takes away a lot of the pains that you encounter as a startup company that needs to interact with enterprise customers. Our target audience is enterprise B2D customers who have specific requirements around data residency, backup and restore, high availability, and so on. Azure Cosmos DB makes it very easy to comply with those requests.

The flexibility and scalability are valuable. You have multiple models. You have serverless, and then you have provisioned throughput, auto-scale throughputs, and so on on top of reserved capacity possibilities where you prepay for capacity. I like that. It gives us a lot of flexibility. The scaling is instantaneous as well. You immediately have all the resources available. The fact it is NoSQL makes it powerful. 

Resource governance across tenants is something that requires some work. There is some room for improvement there. We are a multitenant solution. We decided to follow a certain approach in our architecture, which had an impact on the Azure Cosmos DB. There are multiple approaches to implementing multitenant architecture on Azure Cosmos DB, but there is still no single or best-recommended approach when you have a big variance in the size of your tenants. That is something that still needs to be worked on.

The monitoring aspect can also be better. There should be better monitoring of the costs versus the performance. That is sometimes difficult. It is easy to see or track performance monitoring and separately track your bill, but it is difficult to view the overall picture in terms of the relationship between the cost and the performance. That is something they still have to work on.

We have been using Azure Cosmos DB since August 2018. It has been a bit more than six years.

I would rate it a ten out of ten for stability. We did not encounter any downtime. We never encountered any drops in latency. It is a very stable product.

It depends on how deep your pockets are, but it is very flexible. If you have a good architectural setup, you can easily scale with it. Scaling is almost instantaneous. It is pretty flexible.

I have interacted with their support. If I have issues, I log a support request with Azure, and then it goes via Azure. If I have architectural questions and so on, I already have a lot of contacts within the Azure Cosmos DB product team. I can contact them to get a better understanding. They are very reachable. Most of the time, I get an answer within a few days. I would rate their support an eight out of ten.

It is a cloud deployment. Its initial deployment is easy. You set up the Azure Cosmos DB instance. It takes a few minutes. One person can definitely set it up.

The time taken by a team to be onboarded with Azure Cosmos DB varies. It depends a bit on whether the user has any experience with NoSQL or not. If he has experience with NoSQL, it would take a few days or months to get up to speed and understand how to use the platform in a day-to-day fashion. There are also advanced features and concepts. For example, if you are using SQL Server, not everybody understands to the fullest how a cluster index works behind the screens, but they do know how to use a query or how to write a query, so there is a difference. Writing a query and so on takes a few days, and that is it. Understanding the concepts of partitioning, such as logical partitions, physical partitions, scaling on those partitions, the quota requirements, high availability and so on might take a few weeks, which still is not that much.

Once you are used to the concepts of throughputs, scaling, or request units, it is easy. In terms of the learning curve as a whole, it is not the easiest, but it is right above it.

Its maintenance is all being taken care of by the Azure Cosmos DB team.

It is hard to say if Azure Cosmos DB helped decrease our organization’s total cost of ownership because we started with a greenfield application. We built something from scratch and immediately started using Azure Cosmos DB. However, there have been two features that have created an impact on TCO. These two features that were released helped to not increase our TCO in one-to-one correlation with the number of customers we have. We have the auto-scale functionality, which is two or three years old now. It made a big difference in the cost. The second one is the dynamic per partition and per region auto-scale functionality. We enrolled in it during a private preview, but it went GA just recently. That decreased the bill as well.

It is expensive. The moment you have high availability options and they are mixed with the type of multitenant architecture you use, the pricing is on the higher end.

We had a look at MongoDB but decided not to use it because the managed service of MongoDB was not so powerful compared to Azure Cosmos DB. You still have a DIY approach with MongoDB and you set up everything yourself, but as a startup, your resources are limited, so you do not want to spend time on setting up the infrastructure.

We also had a look at Postgres. I have a few options in Postgres to do NoSQL, but the actual NoSQL power of Azure Cosmos DB really makes a big difference. We could not find a better solution for that.

We do not use the built-in vector database capability. At the moment, we do not use anything for that. We do use all change feeds, all versions, and deletes to link with Microsoft Fabric to populate the data warehouse. We do not use mirroring yet because mirroring has a few limitations. That blocks us from using it.

Azure Cosmos DB has not helped us to improve the search result quality in our company. That is not something of importance in our application. It is an ERP application.

Overall, I would rate Azure Cosmos DB a nine out of ten.

We use it as our main database for our network access control software, and we use it to store all of the information we need to authenticate different devices and users to the networks of our customers. It maintains all of the necessary data for our SaaS product.

It is pretty easy to maintain and to optimize. The main thing that we have to deal with is the RUs. Probably the number one topic of Azure Cosmos DB in the world is how to make sure you have the right RUs set in place for each of your different collections, but the tools that are available in the Azure portal make it very easy for us to check how the performance is going. We can check if we need to adjust anything within the system to ensure that we have the right scale and the right split of our different indexes so that we are getting the most throughput for the data we need. In general, it is very easy for us to maintain. We just need to use the Azure tools to let us know when we need to pay attention to the different throughput variables that are important in the general maintenance of the product.

We use Azure AI Search for all of our search needs. The integration that Azure AI Search has with Azure Cosmos DB is very good. We heavily utilize the integration with Azure AI Search for a lot of the features on our website. The search works very well. I do not know if we have what one would consider large amounts of data because each one of our customers is searching through just their own set of data. On average, each customer has data in the range of only gigabytes, so the search does very well, but I do not know if you would consider what we have as very large amounts of datasets. We are dealing in the few gigabytes range rather than anything huge like terabytes.

The benefits of its global availability and the response time were noticed right away because we immediately had customers who were globally distributed, so the latency was noticed right away. We got a good performance that way. We did not notice any of the other benefits until we got a lot more customers and had a lot bigger scale. As our scale has increased dramatically over the past couple of years, we have noticed that we have not had to do much with Azure Cosmos DB. It just takes all of our additional data and additional queries and all of the additional throughput that we are throwing at it. It does not need very much in terms of maintenance and performance tuning because it handles everything we need pretty much out of the box, so it is a low-maintenance solution for us where we just check on things every once in a while as a best practice. In terms of scalability, we have doubled, tripled, and quadrupled our customer size or number of customers, and we have not had to do very much with it architecturally just because it has been able to handle that scale.

For onboarding, the documentation is very good. As soon as I joined the company, I read a lot of the Azure Cosmos DB documentation so that I understood it. It is well documented, and there are support forums and Microsoft experts. We have a Microsoft Solution Architect dedicated to us, and we have been able to ask him questions. The community surrounding it and Microsoft's ability to answer all of our questions, my questions specifically, have been really good. The documentation is great. I have been able to find all of my answers during my tenure. Everything is generally answered in the documentation, and for what is not, Microsoft has been very quickly able to get to us through our Solution Architect.

Within the first week, I was already executing queries against the database and monitoring its performance. Within a week, I had a basic understanding of how to interact with the database and understand different performance metrics and structures within the database. It is pretty easy to learn if you are familiar with other databases. Because I was familiar with other document stores and SQL-based databases, there was not a lot to understand. There are some differences in the SQL language that you are allowed to use with Azure Cosmos DB, so there was a little bit of a learning curve there, but the documentation was really specific. It is not a sharp learning curve if you are familiar with any other database systems. If you are familiar with SQL Server, MongoDB, MySQL, or Postgres, a lot of the concepts are exactly the same.

We chose Azure Cosmos DB initially because of the type of data that we needed to store. We have a schema that is very nondeterministic and flexible. It is always changing based on whatever data we need to acquire from different devices, so we needed a document store with a flexible schema. 

In addition to that, our customers are globally located, so we needed a database store that could be globally accessed and had minimal latency, good throughput performance, good query performance, as well as scalability. All of the things that you look for in a good piece of software about performance, scalability, high availability, and disaster recovery are available in Azure Cosmos DB. Because of that and because it is a flexible document storage, we went with Azure Cosmos DB.

The one thing that I have been working on with Microsoft about this is the ability to easily split partitions and have it do high-performance cross-partition queries. That is the only place where either our data size or our throughput has grown beyond one partition, so being able to do cross-partition queries efficiently would be my number one request.

The request unit architecture that they have in place is understandable but could be better. What you get out of some solutions like SQL Server or MySQL is a lot more understandable. The request unit architecture of Azure Cosmos DB is not as easy as pure SQL solutions. They could do better in making the RUs more understandable and more flexible because changing your partition keys and your indexes is a larger batch of work than it necessarily needs to be.

The company I have been working for has been using it for more than five years, but I have been with the company for just over two years. I have been working with Azure Cosmos DB during my entire two-plus years at the company.

We have had only one incident where Azure Cosmos DB went down. It was about two years ago in the East US. They had an incident where the update they made caused some downtime for us. I forgot what the duration was, but luckily, we had global replication for our main Azure Cosmos DB setup, so while the East US was down, the West EU region picked up. The majority of our operations continued without issue because of our use of the global replication option available within Azure Cosmos DB.

Latency and availability are great. You can, of course, write code that does bad things for it, and we have had to fix our own code sometimes. Whenever we have written our code properly, latency and availability have been great.

The scale has been wonderful. Our ability to add request units as we have needed them has been easy. We do not have to do much other than tell the system we want more, and then it automatically scales for us, so we do well there. 

The only limitation is around the partitions. Each physical partition maxes out at 10,000 request units as they have documented. We have had to deal with that while designing our data structures to make sure that we take into account that physical partition limitation.

The quality is top-notch. We have been able to talk directly to some of the Azure Cosmos DB experts at Microsoft. We have been able to get extremely detailed answers with very specific recommendations for all of our different questions.

Their speed has been definitely acceptable. Within a day or two, I get at least an acknowledgment of my question. We have not had any high-severity questions to be answered right away. Most of our questions are during the design phase where we just need to know specific recommendations based on our needs, so there has been no real-time pressure. Answering or acknowledging our question within a day or two has been an acceptable time frame. We generally get our answers within a week, which has also been acceptable for us. We have never needed a super fast answer, but I am also clear about that in my communication with them. I tell them that it is not an emergency, and we are just in the design phase and need these questions answered.

I would rate their support a ten out of ten. There is nothing that I would ask for more from the support. They are responsive. They give accurate answers, and they are easy to deal with. That is all that you want from a support experience.

Positive

Historically, in my career, I have used SQL Server, ClickHouse, Postgres, and MySQL. ClickHouse is probably the closest equivalent, but we had to maintain everything in-house, so it was a lot more intensive to maintain. SQL Server was nice, but it does not have the document flexibility, or it did not have that at the point in time we were thinking of using Azure Cosmos DB. So, I am very familiar with all the SQL-based servers historically. They just did not have the necessary document flexibility that we were looking for when we selected Azure Cosmos DB.

It was already in place when I joined.

It does require some maintenance as we grow. Each one of the collections scales up by request units. We use the autoscale feature, but it has a bounded range, so as we grow, we watch the RU maximum, and we adjust the RU maximum of our different containers as we scale up. The maintenance is minimal. We change the RU scale maybe once per quarter. Otherwise, everything goes fairly without maintenance.

I do not know if it has helped us decrease the total cost of ownership, but certainly, it has helped in our DevOps maintenance. Our DevOps people spend a lot less time worrying about or dealing with Azure Cosmos DB. Because of that, we do not spend a lot of person-hours on Azure Cosmos DB. However, Azure Cosmos DB does come at a premium price in terms of being able to do all of its features. It has an appropriately associated cost with it. Because of that, we have not done any formal calculations to see if it saves us more than some of the other solutions such as SQL Server or Postgres. We have not done a cost comparison. What we do know is that it satisfies all of our needs. We do not spend a lot of time thinking about it. As we add features and datasets to it, we do not have to do a lot of performance testing, so we are just able to add things to it. It just works, and we do not have to spend a lot of development time, QA time, or DevOps time worrying about whether it is going to be able to satisfy what we need it to do.

As opposed to running our own VMs or our own databases, it would have reduced our overhead costs. All we have to do is go into the Azure portal, click a couple of buttons, and type a couple of numbers, and then it just happens without any other effort. It takes us seconds to minutes to change things, whereas other solutions might take days or hours to process. From that perspective, there is certainly a reduction because it only takes us a few seconds to scale our Azure Cosmos DB without any other effort. However, you pay for that with the actual price of Azure Cosmos DB itself. That is somewhat built into the price where Microsoft takes on that maintenance cost, but you pay for it.

The pricing and licensing model was initially difficult to understand, but as soon as I learned what was going on and how it was priced, it was pretty easy. What is more difficult is to understand how your system is going to behave specifically with the specific partitioning and querying that you are doing. Some of it is reactive because you cannot always predict what your customers are going to use in your product and in what specific way. So, while we have understood the pricing model, what we have not understood is which parts of our system would end up being the most expensive, costing us the most, or needing to scale the most. It is not necessarily an issue with Azure Cosmos DB itself. It is about understanding your individual software or our individual software when it is running on top of Azure Cosmos DB. It is about understanding what the behavior is going to be.

I would advise taking advantage of all of the features that are available. Especially if you are a globally distributed business, make sure that you have all of the high availability and backup options enabled so that you are not surprised in case of a problem.

Like almost all of the recommendations that you see in different Microsoft videos, make sure that your partition keys are set up properly from a RU perspective so that you know that you will be able to scale your individual containers effectively without running into the limitation of 20-gigabyte physical partition size or 10,000 RU physical partition throughput. Be aware that those exist and design your partition keys for the future so that you will not be limited when your system starts to get heavily utilized in the future.

I would rate Azure Cosmos DB an eight out of ten. There are some improvements that I would like to see around the physical partitions.

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.

We use Microsoft Azure Cosmos DB in our loyalty platform, which is based on our proprietary technology, Synapse LX. In loyalty, we need to enroll, score, and deliver rewards communications in near real-time. There are significant volume spikes in those activities, so our use case is to support the writing of information into our database. Cosmos DB is a no-SQL database that allows us to scale quickly and handle large volume spikes. It allows us to auto or manually scale in many different ways. It gives us much flexibility to handle that requirement and ensure we deliver the right customer experiences.

Cosmos DB is not difficult to use, but like anything, it requires careful planning and consideration of use cases. This is especially important when planning to implement it. From an optimization perspective, Microsoft has made significant efforts in the past 12 to 18 months to facilitate changes after initial implementation and optimize cost.

Cosmos DB provides excellent search result quality. Since implementing it, we have not encountered any issues with our searches.

After deploying Cosmos DB, we initially experienced some performance gains, followed by additional benefits that required a learning curve regarding tuning and configuration. As our understanding deepened, we were able to optimize it further.

In the last three months, Cosmos DB has helped reduce our total cost of ownership. Microsoft recently implemented a feature that allows us to achieve savings of up to 50 percent.

The most valuable aspect of Cosmos DB is its performance. It serves as the foundation for OpenAI's infrastructure, providing us with similar functionality. This not only prepares us for AI use cases but also efficiently supports our loyalty use cases. We can share information with our customers and deliver experiences without concern about performance.

For our Disaster Recovery plan, we currently use geo-replication. We'd like to avoid full DR replication if possible, as this would result in significant cost savings.

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

We have not had any stability issues with Cosmos DB.

Cosmos DB's scalability is excellent, which is the whole reason to use it for scalability and performance.

The dynamic scaling helps decrease our overhead costs.

The initial deployment was straightforward and consisted of two to three people.

Cosmos DB's pricing structure has significantly improved in recent months, both in terms of its pricing model and how charges are calculated. This has led to substantial cost savings for both us and our customers.

I rate Microsoft Azure Cosmos DB seven out of ten because of the disaster recovery requirements.

Cosmos DB presents a steep learning curve. I would rate it a five out of ten. The challenge lies not so much in understanding its concepts as in utilizing them effectively and efficiently.

It took us 12 to 18 months of focused attention to fully onboard our team. At that point, we began to understand. However, it wasn't until we went live and observed actual user activity that we truly grasped the whole picture. Testing is one thing, but experiencing real-world interactions provides invaluable insights and a deeper understanding.

Cosmos DB requires minimal maintenance, but monitoring its performance and optimizing it as needed is crucial.

Potential users should plan accordingly, as Cosmos DB is a NoSQL database that uses similar design principles. Consider the design and apply those principles beforehand to optimize performance from the start. Understanding your read-and-write ratio is crucial due to cost implications, so ensure you understand the balance between reading and writing to the database. All these factors matter as they can impact your costs, so consider them carefully. 

I worked on an entity data client project that handled multiple users from digital products, like a Stream player similar to Netflix. It is called Play Plus, with a user base of seven million and a website that attracts eighty-two million unique users per month. We store the data from these users in Cosmos DB to ensure a fast connection between the user profile and the advertising system.

I believe the best features of Cosmos DB are its global distribution capabilities. It supports multi-region replication with low latency in read and write operations and automatically adjusts throughput dynamically based on workloads. It ensures low latencies, offers consistency levels, and provides a serverless mode. Also, for this scenario, the solution was fast due to its serverless nature, allowing it to handle eighty-two million user profiles with low latency and swift connectivity with the advertising system.

I think Cosmos DB enhanced the benefits of NoSQL databases, offering query flexibility, partition management, and backup and restore options. These aspects are crucial, and perhaps improving the complexity of partition management would be a beneficial area for Microsoft to focus on.

I have been using Cosmos DB since 2023 when I executed a project for clients.

I do not experience problems with Cosmos DB, nor does the team have any issues with it.

I have used both Cosmos and AWS DynamoDB. Compared to Cassandra and Cosmos DB, I think Cosmos is a superior solution because it is serverless. There is no need to worry about installation, updates, or security, as Microsoft handles all this. Our focus is solely on development.

The setup was easy, very easy.

By using Cosmos DB, I estimate at least a twenty percent saving because it allows us to develop rapidly.

I truly recommend Cosmos DB because it is a serverless product. Our responsibility is just to develop and adhere to Microsoft's instructions to achieve optimal performance from Cosmos DB. It is an excellent tool. The product rating is nine 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 like to describe it as a programmer's database. .NET developers, in particular, can design and work with the data easily because it's schema-free. Unlike traditional databases, which are considered rigid with their rules, developers really love Cosmos DB because of its schema-free nature and the freedom it offers.

Cosmos is widely used for web applications. You can also use it for inventory management and IoT solutions... there are a ton of different applications.

It's very easy to integrate Azure Cosmos DB with other Azure services. For example, generating a Power BI report from data in Cosmos is just a few clicks. It's also simple to stream IoT or sensor data into Cosmos.

When it comes to supporting IoT or real-time analytics, the main advantage is speed. Cosmos DB doesn't rely on traditional disks and database structures like a relational database. It uses JSON, which is similar to XML, and that makes it incredibly fast.

The way it was designed is most valuable for global distribution. Unlike old-school SQL Server that was intended for a single data center, Cosmos was built from the ground up for global availability. 

Features like geo-clustering and mirroring were not afterthoughts. If you have a database in Chicago, you can right-click and easily create a failover group in Japan. That works well for global companies with offices across continents; it minimizes latency.

Cosmos's multi-model support made databases more highly available. 

The downside is that Cosmos is new and fairly complex. There's a limited pool of talent who are really good at working with it.

Because of that, I've been approached by recruiters quite a bit; they see my Cosmos DB certification on LinkedIn. It's hard to find people to work on Cosmos projects. 

Sometimes, a really smart developer will design and build a Cosmos implementation and then move on, leaving the company struggling to find someone to work with it and maintain it.

Interestingly, if you need to restore a Cosmos DB database, you have to put in a ticket with Microsoft – they're the only ones who can do that.

I've worked with Cosmos on and off for about three years.

For Cosmos DB, their technical support is very good. They are the experts in that product.

Overall, the customer service and support are excellent. 

Positive

I did a couple days of training on DynamoDB, which is Amazon's comparable product to Cosmos DB.

They're actually quite similar, both being multi-model databases. Relational databases are good for structured data, but once you get into semi-structured and unstructured data, they just don't perform well. 

That's where DynamoDB and Cosmos DB excel – storing, indexing, and quickly working with that less-structured data.

The initial setup is simple and straightforward. You can set up a Cosmos DB in a day, even configuring things like availability zones around the world. 

The harder part is on the developer side – designing the collections (similar to tables) and how the data will flow in.

I've set up a few Cosmos DB instances, and it's about a half-hour tops.

One person can handle the deployment. I'd typically set it up alongside other Azure components like a VM. You choose your settings, networking details, etc., basically walk through a wizard, hit deploy, and it's up within half an hour.

There are some configuration options for database administration on the customer's side. You'll need to go in and enable things like automatic indexing with checkboxes.

With heavy use, like a large-scale IoT implementation, you could easily hit a quarter of a million dollars a month in Azure charges if Cosmos DB is a big part of it.

I would recommend using it, but with a caveat – it's a good fit for companies with deep pockets.

It's powerful and amazing, but the costs can add up.

I'd give it an eight out of ten. It's super powerful and solves real problems with global distribution. I hesitate to give it a perfect ten because it's still new, and good training resources are harder to find. Even the most recent books on Cosmos DB are several years old, which is ancient in IT terms.

I had to work hard to get a certification in it. 

In our setup, we rely on Azure Cosmos DB primarily for cloud-native applications that demand global scalability. We use it for connecting web apps and implementing search functionalities.

Cosmos DB's low-latency data access has greatly improved our application performance. It is a game-changer, allowing us to move workloads from on-premises to the cloud, thanks to the reduced latency, and freeing us from the constraints of on-premises environments.

The most valuable features for our organization with Azure Cosmos DB are multi-master capability for applications, automatic failover ensuring high availability, scalability, support for multiple data models, and low-latency access. Additionally, the seamless integration with microservices running in containers adds another layer of efficiency to our operations.

In terms of improvement, slight enhancements in integration interfaces, expanded dashboard functionalities, and broader use-case support would be beneficial.

I would rate the scalability of Cosmos DB as a nine out of ten.

The technical support is quite good.

It is a relatively affordable solution.

For those considering Cosmos DB, my advice is to embrace its versatility. Cosmos DB can handle various data models like documents, wide columns, and graphs seamlessly. You can consolidate your needs into one database, Cosmos, eliminating the need for multiple databases. It simplifies management and offers a comprehensive solution for a wide range of use cases.

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

We use Cosmos DB as our entire storage database solution for our application. We don't use any other relational database. We have a file that we use for configuration, but we use Cosmos for user data.

We have about 100,000 users a week who visit our website. We have plans to increase usage to four times what we're using now.

The biggest benefit it offers is scalability. It's easier to work with concurrency and updating data. We don't have to worry about locking cables or the speed of reads or query searches because we've structured our data around a key value. Everything is super fast, and it basically removes any bottleneck related to databases in our application, and we just use reference keys. One document will reference the key of another document that we need, so we don't have to rely on searching.

Partitioning is helpful because we use it heavily. Partitions are really nice because they help with the collection of data. Not only is it fast to recall the data, but when you partition it, you can pull the partition and then query the exact document from that partition. It helps with data recall.

There's another feature that we just started implementing, which is partial updates of documents. It doesn't require the entire object to update, but updating documents across applications becomes difficult because you have to pull the entire document, which means you have to support the entire model to update it. So, that application has to know about every single parameter that may or may not have been added because if it reads and writes the document again, you'll lose data elements.

An improvement would be a more robust functionality around updating elements on a document, or some type of procedural updates that don't require pulling the entire document. Otherwise, you have to keep all of your apps up to date with the models, and that can be cumbersome and lead to errors. Usually, you don't always remember, and then it leads to some type of bug, but you won't realize why. You'll lose some value because you don't realize that you have some application that doesn't run often. You forget that it writes to that same document and you didn't update the model.

It would be nice to have some type of functionality for less common updating applications and to not always have to worry about keeping that model up to date.

There's some integration with Entity Framework and it's nice, but it's not robust and it would be good to have something like that when it comes to pulling data.

Occasionally, you have to query the database for values because we save our appointments and we don't have an index on appointments. We don't have a manual lookup for appointments, so we don't save it in another file. We have to run a query to get appointments that occur on a specific day and the downside of that is you have to use strings just to hardcode the string values. It would be nice to more easily integrate with a tool like Entity Framework, and I know that they do, but it's not an easy process. It would be nice to have an easier way without relying on text to query the database.

I have used Cosmos DB for a year and a half.

There have been some configuration issues, but we haven't hit any thresholds or roadblocks when it comes to throughput. That was one of the reasons that we leaned toward it and not a relational database, especially at scale. We haven't run into any issues when it comes to that.

We look at community answers because we can usually get answers faster than messaging support directly. We don't usually resort to a customer service type of support unless it's a fundamental issue. 

When we had an outage in the middle of the night, the turnaround time was within a few hours.

Previously, I used Couchbase. I've also used Neptune, which is a different type of database. I've also used SQL.

We chose Cosmo DB because it's more tightly integrated. One of the reasons we chose this version of a non-relational database was because of the speed of development. We also chose Cosmos DB over other types of NoSQL databases because it's so tightly integrated with Azure, it's easily managed through deployment templates, and it's very easy to scale. If you're using Azure already, it's a very easy tool to pick up and integrate into your applications.

Cosmos is pretty straightforward. There is more complexity, so you just have to be mindful. We had a small issue with making sure that the disaster recovery settings were set up correctly. We found out that there was some type of outage in the middle of the night, but we noticed that the failover didn't run properly. It was because of some configuration that should have been caught earlier, and it wasn't obvious that we got it wrong.

There are some infrastructure teams that manage some underlying resources that are related to Cosmos and some of the configurations, but for our specific implementation, we have three developers at most. We usually only need two people for maintaining and managing the solution.

We deployed the solution in the cloud, but we configured everything in-house.

We have seen ROI. There's no active management when it comes to that. When I've worked on relational databases, there's a lot that goes on, like indexing, upgrades, and store procedures. I've managed relational databases for years while working on an application and worked with people who managed them. Cosmos is nearly maintenance-free and very easy to use.

The pricing is really good. I would rate the cost as 9 out of 10. There may be some more complicated use cases that are more expensive. When we've budgeted for our resources, it's one of the more expensive ones, but it's still not very expensive per month.

I would rate this solution as 8 out of 10. 

When it comes to ease of use, spinning up and working at scale, our specific use case, and the scalability that it offers, the solution is definitely very good.

My advice is to use containers as single objects and create manual indexing to improve efficiency.

The main use case for Microsoft Azure Cosmos DB is as a key-value store where we store all the user data that we have and perform lookups. We use it at a significant scale, with storage of unique data reaching 12 terabytes and handling up to 3 million requests per second.

The scalability of Microsoft Azure Cosmos DB has significantly aided us in managing workloads efficiently.

We were able to realize the benefits of Microsoft Azure Cosmos DB immediately after deployment, making it quite easy to get started.

The most valuable features of Microsoft Azure Cosmos DB include the TTL, the ability to scale up and down as needed, and geo-replication, which comes out of the box. We do not have to do anything for geo-replication. We just have to enable it.

The indexing policy is also very good, and the overall metrics and monitoring system are also quite good.

Microsoft Azure Cosmos DB is fairly easy to use.

Microsoft Azure Cosmos DB can be improved by providing more fine-grained control over certain aspects, such as connections and threads. There could be more control over how many connections are made. I am not sure if it is a knowledge gap issue. A regular connection with the Azure Cosmos DB team might help in addressing knowledge gaps. Being able to fine-tune these features would be helpful for us.

I have been using Microsoft Azure Cosmos DB for about six years.

Over the last two years, Microsoft Azure Cosmos DB has been very stable. It has very good latency and availability. Latency is good on the server side and the client side. We have had only one significant issue that affected our production system. Overall, stability has been excellent.

The scalability of Microsoft Azure Cosmos DB is one of its best attributes. We can scale very efficiently and adjust workloads as needed, which is more challenging with other systems.

We have contacted their support many times. The quality of customer and technical support has improved over the years. Initially, it used to take quite a while for issues to be resolved, but now the support is seamless and very efficient. We have not needed much support in the last couple of years due to the system's stability. It is pretty stable now. I would rate their support a nine out of ten.

Positive

I have used Redis briefly and Aerospike extensively before switching to Microsoft Azure Cosmos DB.

Both Microsoft Azure Cosmos DB and Aerospike have their own advantages. The biggest advantage of Microsoft Azure Cosmos DB is that it is very easy to get started with and it does not require too much effort. It takes just one click to deploy Microsoft Azure Cosmos DB and put it into multiple regions. It does not require too much maintenance, whereas Aerospike requires a lot of maintenance effort. It requires a dedicated team. In this aspect, Microsoft Azure Cosmos DB is very good. However, Aerospike provides control over a few things, which we do not have in Microsoft Azure Cosmos DB. If we want to run or use the maximum amount of resources, Aerospike helps a lot. Both have their advantages and disadvantages.

The initial setup was easy. It was not difficult.

It took us a quarter to be able to use it efficiently. It is fairly easy and straightforward.

We had set up our own autoscaler. There was a pipeline that ran on top of Azure Cosmos DB to see how many RUs were provisioned. It did require a little bit of maintenance because we built custom software on top of that, but that was it. Our autoscaler performed better than Azure Autoscaler. However, because of some billing benefits, we have started using Azure Autoscaler. The Microsoft team said that if we used Azure Autoscaler, they would give us a discount, so we started using that, but our autoscaler performed better.

Initially, the deployment required an entire team, but now, it can be managed by a smaller team of two to three engineers.

It has decreased our total cost of ownership by approximately 20% compared to other alternatives such as Redis.

Its pricing is higher compared to solutions like Aerospike. However, it is justified because of the out-of-the-box features that are provided. The availability and resiliency that we have make it worth the price.

To new users, I would advise first knowing their data. They should know whether it fits their solution, which Azure Cosmos API to use, and what scale they intend to run it.

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