Microsoft Azure Cosmos DB Reviews

Our previous use cases for Microsoft Azure Cosmos DB were mostly for multi-tenant database storage when we needed it. We recently decided to rebuild one of our major products, which is a content management system, on Microsoft Azure Cosmos DB. It's not necessarily a database as much as a content engine, and it has been a major investment to re-platform.

Microsoft Azure Cosmos DB has reduced our total cost of ownership significantly, allowing us to sell our product at extremely competitive pricing, and Microsoft Azure Cosmos DB is a majority of the reason why that's true.

Super sharp latency and excellent availability are one of the best parts of Microsoft Azure Cosmos DB. Microsoft Azure Cosmos DB's ability to search through large amounts of data is excellent, unless we're talking about AI search with its cost problems. 

The challenge that we wanted to address with the built-in vector database was content discovery. Content discovery is a really hard problem in content management, and being able to find relevant content is a big-scale problem. We are using Microsoft Azure Cosmos DB for semantic search and providing AI capabilities that are beyond just simple vector search. It has been good; however, there have been some challenging issues for us.

We are really happy with the AI services in Microsoft Azure Cosmos DB, particularly their hybrid search feature, which combines AI search with full-text search, providing us with a great mix of search results.

Azure Cosmos DB is our database of choice for new applications and cloud-native applications. I use it anywhere.

Because it is NoSQL, it has the capability to adapt to changes. As compared to Azure SQL or other SQL databases, Azure Cosmos DB is schema-less. We can add new columns anytime, and the application will not break. It is very efficient for application-facing scenarios.

We use Microsoft Azure Cosmos DB mostly for maintaining our user databases in the document databases. Our firm has an app where each individual user's home screen is personalized according to their preferences, web searches, and metadata. For this, we maintain tags, and those tags, associated with each individual customer's mobile number, are stored in Microsoft Azure Cosmos DB to drive personalization and hyper-personalization on the app's home screen.

In terms of how Microsoft Azure Cosmos DB has improved my organization, the latency for API calls is pretty good.

We use Microsoft Azure Cosmos DB for one workload, which is a recent implementation. Microsoft Azure Cosmos DB has two use cases: storing unstructured documents and serving as a vector DB for AI purposes. We utilize Microsoft Azure Cosmos DB as a vector DB. In our company, we implement RAG (Retrieval-Augmented Generation) implementation of AI. In RAG implementation, we must chunk and store vectors in databases, so for our workload with RAG, we use Microsoft Azure Cosmos DB as a vector DB to store chunks. We have used the vector database with Azure AI services in our RAG applications.

Microsoft Azure Cosmos DB is not complicated to use; it's very user-friendly. The engine is approachable, and it's straightforward to implement, manage, and migrate. Microsoft Azure Cosmos DB improves reliability through replication in many regions in Azure. MongoDB, for comparison, is more complicated for replicating all clusters worldwide.

Microsoft Azure Cosmos DB is simple in many tasks, and for application performance, we can set many models for scaling, autoscaling, and pay-as-you-go models. We are more efficient with these features. The best feature of Microsoft Azure Cosmos DB is the replication all over the world. The second notable feature is the simplicity of deployment.

Microsoft Azure Cosmos DB is a good general-purpose database with low cost. For our little workload, it's very interesting to work with Microsoft Azure Cosmos DB. The ability to deploy a world-replicated Microsoft Azure Cosmos DB is very efficient in terms of cost.

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.

We use Microsoft Azure Cosmos DB for a lot of facets and various production-based products. In one case, we use it to store news articles and process information about them for AI processing. We also use Microsoft Azure Cosmos DB to store conversations with AI chatbots and for managing data pipelines and orchestration. These are just a few of our use cases.

We use the built-in vector database primarily for searching documents that live within Microsoft Azure Cosmos DB. For instance, if I have a lot of documents stored in Microsoft Azure Cosmos DB and I want to do vector-based searching on those documents, having the vector store in Microsoft Azure Cosmos DB makes a lot of sense because the vector store lives in line with the data. It is in the same workspace and the same region. We do not have to worry about ingress and egress charges because with it being co-located with our data, we are going to have better performance. In other cases, we use the vector database as a vector index for documents that do not even live in Microsoft Azure Cosmos DB. This could be documents that live in a storage account, for example. We find that the vector store within Microsoft Azure Cosmos DB is highly performant and a good place to store those indexes for fast searching.

We have primarily integrated it with web applications that live within Docker containers. They are Azure Container Apps and Azure Kubernetes Service (AKS). They are the primary ones. The nice thing about those services is that we have all of our custom code running within those containers. We use them in a couple of different scenarios. When we are using Azure Container Apps, those are within standard public endpoints, and the integration works quite well. In the case of AKS, we are doing that using private endpoints and virtual networks, so it is locked down a lot more, but the integration with Microsoft Azure Cosmos DB is still easy. That is because we are also using private endpoints for Microsoft Azure Cosmos DB. In both scenarios, it works quite well.

We use it quite a bit with Azure AI services. That goes hand in hand with using the vector store within Microsoft Azure Cosmos DB as well because we typically call out, for example, Azure OpenAI to do some embedding of the data that either lives in Microsoft Azure Cosmos DB or outside of Microsoft Azure Cosmos DB. We then store those results in the vector store. Also, sending the data content that lives in Microsoft Azure Cosmos DB as context to AI services works well too.

Microsoft Azure Cosmos DB has helped improve our organization’s search result quality in a couple of cases. In one case, it does that when we are using the vector store. We already talked about those unique capabilities, but in another case, we have used it alongside Azure AI search. Indexing the data that is in Microsoft Azure Cosmos DB in that search service works quite well. Using a combination of the vector stores and the content from Microsoft Azure Cosmos DB to do a semantic type of search or hybrid search options also works well.

We were able to see its benefits right away. That also comes down to our level of expertise. If you pay attention to how you model your data, how you set up the containers and configure them, and those things are optimized for performance, you will see immediate benefits. Those things are crucial to see immediate benefits. Some people might not know how to do those things as well at the beginning, so it might take a little bit longer. If you follow best practices and documentation, you can see benefits right away.

We use Microsoft Azure Cosmos DB as a NoSQL database to store JSON documents for our clients in the Banking, Financial Services, and Insurance sectors, primarily insurance. They require storage for numerous documents, including policy, claims, and costing documents, making Cosmos DB the ideal solution.

Because the company is spread across multiple regions, maintaining consistency with traditional relational databases was a challenge. Cosmos DB solved this by offering various consistency options and geo-replication capabilities. Logical partitioning within Cosmos DB improved routing efficiency, and composite indexes, combined with the partition key, optimized query execution by directing requests to specific documents, minimizing resource consumption.

Cosmos DB can offer faster data retrieval than SQL for certain queries and workloads, particularly those involving large volumes of unstructured or semi-structured data.

Cosmos DB is highly capable of handling large workloads and offers exceptional reliability for document storage and similar needs. Its particular strength lies in-stream analytics, a functionality currently not supported by MongoDB. This makes Cosmos DB the ideal solution for customers requiring real-time data processing, and it is our consistent recommendation for those working with stream analytics.

I have been working with Microsoft Azure Cosmos DB for approximately two years across seven projects. I started by creating basic containers at the free tier level that Azure provides, and when requirements grew, I moved them to the paid version. Azure typically provides two containers for free, after which you need to upgrade to the paid version. Of the seven projects, five were small projects and two were mid-sized projects. We created approximately 20-30 containers in total.

It works similarly to MongoDB when using NoSQL. When deploying on Azure, the communication is rather easy without many steps and complications, though this is more a benefit of Azure rather than Microsoft Azure Cosmos DB specifically. The queries take a similar amount of time compared to other databases, but the database management system provides a better-looking UI for viewing data compared to other solutions. 

The queries in Microsoft Azure Cosmos DB are faster when trying to fetch specific fields from JSON or run particular queries on a container.