Microsoft Azure Cosmos DB Reviews

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.

This is an event-driven solution. Most oil and gas companies have folder source systems, where they cannot scale, but they still want to provide real-time data to their end consumers for various analytical use cases and AI/ML processing; this is where we input raw data into the Azure environment of this solution. Then, eventually, we built the API on top of Microsoft Azure Cosmos DB because it's highly scalable. The solution is a little bit expensive, but the businesses are ready to accept it. 

In terms of performance versus scalability of this solution, you don't need to worry as long as you have your initial numbers in place. This product works by using performance currency, which is the number of request units per second. Once the data is ingested, based on that, we can know how many users are going to access across the world in every day, hour, or minute. Once you have the ingestion versus consumer pattern identified, you can use this product to input all those numbers, like the volume of data for migration. 

The built-in integration of the solution is tight. It can be used in conjunction with Synapse, Microsoft has also created a Synapse link. In this solution, the OLTP workload will never affect the OLAP workload. Therefore, the solution does data replication asynchronously without affecting the OLTP source system. No specific pipeline is thus required, which is not easily found in other services. 

In the server, there are two ways in which you can provision a call, one is serverless, which has a pay-as-you-go model, and another is a dedicated provision throughout. So, irrespective of what you allocate and whether you use it or not, in this solution, the charges are accounted for the request unit per second. This is a big drawback of the solution.

This is an expensive solution and if you get the initial calculation wrong involving how much you are going to ingest, how many people are going to query and more, then you are going to receive a very large bill at the end of every month.

Additionally, on the serverless option, there is a limitation regarding the amount of data you can ingest; this doesn't allow you to upgrade beyond a point, and the limit cannot be utilized for many use cases. On the execution side, whatever you create as a container, that container cannot be used as a destination when using serverless mode. This is another key limitation of the solution. 

I have been using the solution for one and a half years. 

I had minor issues while using the solution, but they were actively solved, and eventually, a justification was also given. Ninety-five percent of the time I used this solution, there were no issues. Microsoft's service in the cloud market is still growing and so there are some feature limitations. 

The solution is highly scalable. We use the solution in our enterprise both internally and externally, including integration for clients. We created our solution end-to-end by considering different audiences, people who can directly onboard Azure but might not need Cosmos DB.

There are vendors and individuals who cannot directly consume data on the Azure environment and will have a dependency on data. However, we cannot expose the source data for its performance issues and limited scalability, so we deliver this data by using Microsoft Azure Cosmos DB. The parent company Reliance has multiple subsidiaries like Ajio, manufacturing supply chain, Oil and Gas, and more; we used to use the same API for all subsidiaries, which was built on Cosmos. 

Technical support was good. I would rate the customer support an eight out of ten. They were fast and responsive, but the support team runs from different locations within or outside India, so whoever is working during the particular shift will take care of the case initially and then some other individual will take over.

So, my team had to re-explain the same thing over a call or meeting. But it was only a few times, they were able to get all the information based on the previous conversations most of the time. 

Positive

Deployment of the solution was very easy. Once the initial numbers are in place based on request units, only the instance creation was a time-consuming process. The time was consumed due to the dependency on other teams like DevOps, who are responsible for provisioning. So, it was a one-time process, but migrating and running the same workload between different environments was not much of a hassle. 

It took less than a week to configure and install this solution. To complete the setup, it took five to six professionals from our team. One key solution architect, two people from the DevOps team, and two solution architects from Microsoft were needed for the deployment of this product.

Maintenance of the solution is very easy because the solution follows a Platform-as-a-Service type of model. There is actually no need for any downtime or a patch upgrade because it is taken care of by Microsoft. I never have to worry about downtime for this solution. They perfectly deliver on the key characteristics of the product. 

Our business need was to deliver or provide the source data without any latency issues, in less than five or ten minutes latency, to be precise. We had to provide the data to the end consumer without overwhelming our source. We got the business confidence in the initial three months of using Microsoft Azure Cosmos DB. 

The solution is a bit on the expensive side. 

We tried to compare this solution with MongoDB, which is open-source. But we choose this solution because Microsoft is the first implementation partner for us. 

I would rate the solution an eight out of ten. My advice to other people will be first to identify the purpose of availing the solution. There is also a product called Azure Data Explorer, which is a more extensive service used for similar use cases.

Also, in terms of Cosmos, the user should be clear about whether they will be able to use the serverless deployment model or whether they need the dedicated provisioned throughput Model. They should also first use the price calculator by inputting the numbers to decide if they need it. I would also advise you to get in touch with a Microsoft Specialist and walk through all the doubts. 

The solution has a very good service, but the user should be clear about how to start using the product. For the initial three months, we did a lot of trials to get the components and RUs right and check how the calculation is happening. However, after the trials, we were very clear about how we wanted to move forward with the solution to get the maximum ROI. 

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

We use it for different companies and different clients. We have Fortune 500, startups, and mid-sized companies as our clients. They are in healthcare, finance, fintech, tech, manufacturing, construction, real estate, telecom, and a lot of other industries. They all love it.

It is the best in terms of performance and scale, and it can do both SQL and NoSQL workloads, so it is pretty impressive. One of the least understood use cases happens to be cost and caching. It has a pretty amazing caching engine, and its cost is amazingly low. Especially with the strategies we have designed, we can show a cost reduction of 99% in certain cases. The request charge reduction is anywhere between 75% to 99%. It has been pretty amazing to get cost, quality, and time. We can get all three with it. It is one of the very few databases that can even get there.

We use the built-in vector database capability. It is pretty fascinating. You get recalls that are pretty high. In the competitive landscape of databases, it is surprisingly better in terms of p95 latency and also requests per second, which is something that every customer wants but does not easily get by default. You can also use HNSW, for example, a lot cheaper than you would otherwise because of the DiskANN technology. It is similar to HNSW, but it is on the disk, so it is cheaper. You are not going to the memory. That saves you a lot of money, which is important because when you are running workloads that are getting to terabytes and terabytes, the cost is a huge concern, especially to support the underlying business. That is pretty amazing in terms of DiskANN, which is a Microsoft technology that is very well implemented in Azure Cosmos DB.

Usually, the vector database is integrated with a bunch of other applications. It could be a CRM system behind the scenes, or it could be any LLM-based application. The interoperability with other solutions is fairly simple because, at the end of the day, it is just an API. You can make it work with anything.

We use a lot of different models including Azure OpenAI and some open-source ones through Azure AI Studio. They are very easy to use with it because it is just an API.

It is as fast as what you would find elsewhere. It scales, and they do that part for you. Performance and scale are the things that Azure Cosmos DB got right. That is definitely a positive. If you do not use the vector database, you may get into hallucination issues. Things might slow down. Such issues do not happen if you are using the vector database correctly. Your LLM is now supported with the rack pattern, which is done very well by DiskANN and Azure Cosmos DB.

DiskANN does a great job with recalls. We can decide how high we want them to be. That is the best it gets. If you are using vector searches, it does a great job. I do not usually use Azure Cosmos to compete with a regular or classic search engine.

In terms of Azure Cosmos DB’s ability to search through large amounts of data, currently, the maximum we have on it is in terabytes, but a lot of that depends on how you do a lot of things. That includes data modeling and partitioning, and then your entire vector strategy, which is what we specialize in. We have seen great results. You get the best of all worlds. For example, there is a higher recall at pretty amazing requests per second, which in some cases is 10x to 15x of what you would get for the same recall with another engine. Your latency is also a lot lower. In some cases, it is incredibly low. For example, it is 10x to 15x lower than others. This combination is very hard to get with other databases that we have tried, so from that angle, Azure Cosmos DB has done a terrific job.

A few years ago, we put out a report that took Azure Cosmos DB as it is and compared it with other databases out there, and it was 92% cheaper on reads and 20% cheaper on writes. After that, we used our optimization, and we were able to further reduce that by another 75% to 99% in different cases. We have an online talk about it where we partially show how to get there. Those are not full solutions. It was a conference where I had 15 minutes, and I ended up doing a demo. 

It is pretty fascinating because it is very hard for other databases to come anything close to it in terms of the cost given the fact that you have pretty amazing performance and scale. A lot of people can beat you on Azure Cosmos DB, but they do not give you the right performance and scale you need for business, so those cost savings are meaningless. For our customers, it has got to be the best of all worlds, and fortunately, Azure Cosmos DB has that.

Pretty much all of the features are valuable. Change feed is a pretty amazing feature. Once you make the changes, they are quickly read for you, and then you also have geo-replication. You can do a lot of things in your region, and the same regions can be replicated all over the world. There are different geographies. I can have my servers pretty much anywhere in the world. The data could be within the country or continent when there is a data restriction policy and things like that. Security is big. There are a lot of very good features.

It is very easy and very simple now given all the improvements, but it is also designed very well. Especially because we specialize in it, it is the easiest thing on our side. Data modeling happens to be a lot easier than SQL and others. The learning curve is a lot smaller than a typical RDBMS. It is very like code, and that is another benefit. Developers love it because you do not have to learn something new. You can use the same object that you are using in your code, and you can write stored procedures in JavaScript if you want to. If you want to do anything else, you could use the SQL API or NoSQL API, or you could use MongoDB API. It supports a lot of different APIs. You do not have to learn anything new, so the learning curve is way smaller than pretty much anything out there.

The best part of Azure Cosmos DB is that you barely have any maintenance. This is what I liked about it in the first place. 

In the long run, there should be an addition of more features, especially because this space is evolving quickly. It all boils down to how many more features you are adding, how many integrations you are supporting, and how many more APIs you have that are standard APIs. The team is already doing a great job. They are already doing all that is needed, but the more features we have, the easier it is for us and our clients.

For example, when you have these vectors, it requires us to know a little bit about the configuration behind things such as HNSW. When it comes to the MongoDB vCore piece of Azure Cosmos DB, people like us know how to get to higher recalls easily but a regular user may not. If they have a feature that provides an easy way to get to a certain recall you need, and that is a configuration by default, that would be great. Currently, the flexibility is amazing, and we love that. The competition is usually not providing that. The competition sometimes gives you a recall of 80%, but they are taking away the latency and requests per second. Azure Cosmos DB does not do that. It is a better solution. If Azure Cosmos DB has configurations and a feature allowing us to pick any of the use cases we want, it would be great. For example, if I have an application that I am okay with, and my application does not require a huge recall that is 80% but needs one that is 60%, for us, it is very easy to take HNSW and do it that way and reduce the requests per second because that might not be a concern. If there is a feature that allows people to pick out of five different permutations and combinations, it would be very easy for anyone else to do it. However, keep in mind that competition does not even have that flexibility, so competition is lagging behind on that, at least in the case of the ones we have tried. If Azure Cosmos DB has such a feature, it will be easy for more people to take advantage of the things we are taking advantage of.

I started using it when the first version of DocumentDB came out, and then a couple of years later, it was renamed to Azure Cosmos DB. I have been working with it even before it was called Azure Cosmos DB. I am still using it, and it is my favorite database.

In 2020, we put out a report. It is on our website. This was the only one out of all the major databases out there that had a linear throughput increase for hundreds of servers. What is crazy is that everyone else said that they do it, but you could literally see that after a certain number, they would slow down. One of them was a pretty majorly known, multibillion-dollar NoSQL database, but after 50 servers, it would just slow down completely. You could literally say, "Wow, it is taking time to go to the next level." Azure Cosmos DB was the only one that had linear throughput. Our team thinks that the underlying infrastructure of Azure Cosmos DB is procured in advance, and that is why they can have a linear scale for as much as you want to go. It totally depends on how big, literally, Azure is. The competition is running on someone else's cloud mostly. They probably procure machines as they go, and maybe that is why they are slow. This is an interesting thing that made us love Azure Cosmos DB.

Latency is pretty straightforward. They guarantee 10 milliseconds read and write times now, which used to be 10 and 15 earlier. That is one thing that is pretty incredible. A few things that we have shared with customers is that there is always a wrong way of doing things. You may know the right thing, and it is easy for you to get the latencies, but you may completely mess up the data modeling as well as your code and hundreds of different things. You may be making five calls when you need to make one. You may be doing a lot of other things that are not necessarily best practices. In some cases, we have seen people having a latency of more than 200 milliseconds, which we brought down to 10 milliseconds.

Azure Cosmos DB’s dynamic scaling decreases an organization’s overhead costs big time. This is where it stands out. A lot of our clients who were previously using RDBMS kind of solutions found them to be slow. It would take forever. They would not scale beyond a certain point, and they would get extremely costly after some time because you have huge machines. Some of them were paying millions of dollars for one machine, whereas now, they just pay and go and they can scale. They can go all the way up, and if they want to go down, they go down. For example, on Thanksgiving, they may be scaling to hundreds of nodes behind the scenes, and the next day, they could be scaling back to three nodes. Imagine the cost savings when you never had to procure those servers or anything else. This is the genius of this whole thing. They are being able to take advantage of a scale that they could have never had as an organization. This is not just for startups. Even big corporations can take advantage of the same exact thing. It works for every single one out there.

I never had to contact support. If you know what you are doing, then it is really good. I do not even know of anyone calling Azure Cosmos DB support for anything.

I have worked with almost all of the competitor solutions. I cannot think of any disadvantages of Azure Cosmos DB unless the competition is for a specific use case. For example, in the beginning, Redis was great for caching. It had a great Pub/Sub Over a period of time, Cosmos DB got there, but Azure Cosmos DB is a lot more than just that use case. Today, it is easy for me to pick Azure Cosmos DB as a caching engine. I would not have done that five or six years ago.

We do not do much with the on-premises version. We only work with the cloud version.

Its deployment is pretty easy. I have been doing it for a long while, so it is easy for us and our clients. I do not know about others.

Our implementation strategy depends on what kind of project it is. We do greenfield, brownfield, and all of the projects. We do integration projects. We also do projects where they are only doing an addition of LLM. We start with understanding the client's needs and then figuring out what is currently there. If there is nothing, we data model the whole thing from scratch and go with the best practices. A lot of times, if it is brownfield, a bunch of work is already done, so we are not going and figuring out what is the most optimum way to do it within client constraints. We create a strategy based on that and implement it based on their tech stack because everyone has a different one. Once we get the approval on that, we move forward with the implementation.

The number of people required and the time required depend on the client and their workload. If you have a small app, you could be onboarded on day one. If you have a big app with petabytes of data, it is usually a month of work. It totally depends on what we are looking at or the use case.

In terms of the learning curve, Azure Cosmos DB is one of the simplest ones out there. It is on the easier side. There are a couple of them that are pretty easy. 

To new users, I would advise understanding different propositions. Start with understanding what kind of data set you have and every single thing. Also, know the tech stack you have and pick your strategy accordingly. What you do not want to do is go with the flow without understanding what a NoSQL database is supposed to be like and make changes down the line.

A lot of people with an SQL background, unfortunately, start using any NoSQL databases, not just Azure Cosmos DB, in a way that is not very good for them because the patterns that usually are the best patterns for SQL may not be the best patterns for NoSQL. For example, there is a reason we do normalization in SQL. That takes away duplicate data, which is perfectly okay, but in the case of NoSQL or Azure Cosmos DB, we can scale and have duplicate data in places if we have a different kind of use case. If I want to make different kinds of searches available, I can have three different kinds of searches available for similar kinds of parameters. I will not be worried about doing that in a NoSQL environment because I can scale out pretty easily, so data does not hold me back. In an RDBMS environment, I might be doing two or three joins to make sure that I am making it fully normalized because if my data increases drastically, that will create a scale up situation. Scale-up is the only thing you can literally do with RDBMSs. Mostly, scale-out is not that easy unless you are on the cloud and you are using the scale of the cloud, and then you have performance issues. In those kinds of different scenarios, the DBAs or people with an RDBMS background need to come up with an open mind and understand what this is.

It is not that you have to learn a lot about Azure Cosmos DB. You will have to learn about this new paradigm. It is not very new. It has been going on for more than a decade. We have been doing it for more than a decade, but we see a lot of people coming from an RDBMS background and getting it wrong, and then you're paying people like us a lot more money to fix it. It is easier to work with someone like us in the beginning or do a little bit more due diligence and learn that paradigm before you get started. That will save you a lot of money and time, and hopefully, you will not need our services at that point of time. That is definitely my advice.

I would rate Azure Cosmos DB a ten out of ten at this time.

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.

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.