Microsoft Azure Cosmos DB Reviews

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 are using Cosmos DB in several different ways. We receive unstructured and semi-structured documents from partners, and we use Cosmos DB to push the data in and scale it to kick off internal processes. 

We receive notifications from our customers to take action quickly regarding the energy grid. Cosmos DB is also used in a different project for our settlement system, where it is used as a queuing engine for the change notification portion.

The ability to scale efficiently improves our performance and scalability. Although we haven't yet used Cosmos to improve search result quality, we believe it can be useful with vector search and data architecture improvements. We are exploring AI, but I don't think our focus will be generative. We do a lot of ML models, and we plan to restructure our data to use the data lake or leverage the efficiency of already created models to reduce our resource costs and improve efficiency. 

Change notification works well, and the ability to process documents in a scalable way is important. This means we can efficiently thread out different operations and meet our organizational performance and scalability needs. 

Cosmos DB is pretty straightforward. I'm not 100 percent an expert. I have three or four different developers up to speed on it and working on it. They do most of the daily operations, while I do a lot of the prototyping and conceptual aspects.

While we don't use the vector database system, some interesting features might benefit our future data architecture. In one of the workshops, we learned about its capabilities and how it's used as part of Copilot and the backend database. I'm thinking about AI, our data, and some performance benefits.

One area that could be improved is indexing. Some of the developers struggle with the way the indexing works. We are exploring vector indexing, which we haven't examined fully yet. Indexing is an aspect we're looking to improve upon potentially.

I started dabbling in Cosmos before COVID approximately four or five years ago. Initially, I just wanted to test some concepts and figure out its benefits, using the Cosmos local engine to better understand its functionality.

We have not encountered any issues with latency or availability. As we continue to grow and scale, we will keep assessing to ensure our expectations are met.

Scaling the workloads is one of the key advantages of Cosmos, preventing the database from becoming a performance bottleneck.

We assessed other databases like MongoDB but chose Cosmos for its object-style database capabilities, user-friendliness, and ease of access. It aligned well with our needs, and a Microsoft conference initially piqued our interest.

Onboarding to proficiency took a couple of months. The transition from a traditional relational database programmer to an object database was straightforward. The learning curve was manageable and engaging.

I don't know how much money Cosmos DB has saved us. We're still using some of the old databases, but when phase them out, we'll see a significant cost reduction.

The pricing model aligns with our budget. It's expected to lower overhead costs, especially as we phase out older databases. Cosmos DB is great compared to other databases because we can reduce the cost while doing the same things.

We considered Mongo DB among other databases, but Cosmos had the desirable capabilities we were seeking.

I rate Cosmos DB eight out of 10.

Our primary use case for Microsoft Azure Cosmos DB is as a solution for customers who are not necessarily migrating an existing application but are looking to build something more cloud-ready and scalable. The objective is to provide a scalable and flexible database solution that does not require the compatibility requirements of Azure SQL, allowing for fast data access across regions without latency concerns. They are not looking for all the compatibility requirements for Azure SQL, but they are looking for something that they can scale quickly without latency.

I found Cosmos DB to be rather intuitive and straightforward. The documentation is pretty clear because it is a managed service. I could give the custom developers their endpoint and even set up managed identity in a way where we do not have to worry about having secret keys and all of those pieces. We are using private endpoints for everything and found it to be working just as advertised.

The most valuable features include the global write capability, which allows customers to read and write across different regions simultaneously, enhancing performance and availability. 

A lot of my customers like the ability to choose a different API with which they are familiar. The flexibility to choose different APIs, such as MongoDB or Cassandra, allows customers to leverage their existing knowledge while using Microsoft Azure Cosmos DB. 

We are using the vector database a little bit. We often use Azure AI search for that capability. We have an application that is taking in legal documents and needs to do a semantic search against those. It is a combination of using the embedding models and vectorization to get closer to the right chunks of the documents that they are looking for. We, in turn, send that over to Azure OpenAI services to fine-tune and get the best result from our initial results.

We integrate the vector database with another application. It is a custom-built homegrown application that provides a UI for their end-users to be able to use AI search and vector search to be able to get highlighted results of their PDFs.

The vector database absolutely improved the search result quality of our customer's organization. They are partially using Microsoft Azure Cosmos DB in that, but, in general, the two combined absolutely did help by not defaulting only to keyword search and being able to do a hybrid between the two.

For this project, there has been significant improvement in the time to process these documents. There has been a 5x time reduction for the end users in finding the data they are looking for, inputting it into their model, and performing their workflow.

In terms of Microsoft Azure Cosmos DB’s ability to search through large amounts of data, for this specific use case, we are probably on the low end of what Microsoft Azure Cosmos DB can accomplish. We have a decent dataset, but definitely not a gigantic one. So far, our experience has been great, but we are not necessarily testing it to its limits. The one that we are working on is still under a terabyte. We only have several hundred gigabytes for this specific customer. It is a lot of data, but in the grand scheme of things, it is not very much.

Continuing to educate customers on how they can take better advantage of Microsoft Azure Cosmos DB without having to completely rewrite their entire application paradigm would be beneficial. They can help them understand that there are multiple options to interact with it. They do not necessarily have to start from scratch. They can refactor their existing application to be able to use it better.

They can continue to find better use cases for it. It helps to be able to show our customers example documents or example applications. It definitely helps us to be able to show customers how they could be using this.

I have been using Microsoft Azure Cosmos DB for around a year to a year and a half.

The latency and availability of Microsoft Azure Cosmos DB are fantastic. It provides resiliency and business continuity without having to do much. Having it already built in is a big selling point.

I am not working with any customers who are going to have any problems with scalability. We are not going to push the limits of what it can do. My customer base does not have to worry about scaling because none of their applications are ever going to struggle with something as global and as resilient as Microsoft Azure Cosmos DB.

Microsoft Azure Cosmos DB’s dynamic scaling helped decrease the overhead costs for our customers. They have spikes, but most of the time, they have a pretty low baseline. Rather than overprovisioning to handle those spikes, they are able to settle in and ride the waves of their utilization throughout the days and weeks. They have seen a decrease in costs and expenditures. It is still early for a lot of it because a lot of new functionality was added. They did not necessarily have a true baseline to compare against, but they like the idea that it is so elastic.

The onboarding process was relatively quick, taking about six to eight weeks, as the team adjusted to using Microsoft Azure Cosmos DB.

We have not run into many challenges during the migration or implementation of Microsoft Azure Cosmos DB other than being novices and unfamiliar with it. We need to understand all the different components of it, but we have not necessarily run into any technical problems or issues with timelines or things like that.

It takes only a couple of months to onboard customers with Microsoft Azure Cosmos DB. We are able to go pretty quickly. Our onboarding path is about six or eight weeks.

There is a bit of a learning curve for the customers who have only worked with traditional Azure SQL VMs and are not familiar with having a fully managed or PaaS instance. There is some learning curve for them to understand that they do not just have x number of cores or memory available, and it just grows as they use it.

In a couple of use cases, Microsoft Azure Cosmos DB helped decrease an organization’s total cost of ownership. Oftentimes, when we are implementing some of these features, we do not have a baseline to compare against. In my own experience, there definitely is an opportunity if we are able to use the model to reduce cost instead of provisioning a VM or something like that, as we would historically do. It is hard to provide metrics, but when I have done comparisons or cost calculations, I have sometimes personally seen as much as 25% to 30% savings.

Most customers like the flexibility of the pricing model, and it has not been an issue. They can start small, and the cost grows with adoption, allowing efficient management of the budget. Its pricing model has not been a concern at all for any of our customers. They understand it. It is simple enough to understand. Oftentimes, it is hard to forecast the RUs, but, in general, it has been fine.

I would rate Microsoft Azure Cosmos DB a nine out of ten. There is always room to grow, but it is a highly capable solution. I am looking for more opportunities to use it as we help customers move toward more cloud-native technologies, rather than always defaulting back to what they are familiar with, which is sticking with Microsoft SQL Server or Azure SQL.

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.

We mainly use Azure Cosmos DB across different projects in our service-based organization. It has been consistently used in projects that require maintaining and creating NoSQL databases. Our team leverages Azure Cosmos DB for these needs.

Azure Cosmos DB is efficient and manageable. These are the advantages of Azure Cosmos DB.

There is a lot of reusability. For instance, for integration, we can copy code snippets, and the connection is taken care of from Azure itself. Creating connections from an application to the database is easy. Doing recalls and running some queries is easy. We did not have any trouble integrating with applications. The only challenge was to apply the search over the large database in real time.

Our use case required minimal usage of the vector database, but there are a lot of personalization opportunities when it comes to the vector database. We can create as many vector embeddings as we want and customize the structure. There are no rigid rules about the structure. It is customizable. It is also AI-driven, so there are enhanced search capabilities. In terms of relevance or context of search, it is quite good to use a vector database over other databases. 

Scaling is very easy. With other databases, we have to take care of a lot of things, such as schemas and how things will transform, whereas with vector databases, scaling is hassle-free. We do not have to worry about a lot of parameters.

With Azure, resource usage is always optimized. Azure automatically takes care of a lot of things. There are many features. It can autoscale and has efficient indexing. You get asset transaction capability as well. 

The latency is quite low when it comes to search. Searching is very easy, fast, and efficient. Using vector databases means that we want to search for specific parameters.

Azure Cosmos DB offers numerous data connectors that provide a platform for seamless integration with various platforms and visualization tools such as Power BI. It allows connection via multiple data connectors to integrate data in any desired format. 

Additionally, its distribution and low latency features are beneficial. We do not need to rewrite things. We can copy a schema from a template.

It offers efficient indexing and low search latency, making searching fast and efficient and ensuring peace of mind in database operations.

For streaming platforms, Azure Cosmos DB could improve efficiency in data storage. Indexing can also be better. Enhanced capabilities are necessary to manage increased data amounts more effectively during searches.

Azure Cosmos DB provides vector search capability. I used it for an AI application. We needed a vector database that could manage and give us a dynamic connection with the application. It was quite easy to integrate with the application. Querying vector databases and writing the queries is very easy in vector databases. There is also an option for semantic search. We can use the search engines present by default in Azure Cosmos DB to search in the database. That is also useful. Most things were easy, but the vector API part was a bit tricky. If we have a lot of data, doing a real-time vector search is a performance challenge because the search happens over a large dataset. It consumes more time. It is computationally intensive and can be optimized.

I would love to see more features because the market is very competitive for cloud databases. There are many startups offering vector database integration at different speed rates or higher velocities.

We have been using Azure Cosmos DB for the last 12 months.

Azure Cosmos DB provides low latency and reliable availability. As long as instances and databases are configured correctly, stability issues are unlikely. Azure Cosmos DB would be a good choice if you have to deploy your application in a limited time frame and you want to auto-scale the database across different applications. From the availability and latency point of view, Azure Cosmos DB is good.

Scaling workloads with Azure Cosmos DB is straightforward. It has auto-scaling and global distribution features for handling dynamic, high-demand workloads. You just need to configure it correctly. 

It has a feature for multi-region scaling to scale across different regions or applications. You can also conduct horizontal partitioning. You can distribute the data across multiple partitions depending on your use cases. Handling workloads is easy.

Personally, I have not needed to contact technical support. The Azure Cosmos DB community and forums have been helpful in finding solutions without requiring direct support.

Neutral

I have used MongoDB for personal projects, but professionally, I have only used Azure Cosmos DB due to project dependencies.

Setting up Azure Cosmos DB initially was easy. We were able to deploy effectively while ensuring continuous operation and handling transaction queries without failures within one or two days.

It took us some time to realize the benefits of Azure Cosmos DB because when the platform went live, we were using it in-house and had a team of three to four people. The search quality was efficient and it ran fantastically in a small test case. After that, we rolled it out to a larger audience. We took the feedback. People liked the quality and relevance of the search. The quality of concurrent searches was also good. Over a period of one month, we observed the performance and found it to be performing well. We knew we would not have any problems from an infrastructure standpoint.

Its maintenance is quite easy. I have not faced an issue with that. Sharing it across user groups is also easy.

We formed a team and took about four to five days to become familiar with Azure Cosmos DB, given our experience in infrastructure and databases. We were able to work on our use cases within a week. 

Azure Cosmos DB's pricing is competitive, though there is a need for more personalized pricing models to accommodate small applications without incurring high charges. A suggestion is to implement dynamically adjustable pricing that accounts for various user needs. There should be smaller subscription options or a lighter version with a limited set of features for small applications.

Its learning curve is a little bit steep for those who are new. If you have a little bit of experience in infrastructure and databases, becoming familiar with Azure Cosmos DB does not take much time. 

It is easy to use if you have knowledge of NoSQL databases in general. If you know how to create schemas, then setting up the infrastructure in Azure Cosmos DB is no hassle. The basic requirement is to know about databases. That is it. Many things are managed by default in the Azure platform. You just need to take care of the specifics of your project and the regions you will be working in. These are the things that are automatic in Azure Cosmos DB.

I would rate Azure Cosmos DB a seven out of ten, considering its ease of use, efficiency, and provision for peace of mind through its features and functionalities. There is still room for improvement, particularly in pricing and feature offerings.

Our primary use case for Azure Cosmos DB is storing information for our large accounting application, which integrates several sites on SharePoint Online. We use event programming to store all calls in Cosmos DB, so we can redo them and have them persist in the database.

Cosmos DB has helped our organization handle large amounts of data. For example, we had a customer who collected data from 100,000 sites, and we increased that to a million without significantly increasing search query time. We can now search in nearly real-time, which has been crucial, especially with AI workloads.

Azure Cosmos DB's resiliency is valuable. It is available in every Azure region, allowing quick information storage and retrieval. We can partition it to improve indexing, enabling us to retrieve information and recreate website content quickly. 

It's easy to use for our use case because we use it to store and retrieve information, but it will be more complex if you are configuring a Redis cache or something similar. 

Cosmos DB also integrates well with Azure app services and functions, allowing us to scale by efficiently storing calls. Its ability to scale workloads is impressive, and features like partitioning and Azure replication enhance its scalability. Its interoperability with solutions is better than that of other NoSQL databases we assessed. It's native to Azure and integrates with the networks and security.

Cosmos DB should continue evolving in AI features. We expect Cosmos DB to lead on that. There is potential for improved security features, which is important for data storage, especially for Dell Technologies. We must ensure data security remains the top priority.

I have been using Cosmos DB for over eight years, starting from its preview release.

There have been no notable issues with the stability of Cosmos DB. Any problems encountered were not directly related to Cosmos DB but perhaps coding errors or usage methods.

Cosmos DB scales workloads impressively through features such as partitioning and Azure replication. Its design as a NoSQL database has helped us transition from traditional SQL, impacting costs positively.

We previously used MongoDB, but Cosmos DB's integration within Azure provided better network and security options, making it a preferred choice. I've worked on Microsoft technologies since the beginning, and I love how Microsoft solutions are integrated. Everything works together securely, and moving from one technology to another is simple.

The initial setup was easy. The transition from MongoDB was seamless as Cosmos DB has improved upon existing NoSQL structures without reinventing them.

Cosmos DB has decreased our organization's total cost of ownership, particularly with decreasing overhead costs due to its scalable features.

We prioritized fine-tuning operations to optimize costs, and Cosmos DB’s pricing model allows room for improvement. We are assessing its use in other areas to potentially eliminate third-party solutions.

I rate Microsoft Azure Cosmos DB nine out of 10. To avoid migration challenges, data storage methods in Cosmos DB should be carefully considered.

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.