Microsoft Azure Cosmos DB Reviews

My primary use case for this solution is collecting compliance data, which we use for SOC 2, SOX, and SOC 1 reporting.

The features that I find most valuable within Microsoft Azure Cosmos DB are probably the cost, as the cost optimization is good. The storage and queryability are good for what we're doing; it's a lot of unstructured data, so having a platform to put that in and then be able to harvest that data out for the reporting we do is essential.

In terms of cost saving, it was probably easily 30 to 40% cheaper than doing a standard SQL, which is what we saw just on piloting and getting in there. We were initially thinking 20 to 25%, but we were probably more at the 35 to 40%.

We are using Microsoft Azure Cosmos DB's hybrid search today.

The value that it has added to my AI or search workloads is that I think it's optimized that process and made it easier. We have a lot of unstructured data coming from different dissimilar systems and different data sources, so correlating those things together and making sense of it has been very beneficial.

Microsoft Azure Cosmos DB has had pretty good performance with searching through large amounts of data; it's been fast, and we haven't seen a lot of performance degradation while building larger queries and bringing in a large set of data.

The dynamic auto-scale or serverless model from Microsoft Azure Cosmos DB has helped reduce costs and operational effort; however, it's hard to quantify how that plays out since you're using a shared service. It shifts my focus away from building, managing, and upgrading to adding value.

Microsoft Azure Cosmos DB can be improved with more native out-of-the-box plugins. We have a lot of good ideas but find it challenging to implement because we're waiting for vendors to provide the necessary plugins. Building out that ecosystem would make the integration of other systems much easier.

I have been in my current role for eight years.

My impressions of the latency and availability of Microsoft Azure Cosmos DB are that we haven't had any latency issues that I'm aware of, and availability seems pretty good.

My impressions of Microsoft Azure Cosmos DB's ability to scale workloads have been decent; we have been able to scale up transparently without much worry from a performance perspective.

Customer service and technical support from Microsoft have been all right.

On a scale of 1 to 10, I would give them probably a six, maybe a hard seven at most. It depends on the issue; you often start with basic troubleshooting that we might have already done, and while there are escalation paths, getting to the right person can sometimes be a challenge.

Neutral

Before Microsoft Azure Cosmos DB, we used SQL and also had some Azure SQL, so we have a mix of those databases.

What stood out in Microsoft Azure Cosmos DB versus all the other competitors for us was just how easy it was to get it up and running; it was fast to get running with the least amount of effort needed from the team.

My team's experience developing with Microsoft Azure Cosmos DB SDKs and APIs has been pretty good; we've actually turned that into a production, internal application where people can self-service themselves on the front-end pieces we've built to the backend.

We have considered other databases; we are multi-cloud, so we've looked at a couple of competitors and piloted those, but we kind of landed on the Microsoft solution.

Microsoft Azure Cosmos DB is where we're going next for AI or real-time applications such as Copilots, personalization, and recommendations. Right now, the data itself is pretty dynamic, but the output is pretty static. The idea is to take that and make it more dynamic so that instead of creating a report, you can ask the AI specific questions about the data, and it should be able to build those reports for you.

The primary reason for switching to Microsoft Azure Cosmos DB was to try something new, which may sound unconvincing, but we wanted to see if it could prove out. There were also cost savings and optimization opportunities that seemed promising for our new projects.

My advice for someone who is considering Microsoft Azure Cosmos DB is to do some testing with it and give yourself time to think about your data in a different way, as it's a different concept from SQL. For us, it has worked out pretty well for a lot of unstructured data. I would rate this solution an 8 out of 10.

We built a chatbot for one of the clients, which is a trading-related chatbot that assists with trading queries. We use Microsoft Azure Cosmos DB to store customer interactions.

It performs very well, especially under high load where it automatically scales up the RUs. The main advantage of Microsoft Azure Cosmos DB is its low latency, with response times in milliseconds, making it great for chatbots.

I am a part of the NLP team. We primarily use Azure Cosmos DB and MongoDB, specifically leveraging their NoSQL capabilities for storing unstructured data, such as JSON formats. This is crucial since we need to access data in milliseconds and handle all operations, including storing, writing, and reading. The client's expectations for response time are quite high. Large Language Models (LLMs) can be time-consuming, so we aim to minimize latency. This serverless architecture helps us significantly in achieving shorter response times compared to other services.

The best features of Microsoft Azure Cosmos DB include its support for asset properties, which makes it more secure and easy to understand. The auto-increment feature is particularly good, and overall, it remains user-friendly and supports multiple SDKs effectively.

Microsoft Azure Cosmos DB demonstrates good capabilities for searching through large amounts of data. It is easy to maintain, offers good quality, and is straightforward to understand and deploy. Its scalability is excellent, supporting all asset properties. 

Microsoft Azure Cosmos DB is quite easy to use. It offers five to six types of inference options such as Python and NodeJS, or REST APIs, and we primarily used Python. Python was very helpful because it is easy to read, easy to understand, easy to implement, and easy to maintain.

The initial deployment of Microsoft Azure Cosmos DB, particularly involving managed identity and service principal, is quite challenging due to insufficient documentation. However, deploying via key access works and is easier. 

I expect improvements in Microsoft Azure Cosmos DB, particularly in the vector database area. In comparison to Databricks, there’s a functionality in Databricks that allows direct updates of the data structure. For instance, we have a use case to display live dashboards to customers where a chatbot is used by around 200 end-user customers concurrently. When wanting to display the queries and responses, along with evaluation metrics, all this information is stored in Microsoft Azure Cosmos DB. However, to show this in real time, we need a live connection that automatically updates in response to new records being inserted. This automated updating feature is lacking in Microsoft Azure Cosmos DB compared to Databricks.

There’s a lack of proper documentation regarding service principals and managed identities, which necessitated referring to various resources to implement these features, making it challenging.

I have been using Microsoft Azure Cosmos DB for the last two years.

I would rate the stability of Microsoft Azure Cosmos DB as eight out of ten. 

I would rate the scalability of Microsoft Azure Cosmos DB as very high, around nine out of ten. One of its best features is the auto-scaling ability, which has no delay. It automatically scales RUs in milliseconds, ensuring a robust security level with Entra ID, managed accesses, and service principals that help with internal products. Utilizing all Azure services with managed access keys provides added security against data leakage, alleviating concerns about key exposure.

I would rate the technical support for Microsoft Azure Cosmos DB an eight out of ten. 

Positive

The initial deployment of Microsoft Azure Cosmos DB, particularly involving managed identity and service, was quite challenging due to insufficient documentation. However, deploying via key access works and is easier.

Onboarding with Microsoft Azure Cosmos DB is straightforward, as the learning process is simple to understand due to comprehensive documentation.

Maintenance is required when using key-based services in Microsoft Azure Cosmos DB. If we use service principals, the maintenance needs are reduced, but some overall maintenance is still necessary. Regular checks are optional for system status, and we prefer to keep resources minimal.

Only one person was required for the deployment of Microsoft Azure Cosmos DB.

In terms of budget, Microsoft Azure Cosmos DB offers multiple selection options from Azure, allowing us to choose services such as auto-scale and select how many RUs we need at any time. We typically recommend going with auto-scale, as it automatically increases RUs during high load and decreases them during low load. 

The pricing is quite competitive, providing some free GBs to practice before implementation, alongside a good backup system. The backup duration is around 90 days, differing based on the tier we select. 

I am not entirely sure about the exact costs. Before presenting the solution to our client, we compared RU costs on Azure and AWS. The client specifically required a secure platform, prompting us to choose service principals, meaning we commit to all Azure services such as Azure OpenAI, Azure Cosmos DB, Azure Applications, Azure Monitor, Azure App Services, and Azure Kubernetes. Overall, we find the storage costs comparatively high. Comparatively, AWS offers similar features, but at a slightly lower cost, and I would rate their support a seven.

We have not used the AWS marketplace for purchasing; we exclusively go with Azure. Upon comparing costs between AWS Cosmos DB and Azure Cosmos DB, the pricing in Azure tends to be higher.

Vector database capabilities exist in Microsoft Azure Cosmos DB. They allow us to store vectors in NoSQL or other containers such as tables, although we only utilize a few features. While it is possible to store vectors, we can’t search for them directly since vectors have multiple dimensions; thus, we can only store them.

Microsoft Azure Cosmos DB has helped improve our search result quality, although there is no perfect searching technique here. We need to utilize SQL queries, which are not standard SQL queries, requiring us to create specific SQL queries after reviewing the documentation. This includes reading samples provided in the documentation to access the data effectively.

I would recommend Microsoft Azure Cosmos DB to others who seek solid security and wish to protect their data without exposing keys and values. API-based authentication mitigates risks associated with lost keys. Using service principals and managed identities is advisable for enhanced security. However, if the effort to manage keys is unappealing, I suggest exploring other platforms that may not offer the same level of data security. 

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

My main use cases for Microsoft Azure Cosmos DB are usually warehouse software, as I'm mainly using it for storing all our data that has to go in and out very quickly.

My favorite feature of Microsoft Azure Cosmos DB is multi-region; being able to automatically enable multi-region is something I appreciate, as well as Synapse.

I appreciate it because we have a read-only data store and we don't have to do anything but check a checkbox and it's magically there.

These features benefit my company as a whole because we're multi-region, so we can handle a region down without a lot of problems, and Synapse lets us do the analytics part of it, allowing us to send that to our analytics people without causing any problems for our normal operations.

I think Microsoft Azure Cosmos DB can be improved by providing continuous backup for multi-region rights. I believe it's available for non-multi-region rights, but there are many features that are locked behind continuous backup that I can't use because it's not enabled yet.

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

I haven't noticed any problems with the latency of Microsoft Azure Cosmos DB at all, so it seems to be really solid.

The scalability regarding scaling workloads works effectively; for holidays, we had to scale it up, and that basically solved the problem.

I evaluate customer service and technical support for Microsoft Azure Cosmos DB as good; whenever I've called them, I've had good results getting a response.

Positive

Prior to adopting Microsoft Azure Cosmos DB, I was using another solution that met those same needs.

I switched because it was an on-premises solution that's being end-of-lifed, and I wanted something in the cloud.

The migration or implementation process faced challenges mainly in going from a relational to a DocumentDB; that was the biggest obstacle, trying to get the models right and the partition keys right.

I solved it through numerous iterations.

Microsoft Azure Cosmos DB has helped decrease my company's total cost of ownership.

It's easier because we have less to maintain; we're not trying to set up multiple SQL servers with replication and everything. I can maintain only Microsoft Azure Cosmos DB, and it handles everything for us. We can have one Cosmos account that has all our things, so centralization helps a lot.

Microsoft Azure Cosmos DB's pricing model has aligned with my budget expectations because I can tune the RU as I need to, which helps a lot.

Microsoft Azure Cosmos DB's dynamic auto-scale or serverless model has helped reduce costs and operational effort.

Auto-scale has been beneficial because we use it in many places, as we have a lot of cyclical things; it'll run heavy for a couple of hours and then it doesn't run at all for the rest of the day, so we use auto-scale almost everywhere.

I have probably not considered switching to another solution while using Microsoft Azure Cosmos DB since we've done other things in addition to it, but I appreciate Cosmos.

I am not using Microsoft Azure Cosmos DB for AI or real-time applications yet.

I have not used Microsoft Azure Cosmos DB's built-in vector or hybrid search.

I assess Microsoft Azure Cosmos DB's ability to search through large amounts of data by saying if I provide it the right information, it does really effectively; otherwise, if I can't provide it the partition key, then it's much more painful.

I have integrated Azure Functions with Microsoft Azure Cosmos DB.

I assess the overall experience of using Microsoft Azure Cosmos DB with these services as good; it's worked really effectively.

I have not had any problems with the integration of Azure Functions and Microsoft Azure Cosmos DB since it's pretty straightforward.

I would describe my team's experience developing with Microsoft Azure Cosmos DB SDKs and APIs as good; we've had pretty good results with it. We're starting to try managed identity; we haven't used that yet, but we're moving to that in the next couple of months. However, we haven't had any trouble with it at all.

Microsoft Azure Cosmos DB's dynamic scaling has helped decrease my company's overhead costs.

I would say it has decreased costs by at least ten percent to a quarter.

My advice to other companies considering Microsoft Azure Cosmos DB is to be prepared for the fact that DocumentDB is the trickiest thing, especially getting used to the partition keys, but other than that, the replication and everything is very handy and makes it easy to manage.

I would rate my overall experience with Microsoft Azure Cosmos DB as a nine out of ten.

My main use cases for Microsoft Azure Cosmos DB involve real-time analysis, where we store information inside Microsoft Azure Cosmos DB as a speed layer, and this use case is now in production. We do analysis with Synapse, and I currently use Microsoft Azure Cosmos DB with a generative application for an agent, serving as the memory cache for the agents. Additionally, we utilize it for user information, such as user settings, and also for microservices applications to store information about products or entities within the customer platform.

In our project, we use Microsoft Azure Cosmos DB for all things related to AI. We utilize it as an object store for tool calling for agents, where we store the results of information that the agents call from the MCP server. This capability helps our agents retrieve information and provide context to the workflow, as well as the reasoning of the model for the agents. Furthermore, another implementation of Microsoft Azure Cosmos DB is for the conversational layer of our application, which involves conversation feedbacks and all types of user information, being essential for the context of our agents and our model.

The features of Microsoft Azure Cosmos DB that I appreciate the most include the CRUD feature: create, read, update, and delete. This feature operates within a logic partition and is fully hosted by Azure, and my colleagues and I understand the primary key which is most usable within our context for utilizing this CRUD feature effectively.

Microsoft Azure Cosmos DB's ability to search through large amounts of data is very useful because it is highly responsive and performs queries faster than other types of databases such as SQL or SQLite, largely due to our capability to index the fields within the document.

We integrate Microsoft Azure Cosmos DB with Azure Kubernetes Services, Azure Functions, and Azure Container Apps, which I find very useful. For instance, Azure Functions provide a trigger for an event when a row is updated or inserted within the Microsoft Azure Cosmos DB container.

A way Microsoft Azure Cosmos DB could be improved is through the introduction of an access control list on a row and on a specific field within the document, rather than relying on application-level coding to manage different access control lists.

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

The latency of Microsoft Azure Cosmos DB is very good, and the service responds accurately, with high availability of data and backup, which is critical for us when our application is in production.

Microsoft Azure Cosmos DB scales workloads effectively, and when I set the scaling to automatic, it responds quickly and performs very well.

I have not had any direct contact with customer support for Microsoft Azure Cosmos DB. However, I have found that support for other services such as Azure Functions is very prompt and effective, with people responding quickly and providing valuable assistance.

Neutral

In my company, I have not used another kind of NoSQL implementation before utilizing Microsoft Azure Cosmos DB.

I can tell you that there has been a thirty percent reduction in costs and operational efforts, with reductions also reaching up to fifty percent and forty percent in different instances.

I find Microsoft Azure Cosmos DB's pricing model correct and aligned with my budget expectations. For all the use cases with my customer, I see considerable potential to arrange a budget for this type of service.

The dynamic autoscale or serverless model of Microsoft Azure Cosmos DB has indeed helped reduce our costs and operational effort by allowing us to scale horizontally in a straightforward manner according to our needs. For example, when the workload increases, we can easily scale manually, and we can also set a threshold for scaling to ensure maximum performance for the service.

My company has not considered switching to other products.

I am using Microsoft Azure Cosmos DB for both AI and real-time applications.

I have not used Microsoft Azure Cosmos DB's built-in vector or hybrid search because our clients prefer to use MongoDB with the RU feature. Therefore, I do not use Vector DB in production; however, I have utilized the Vector Database in simpler cases based on my experience. In other scenarios, we resort to AI Search because our clients opt for Azure AI Search.

In terms of my team's experience developing with Microsoft Azure Cosmos DB SDKs and APIs, I primarily use only the SDK and not the APIs, as the SDK fulfills all our requirements for the deployment lifecycle. I rely heavily on the SDK, for example, to create indices within a container during production maintenance and for configuring the release of our code to production. Creating indices and managing the container is very simple with the SDK, which I find is excellent for Microsoft Azure Cosmos DB for NoSQL, although I notice that the Mongo SDK does not integrate as effectively for this type of database.

Microsoft Azure Cosmos DB's dynamic scaling has indeed contributed to decreasing our operational overhead costs.

My advice to other companies considering switching to Microsoft Azure Cosmos DB is that the SDK makes it very simple to create a container or a database, and managing it, including backup and restoring to a previous data point, is very straightforward. I rated this product with a nine out of ten.

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.

The main downside I have faced was with hierarchical partitioning in Microsoft Azure Cosmos DB. When using the second partition within hierarchical partitioning, I encountered issues while fetching queries. Though it retrieves values, the performance is not optimal when using partitioning. For example, when dealing with users and different categories of users in hierarchical partitioning, the query results were not providing all the desired results. The documentation regarding partitioning keys was limited, and despite contacting support, the problem remained unresolved. Additional documentation on this feature would be beneficial.

I have been using Microsoft Azure Cosmos DB for approximately two years.

Lag only occurs when different resources are set up at different locations. When all resources are at the same point, there is no lag. In production, we have experienced minimal issues. The project has been live for two years without any database problems. We decreased the timeout for connections and queries to two seconds, and it works efficiently. Our project remains at mid-scale without requiring a load balancer at the Microsoft Azure Cosmos DB level.

Given the RU size, it can scale up significantly. If the user base increases, increasing RUs to handle more database calls is not problematic. Azure has done an excellent job making everything more scalable, including Microsoft Azure Cosmos DB. The plans allow for easy upgrades based on user growth, supporting parallel queries and increased call volumes. You can move to a better plan if you are going to have more users.

The response time you experience mostly depends on the specific service you are using. For instance, For Azure AD-related issues, their support was quite fast and effective. However, with Azure AI speech service, I faced some challenges. They didn't provide a precise answer to my issue, but they did share some documents for reference. It took about 48 hours for them to respond, and even then, the solution they offered wasn't exactly what I needed.

On the other hand, my experience with Azure Cosmos DB was more positive. I had a specific inquiry regarding partitioning, and their support team was helpful. One representative reached out to me, and we discussed the issue. They were able to guide me in implementing different hierarchical IDs to structure the data better. Our goal was to optimize our queries and reduce API calls. Overall, their response took around seven to eight hours, and I felt they effectively resolved my concerns.

Overall, I would rate their support an eight out of ten. Specifically, if I focus on .NET, I find their support to be excellent. However, for other services, such as Azure reports, there are still issues that prevent me from giving a higher score, so in those cases, I would rate it a seven.

Positive

I previously used MongoDB. The choice depends on requirements. Microsoft Azure Cosmos DB is optimal for simpler structures with fewer containers and less complex data partitioning, offering faster queries. For more complex database structures, MongoDB might be preferable. However, when using other Azure services and hosting on Azure, Microsoft Azure Cosmos DB works best. The choice ultimately depends on the entire application architecture and hosting environment.

The onboarding process and learning to run queries is straightforward. It requires only a connection string for the database and container name to run queries. Migration from SQL to NoSQL is relatively simple due to easy syntax and connection process. The initial setup took approximately 5 minutes using the emulator on the local machine, and the Azure subscription setup required only about a minute. An API was used to create all containers efficiently.

The pricing is calculated per query with specific calculations, though I cannot provide detailed information about this aspect.

I have worked with Azure AI services including translation, transcription, and speech synthesis. We used Microsoft Azure Cosmos DB for storing links to storage accounts for AI-generated data, utilizing NoSQL queries for data retrieval. Azure AI services can be somewhat challenging to integrate, in my opinion. I find that integrating Microsoft APIs is generally harder compared to others. In this case, we weren't using the Vector DB explicitly; instead, we utilized Microsoft Azure Cosmos DB. We relied on standard containers, and I believe we had about seven or eight containers in total.

We generated our data using AI services and then stored it in these containers. The links to specific storage accounts for each request were saved in Cosmos DB. When we needed to retrieve that information, we used queries to fetch the data.

In a banking project, we used the Vector DB capabilities of Microsoft Azure Cosmos DB, though limitations were due to our API standards rather than database limitations. The team later discovered and implemented the inbuilt vector DB features when the database grew.

Overall, I would rate it a nine out of ten with the only significant issue being the partitioning key functionality. It's a good alternative to other NoSQL databases.

We are in retail and marketing, and Microsoft Azure Cosmos DB gives us the opportunity as a retail industry to store catalog data. This is essentially used for event sourcing. In my department, it is particularly useful for our catalog data storage and marketing operations.

Microsoft Azure Cosmos DB has improved our overall search result quality. It is very easy to use Microsoft Azure Cosmos DB to search through large amounts of data. This is one of the advantages that I can mention with Microsoft Azure Cosmos DB, which is not available or accessible with other solutions. Searching and working with large amounts of data while using Microsoft Azure Cosmos DB is one of the biggest advantages it provides for enhanced business operations.

The aspect I appreciate most about Microsoft Azure Cosmos DB is the scalability. Horizontally, we can add as many servers as possible, which is very key for us as a company. Another important feature is that it is a globally distributed product that comes with numerous benefits. The real-time analytic features it offers, as opposed to structured query language features, provide real-time analysis for our retail and marketing operations. The integrated features, such as Azure Snipes link, enable easier running analytics for our operations. Additionally, we have noticed that it positively impacts our transactional performances as a company.

In terms of improvement for Microsoft Azure Cosmos DB, while it eliminates the burden of managing database infrastructure, we realized it might not be possible to use various models simultaneously as it only accepts a single model at any given point in time. This is an area that could be improved upon.

The operational complexity of Microsoft Azure Cosmos DB can be challenging for individuals who are not tech-savvy. Making it simpler for companies to navigate through various features would be beneficial for future development in terms of reducing its complexity. However, it remains a good product that eliminates many bottlenecks we experienced before in terms of database management, storage, transmission, and retrieval for our business.

While there is complexity in Microsoft Azure Cosmos DB, we have found that software experts and IT professionals who are passionate about the product can overcome these challenges. We have not yet achieved fifty percent in terms of training our staff due to its complexity. However, the benefits significantly outweigh the complexity, particularly in terms of database storage, management, retrieval, and transmission in milliseconds. The global access, real-time capabilities, and low latency in terms of turnaround time make it an excellent solution once fully embraced and deployed.

We have been using Microsoft Azure Cosmos DB for one year.

The initial deployment of Microsoft Azure Cosmos DB was challenging at the beginning, but we overcame these challenges and ultimately achieved positive results.

The performance and stability of Microsoft Azure Cosmos DB maintains low response times in milliseconds. It is fast, effective, and reliable.

In terms of scalability for Microsoft Azure Cosmos DB, the servers can be horizontally scaled, and we can add as many servers as needed. This capability is possible with Microsoft Azure Cosmos DB, which is not common in other solutions. This is a significant advantage of Microsoft Azure Cosmos DB.

It took us approximately three to four weeks to fully set up Microsoft Azure Cosmos DB and get it operational. Our company utilizes multiple software solutions, so integration was a key consideration. With a team of six to seven software developers, along with additional IT experts, we completed the setup within this timeframe, which we considered reasonable for this type of product.

Our company has multiple software solutions, and integration is a crucial aspect. We have a team of six to seven software developers, along with additional IT experts, who assist in working with these software solutions.

I have used SQL as an alternative to compare with Microsoft Azure Cosmos DB. Having Microsoft Azure Cosmos DB come with additional features beyond SQL capabilities was advantageous for our company's deployment.

I rate Microsoft Azure Cosmos DB a 9 out of 10 because there is always room for improvement in any software.

The benefits of Microsoft Azure Cosmos DB were immediate for us. It was within our budget, and we cannot say it constrained our finances because it was approved. The cost-benefit analysis shows that the benefits outweigh the costs. The maintenance costs are also within our estimated budgeted projections as a company.

I am willing to provide references for Microsoft Azure Cosmos DB and can be a reference for anyone interested in purchasing the same product. I am available to be contacted by Microsoft regarding this review should they have any questions.

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.

Overall, Microsoft Azure Cosmos DB is phenomenally easy to use; it is very good. As NoSQL databases go, or as an Azure product, it's great. The search, configuration, and ease of cost management have been a really great experience.

The efficiency of search capabilities is significant, particularly when it comes to the flexibility of conducting in-depth, almost recursive searches that are both efficient and cost-effective. We are currently part of an early access program for a new feature called Fleet Spaces. This feature allows us to manage costs across different tenants effectively. In our setup, each customer has a dedicated tenant in Microsoft Azure Cosmos DB, which means we do not share databases. This approach provides the additional security and restrictions our customers desire, and it helps avoid issues related to noisy neighbors. However, the challenge with this model is that we cannot easily share costs between tenants. Fleet Spaces offers a solution that combines the benefits of multi-tenancy while still isolating each customer's tenant. This is especially important for large enterprises and marketing companies that prefer to keep their content completely separate from others. Additionally, we can share bursts of resources across these tenants, allowing us to gain some advantages of multi-tenancy without compromising security. The vector search functionality is also noteworthy, as it provides all the necessary tools for implementing AI-driven search capabilities. My architect could probably add more insights, but overall, we are pleased with the solid uptime and reliability of this new feature.

The speed of search with Microsoft Azure Cosmos DB is 10 to 100 times faster, and while I don't have a metric yet for recall, I can say that the actual ability to get more content does not have a static metric currently.

For integrating Microsoft Azure Cosmos DB with other Azure products or other products, there are a couple of challenges with the current system. Right now, the vectors are stored as floating-point numbers within the NoSQL document, which makes them inefficiently large. This leads to increased storage space requirements, and searching through a vast number of documents in the vector database becomes quite costly in terms of RUs. While the integration works well, the expense associated with it is relatively high. I would really like to see a reduction in costs for their vector search, as it is currently on the expensive side.

The areas for improvement in Microsoft Azure Cosmos DB are vector pricing and vector indexing patterns, which are unintuitive and not well described. I would also like to see the parameters of Fleet Spaces made more powerful, as currently, it's somewhat lightweight. I believe they've made those changes intentionally to better understand the cost model. However, we would like to take a more aggressive approach in using it. 

One of the most frustrating aspects of Microsoft Azure Cosmos DB right now is that you can only store one vector per document. Additionally, you must specify the configuration of that vector when you create an instance of Microsoft Azure Cosmos DB. Once the database is set up, you can't change the vector configuration, which is incredibly limiting for experimentation. You want the ability to try different settings and see how they perform, as there are numerous use cases for storing more than one vector in a document. While interoperability within the vector database is acceptable—for example, I can search for vectors—I still desire a richer set of configuration options.

We've used Microsoft Azure Cosmos DB in smaller circumstances around our ecosystem for about 3-4 years. Recently, we've made a major investment in shifting our main product's database to Microsoft Azure Cosmos DB. While we've been using it for 3 years, our bigger investment project has been ongoing since December.

The stability of Microsoft Azure Cosmos DB is excellent. The uptime is five nines and very consistent.

I rate the scalability of Microsoft Azure Cosmos DB as excellent, as it is the best.

Approximately 50 users work with Microsoft Azure Cosmos DB in our organization.

We are in a privileged position because we have access to the product team. I don’t think I can speak for most other organizations in terms of customer support, as we are part of many of their early access programs. This means we can easily communicate with the principal product manager of Cosmos DB, and he responds within a day. It's been phenomenal, but I don't think this is how everyone else operates.

Prior to using Microsoft Azure Cosmos DB, we were using SQL Server. The cost model of Microsoft Azure Cosmos DB is great. The SDKs are better than MongoDB. Microsoft Azure Cosmos DB is distinctly better for what we need.

The initial setup for Microsoft Azure Cosmos DB is really straightforward. My developers love using it, and they find it very easy with strong SDKs, so there haven't been many moments where they don't know what to do next. It took us a couple of days to deploy Microsoft Azure Cosmos DB in our lower environments.

Microsoft Azure Cosmos DB does require maintenance. Most of the maintenance involves two main aspects. Firstly, we did not have NoSQL database administrators, which made the transition more challenging. We had to learn the skills necessary for maintaining a NoSQL database, requiring a significant investment in our own development. Secondly, we are constantly engaged in performance tuning and cost management, both of which require ongoing attention.

It took a couple of days to onboard our team with Microsoft Azure Cosmos DB, and I found the learning curve straightforward. The hardest part was for the DBAs since they are trained in SQL and struggle to transfer that skillset, but developers onboarded quickly.

Regarding return on investment with Microsoft Azure Cosmos DB, we estimate a significant amount of time saved. Our competitor took 2 years to rebuild their content management system, while we plan to go live in 8 months, and we feel that a large amount of that is due to using Microsoft Azure Cosmos DB.

This cost model is beneficial because it allows for cost control by limiting resource units (RUs), which is ideal. However, for our needs, we can't engage with their minimum pricing, which ranges from 100 to 1,000 RUs. At the bare minimum, we need to use 4,000 RUs for a customer. I would like to find a way to gain some advantages from the lowest tier, particularly the ability to scale down if necessary. It would be helpful to have more flexibility in cost management at the lower end.

The RU model is great for planning costs, but their vector search is prohibitively expensive and needs to be reevaluated. The pricing just doesn't make sense. For instance, if I want to search a hundred thousand documents in the vector database, it would cost me thousands of RUs, whereas reading from a traditional database only costs one RU, regardless of its size. Even if it's an AI read, the disparity in pricing is concerning. The overall scaling of costs seems off.

We did an extensive evaluation of different databases and different database models. We evaluated SQL Server, Cosmos Postgres, MongoDB, Neo4j.

I would definitely recommend Microsoft Azure Cosmos DB due to its reliability, cost management, and being a really high-performance database.

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

Our main use cases involve syncing client accounting data and containers, and we use it as a read database. We do not put much into it; we just sync from their on-premises data or from other APIs, and we collect things.

We have not used enough features of Microsoft Azure Cosmos DB yet, which is why I'm here to try to use more. We're trying to figure out how to do more by linking data from things like documents and our SQL structured databases into Microsoft Azure Cosmos DB. Our goal is aggregating our clients' data to run searches or reporting, and we're trying to learn how to use it more.

I evaluate the enterprise-grade security features of Microsoft Azure Cosmos DB in terms of data encryption and access control as excellent.

The scaling of Microsoft Azure Cosmos DB's automatic elastic scaling of throughput and storage works fine in our current projects, and we use shared throughput successfully.

The scalability and ease of use with the APIs of Microsoft Azure Cosmos DB have allowed us to meet our customers' expectations pretty easily with little barrier to entry.

The features have allowed us to become SOC 2 and NIST compliant relatively easily, so I would say that's been a good success for us.

I have not utilized Microsoft Azure Cosmos DB's multi-model support for handling diverse data types.

We haven't really used the global features; we don't make it multi-regional and only have a backup, so there hasn't been a reason to utilize globalization.

There is nothing right now; that's something that we'd be interested in regarding Microsoft Azure Cosmos DB's consistency models and their role in fine-tuning the performance of our applications.

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

I faced nothing that we couldn't overcome pretty easily; there were no significant issues. It's always a learning curve, but it wasn't hard to get past.

I wouldn't say we have benefited from the workload management by using it; we just sync data to it and make it available for people to retrieve.

I evaluate my customer service and technical support experience as great; anytime I've needed technical support, it's been excellent.

On a scale from one being the worst and ten being the best, I give my customer service and technical support a ten.

Positive

Prior to adopting Microsoft Azure, I wasn't using a different solution to address similar needs.

My experience with deploying Microsoft Azure has been relatively painless; it has been easy, and we haven't had any problems yet.

I have seen a return on investment.

We use it to sync data that is not easily accessible; the scalability and ease of integration into our system have been where our return on investment is.

We considered all Azure solutions before selecting Microsoft Azure Cosmos DB, including table storage, but Microsoft Azure Cosmos DB was a better fit, and we haven't looked at any other solutions.

I wouldn't know how Microsoft Azure Cosmos DB can be improved because I don't think we use enough of it; I need to learn more about what to use in Microsoft Azure Cosmos DB.

I find the pricing transparency of Microsoft Azure Cosmos DB to be a little confusing, but we're figuring it out.

I would recommend Microsoft Azure Cosmos DB to another organization that's considering using it. I gave this review a rating of nine.

We have a very large team of developers who develop a solution for our customers. In the part where they need some infrastructure on Microsoft Azure, we deploy entire environments of different types such as development, testing, production, and pre-production to Microsoft Azure and configure it, monitoring that infrastructure, one of them being Microsoft Azure Cosmos DB. Later, we hand over those resources to our development team and they can start to use it.

For example, we have one application which is for one of our post offices where they host their main application for tracking packages, for sending packages, and for everything they provide to their customers. The main database for this solution is Microsoft Azure Cosmos DB.

In production, we definitely are using automatic scaling because of the workload, since some days there is a workload which is very high and some days it is not so high. For non-production environments, it's a minimal setup with minimal SKU on Microsoft Azure.

Availability is for sure better with Microsoft Azure Cosmos DB, but it's also the biggest cost for that setup. We are a very small country from Slovenia, so our customers don't require so much high availability for their applications. This leads us to set up resources only in one region for most of them, while for the most critical workloads, such as those from banks, we use the multi-region setup and auto-scaling.

About the performance, I monitor everything that's going on, what is possible on the resource level in Microsoft Azure, and we also do the FinOps solutions for our customers, utilizing different metrics to optimize resources and the entire setup.

Overall, I think Microsoft Azure Cosmos DB works fine. I don't remember any case where our developers or our clients have been disappointed with it.

The benefits we and our clients have seen from using Microsoft Azure Cosmos DB are similar to those most platform-as-a-service solutions provide, where you don't need to take care of the underlying infrastructure, which is the main reason.

I have not utilized Microsoft Azure Cosmos DB multi-model support for handling diverse data types.

I'm not in the position to decide if clients will use Microsoft Azure Cosmos DB or any other database. However, I notice that there is more and more Microsoft Azure Cosmos DB setups in different applications.

The only problem I face is more with infrastructure as code templates that don't cover everything that can be set up or configured on the portal, requiring some manual work which is additional work for us. Some resource providers don't provide certain configurations, which I think is on Microsoft's side because they need to change Azure Resource Manager and the version of templates. Other aspects involve different providers for those templates including Azure Verified Modules with pre-configured templates on the community and the team working on them.

I have been using or working with Microsoft Azure Cosmos DB for the last year and a half.

I usually use Microsoft support, and I would evaluate them around one to ten as very bad for the first level. They have some instructions and procedures they follow without listening to customers, primarily seeking to get their checkboxes rather than fully understanding the customer's needs. However, upon reaching the product group or a higher level, the support was great. I currently have one critical ticket open for another solution and it has been handled excellently.

Based on my experience with Microsoft support, I would rate them around eight on a scale of one to ten. To make it a ten for me, they need to listen to customers more instead of just going through their automatic process.

Positive

Our clients see metrics in terms of ROI after some time, but not at the beginning. They usually observe cost saving and time saving post-optimization when we find the right SKUs because most of the time, they don't know what they need regarding the required SKU or size of some resources. After time, for sure, they see ROI.

On average, the kind of savings we see ranges from 15 to 25 percent. The savings I refer to are in money saving.

In my opinion, the main difference between Microsoft Azure Cosmos DB and other types of databases is hard to say. It's mostly how developers see everything, as it depends more on the development side—what they want to use and what features they need, such as relational databases or document databases. This leads us to select the right database based on those inputs. The selection is based on the use case.

We are implementing other Microsoft Azure solutions like Azure SQL and Postgres. We focus only on Microsoft Azure and do not work with other vendors like AWS. I gave this review a rating of ten out of ten.

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.

The most valuable feature of Azure Cosmos DB is its scalability. That is the biggest reason I use Azure Cosmos DB.

I also like its developer-friendliness. It is very easy to begin with. Microsoft and Azure are good with that. With all the getting started information and all the introductions, it is very easy to begin with. Optimization is where it gets a bit trickier. That is where you need to be more active and understand why things are not performing as they used to. Most of the time, performance is not a problem. It is always fast. The problem is more around the cost consequence of that performance.

Its vector capabilities are new. They were implemented just months ago. There are probably three things that we were looking to address by using the vector database. The number one is the cost of Azure AI search and indexing. Before this feature came out in Azure Cosmos DB, the alternative for me was using AI search, which is way more expensive if using it as a vector database. Now with Azure Cosmos DB, that price point becomes much more accessible. That is number one. 

Number two is the developer familiarity aspect of things. AI search is more around enterprise use cases or enterprise search and requires more specialized skills to begin with, whereas Azure Cosmos DB is more or less a commoditized developer platform that is much more accessible to a wider developer audience. That is another aspect that it has addressed. For example, if I have a new starter in my team, it is easier to train that person on Azure Cosmos DB than the AI search. With the explosion of LLMs, AI agents, and things like that, the vector database on Azure Cosmos DB is a good place for developer onboarding. It is just way easier. 

The third part is still related to the developer experience, but in terms of the SDK aspect, the libraries available for Azure Cosmos DB are already well-established in the ecosystem. With the vector database capability, it is just a matter of adding an extension of those existing libraries. That means if the applications that are already using Azure Cosmos DB want to jump to the vector database, the jump would not be that big. It is just a matter of implementing it directly with their existing Azure Cosmos DB that they are already using.

We have used the vector database with Azure AI services. The other aspect is using the vector database with document intelligence. We use document intelligence to process a raw PDF document and things like that. From there, we convert that into embeddings, and then those embeddings will be stored in the vector database. It is something we use as a landing spot for new LLM applications.

The quality has improved because, traditionally, we did things in batches. We processed documents once a day or every twelve hours or so. With this new capability, we are very confident to run those processes in real-time. As new documents come in, the process and the workflow can get triggered. It is not a batch anymore. It is in real-time.

Azure Cosmos DB’s ability to search through large amounts of data is yet to be determined. Large is subjective at the moment. I have only tested it up to 2 gigabytes, and for that, it is working pretty well.

Azure Cosmos DB is our default. We do not question it anymore. After migrating out applications from an SQL database to Azure Cosmos DB, the change in the organization is massive. Especially on the application side of things, app developers are much more productive and lean. Previously, we had to go through a very rigorous process. To add new columns, tables, and other things, we had to work with DBAs. With Azure Cosmos DB, we can have a PoC and POV in weeks, sometimes days, instead of six months. That is how the whole NoSQL ecosystem changed our life cycle and productivity.

Azure Cosmos DB has changed our total cost of ownership for old applications, but not for new applications. For those who are still using SQL Servers or other databases, there was an added TCO because different projects are using different databases, whereas about 10 or 15 years ago, we had just Oracle, SQL Server, or IBM. For new applications, it is the default for us, so there is no change in TCO.

There are several areas for improvement. Firstly, having a local development emulator or simulator for Azure Cosmos DB would be beneficial. It would be very handy to have a Docker container that developers can use locally. Although, I know there is a free tier and so on and so forth, having a local environment would be nice. For example, SQL Server is very portable. You can even install it on your machine. That is the number one thing that is missing in Azure Cosmos DB.

The second improvement area is the IDE of choice. That means how you interact with Azure Cosmos DB. For example, with SQL Server, you have SQL Server Management Studio. I know there is a little bit of support for Azure Cosmos DB in Azure Data Studio, but it is not heavily advertised or it does not feel like first-class citizen support. Developer experience or developer tooling is missing in terms of interacting with the database. Better developer tools or an IDE for interacting with Azure Cosmos DB would enhance the developer experience.

Lastly, there is some mixed messaging about what Azure Cosmos DB is, given its multiple APIs. There are so many Azure Cosmos DB APIs available. There is NoSQL. There are MongoDB, Gremlin, and others. There is still some mixed messaging for others who are new to Azure Cosmos DB about what Azure Cosmos DB is. Is this like MongoDB, but then there is also MongoDB in Azure Cosmos DB? I know it well, and I know that the default one is just NoSQL, but others I have interacted with over the last ten years or so get confused.

I have been using Azure Cosmos DB for over a decade. I have been using it since it was announced.

The solution is very stable, and I cannot recall a time when Azure Cosmos DB let us down. I would rate it a ten out of ten for stability. I never had issues with it.

Its scalability deserves a ten out of ten. I have never hit a limit with Azure Cosmos DB.

We have multiple locations and multiple departments. We are in different countries and regions. For our one project, we have multiple Azure Cosmos DBs. We have about seven developers, and we have tens of thousands of users or consumers. Our clients are enterprises and SMCs.

Early on, about a decade ago, when I started with Azure Cosmos DB, I just played with it and created many things. I ended up having a $10,000 bill. Because it was an accident, I had to send a support ticket. The support team was able to waive that cost for me. That left a very good impression on me up until today. I did not have to pay that money, especially when I was just starting. Now, there are very good partners out there, us included, who are well familiar with Azure Cosmos DB. That ecosystem is well supported now. It is not like you are going to a niche database and hoping for the best. That ecosystem is quite mature.

I would rate customer service and support a nine out of ten. The only reason why it is not a ten is because a lot more triaging is required when raising a support ticket. That is the problem I have.

Positive

Before using Azure Cosmos DB, we primarily used MongoDB and Postgres. I have a mixed experience with both of them. There are also Azure flavors of those. You have MongoDB Atlas on Azure and you have Postgres on Azure. That is why sometimes I am very conflicted about which one to use. Both MongoDB and Postgres have captured the audience around the open-source community and the non-Microsoft enterprise or developer ecosystem.

The deployment is a one-off. It is straightforward. For provisioning Azure Cosmos DB, everything is there. It has been straightforward so far.

Its deployment is done in minutes. In terms of maintenance, Azure Cosmos DB itself does not have any maintenance. However, the application that we are supporting and developing needs maintenance. That is it. Azure Cosmos DB does not require migrations like SQL Server where you have to manage a migration from version 17 to 19 and so on.

We achieved a strong return on investment. Using Azure Cosmos DB enabled us to bring a project to the MVP stage in six weeks. With one recent application that we had, if we had gone through another approach, the project could have taken six months in an enterprise setting where everything is slow and challenging. Getting an MVP of that project would have taken six to eight months, but because we had an active choice of using Azure Cosmos DB and other related cloud-native services of Azure, we were able to get to an MVP stage in a matter of weeks, which is six weeks. That was a very measurable impact that we had. If we went another route, just defining the tables, entities, and other things would have taken us a big amount of time. We had already identified base entities. We knew we could add more columns or remove some columns as we went along. That gave the agility to our project.

We do not have to look at it periodically. I do not get support calls that our application is down.

From a startup point of view, it appears to be expensive. If I were to create my startup, it would not have the pricing appeal compared to the competition, such as Supabase. All those other databases are well-advertised by communities. I know there is a free tier with Azure Cosmos DB. It is just not well advertised.

For mid-tier customers, its pricing is justifiable. The enterprise tier is where it is subjective. For organizations that have built a lot of capabilities around SQL Server, Oracle, or so forth, because of the lack of skills, understanding, and capabilities around Azure Cosmos DB, it would appear to be expensive. The professional services aspect of Azure Cosmos DB is what is driving the cost, not the platform itself. The skills required to manage the service can drive up costs more than the platform itself.

I would recommend Azure Cosmos DB for its scalability and performance. Do not be frightened to give it a try. Because there is no local way of doing things, Azure Cosmos DB will always be considered expensive. It is not very developer-friendly when you have to pay upfront, but there is a free tier. Microsoft needs to do better in terms of communicating that it is free to get started.

I would rate Azure Cosmos DB an eight out of ten because of the lack of local development and so on. It also gets confusing with so many APIs. There is a mixed messaging problem around that. The vector database and so on are also confusing. There is a vector database, but depending on which API you choose, there is a different implementation. It is just a bit confusing. I use this every day, so I know it by heart. I know where it is going, but it is just not very easy to get started for others. Messaging and product categorization are not clear. The way they are bundled or packaged is confusing.