Microsoft Azure Cosmos DB Reviews

We use Microsoft Azure Cosmos DB emulator to display database contents and occasionally perform manual data edits when necessary. We utilize it for general database emulation tasks.

It has been very efficient so far. The team has been using it for quite a while. I am new to the team, but they always talk about how efficient it is. We are using the NoSQL version. It is easy to use for development. It is reliable and quick. 

It has been pretty efficient when it comes to search. I have no complaints about that. It is easy to use and very compatible with Java.

I had a challenging experience implementing the emulator with a Mac. I had to install the emulator in a Docker container because it is not natively compatible. A significant amount of time was spent researching how to enable HTTPS communication when connecting the container and the emulator. I encountered TLS and SSL errors but resolved most of them by setting an environment variable in the container and using HTTPS protocol communication. I also had to use gateway mode with the Cosmos client in my Java app. I am disappointed with the lack of compatibility of the Microsoft Azure Cosmos DB emulator with Mac. I also found a scarcity of online resources regarding this issue.

It would be great to include compatibility with various databases like graph databases, adding to the existing NoSQL and MongoDB compatibility. I have used that for various projects on other platforms, and such additions would be beneficial.

I have been using it for about a week now.

I do not see any stability issues. I would rate it a ten out of ten for stability.

It is scalable. I would rate it a ten out of ten for scalability. We have had no issues with its ability to search through large amounts of data.

We have thousands of users. We are a big organization, and it is being used at various locations.

I love the community forums. They provide a wealth of useful information, which gives me an advantage when it comes to support. The only disappointment was not being able to find any information about setting it up on a Mac.

Neutral

I have used the cloud-based Firestore database and MongoDB before. They largely perform similar tasks, and I have no problems using either one. They work and get the job done.

For me, the setup was not complex because my team had everything ready.

I watched a couple of videos on YouTube. The onboarding was seamless, especially the database part. It took me no more than two days to learn the basics and necessary setup.

In terms of maintenance, it does not complain if you do not update it, but there are always updates that you can add. For example, for the emulator that I am using, there are a lot of versions I can install, but it works with most of them.

I have no complaints. It does its job efficiently and is easy to set up. Our organization has been using it for quite some time. They must see a value in it. Otherwise, they would go for a better technology in terms of performance or pricing.

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

My main use cases in my company for Microsoft Azure Cosmos DB are to store data for semi-structured and unstructured data and to retrieve data for data agents.

The feature I have found most valuable in Microsoft Azure Cosmos DB is its scalability and speed.

Microsoft Azure Cosmos DB can scale quite fast and easily, and you can store a lot of data, so I believe that is the biggest advantage of it.

I evaluate the enterprise-grade security features of Microsoft Azure Cosmos DB in terms of data encryption and access control as a positive implementation because data security is important today, so it is very beneficial.

These features have helped improve my company's data security strategy because every client, as I work in a consultancy, wants their data to be secured, and nobody wants it to get leaked. The features already implemented into Microsoft Azure Cosmos DB help to make our job easier.

I think it could be better if it included more in regards to AI or if it were more exposed to AI. I find it straightforward as you store whatever you want and then train the models and fine-tune the models.

I have been using Microsoft Azure Cosmos DB for around six months, as they introduced it relatively recently.

In my experience, the global distribution and multi-region replication of Microsoft Azure Cosmos DB have not significantly influenced the performance and availability of my applications because we work primarily in West Europe. I did not experience much multi-regional functionality as we are based in one region and work in one region.

Microsoft Azure Cosmos DB can scale quite fast and easily, and you can store a lot of data, so I believe that is the biggest advantage of it.

I have utilized Microsoft Azure Cosmos DB's multi-model support for handling diverse data types to some extent, but not extensively.

I would assess Microsoft Azure Cosmos DB's automatic and elastic scaling of throughput and storage for my current projects as quite good, as it is fast, easily scalable, you can store a lot of data, and you cannot see significant latency.

I have minimal interaction with customer service and technical support because we have salespeople and more tech-related sales representatives who handle all the talking and requirements gathering. I am more of a tech-savvy technical specialist who implements everything.

Neutral

Before choosing Microsoft Azure Cosmos DB, the company I work for did not use another solution. I have had some exposure to AWS, but now I am in the Microsoft stack.

For me and my colleague, the deployment process for Microsoft Azure Cosmos DB is quite easy and not complicated.

The biggest return on investment for me when using Microsoft Azure Cosmos DB is that you can store everything—not only structured data or unstructured data, but everything. You can also integrate it with AI, which I believe is the best investment.

I do not believe my company is considering other products instead of Microsoft Azure Cosmos DB because we are currently very happy with the product and what Microsoft is doing by integrating Microsoft Azure Cosmos DB and AI Foundry. We also received news that it is a DocumentDB as well, so we will stay within the Microsoft tech stack.

I would say the main difference between AWS and Microsoft is that I prefer Microsoft since, in my opinion, it is more user-intuitive and everything is on one platform. If you want to do Fabric, everything is in one place, and if you want to do Azure, everything is still in one ecosystem, so you do not need many third-party applications to do your job.

From what I have used, I believe the tool is quite good.

Microsoft Azure Cosmos DB is currently quite good, and I do not have any enhancements I would recommend since I am not a heavy user, having used it for about six months.

My advice to other companies considering Microsoft Azure Cosmos DB is to simply try it, and you will love it. I would rate this product a 9.5 out of 10.

I have been using Microsoft Azure Cosmos DB for the last five years for IoT-based data saving and other purposes. We use non-structural data for various reasons. For instance, we are using artificial intelligence to save multiple data sets coming from different sources.

It is a managed service, so we do not want to worry about other aspects.

One valuable feature of Microsoft Azure Cosmos DB is partitioning. Its performance is very nice. I use it mostly on the Microsoft backend, particularly .NET and .NET Core technology. From deployment and accessibility aspects, there is significant performance improvement.

Additionally, consistency is noteworthy. For example, we have people spread across multiple locations. If they update data in Australia, we can access it in another location within a fraction of a second. That is an impressive feature of Microsoft Azure Cosmos DB.

It is very good from the optimization and usage point of view. It is very user-friendly. Microsoft also provides support from the performance aspect. They support us from the optimization and scalability aspects.

The query searching functionality has some complexities and could be more user-friendly. Improvements in this area would be very helpful.

We have multiple applications. Our applications are running in different environments such as AWS and Azure. We are able to give flexibility to AWS to access this data from Microsoft Azure Cosmos DB. We have created an interface between them through APIs. Through the APIs, the AWS applications can consume the data from Microsoft Azure Cosmos DB, but we have seen some slowness or latency, whereas with Azure, we see better performance. Our AWS is in the Eastern zone, and people in the Western zone have some latency.

I have used the solution for five years.

We are seeing some latency issues with AWS. It offers good availability. 

Being serverless, the scalability is very good.

We pay for the support. We are happy with their support. If we face any challenges initially, they provide us with a resource to answer all our questions.

Positive

Previously, we used MongoDB and DynamoDB, though not extensively. Because of client preferences and their use of Azure, we chose Microsoft Azure Cosmos DB. DynamoDB uses clusters, which affect costs.

The initial setup can be somewhat tedious. We have to set up things, run them, see the results, and fine-tune them.

The initial setup took more than one month. After that, everything became automated. Now, if we want to deploy it in another location, the operational team typically takes one week. They verify whether everything is working properly or not. By using the automated scripts, we can deploy it at other locations.

We have a separate team for configuration. We also get support from Microsoft.

Its price is in the middle, neither too low nor too high.

We are happy with the usage of Microsoft Azure Cosmos DB for our use case. In terms of learning, it is of medium complexity. It is neither very tough nor very easy.

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

I find SQL API suitable. I used it in my last project. Previously, I worked for a client called EPS, which has a product called BOS (brokerage operation support system). There I have used the SQL API.

I have used it in a product called BOS, and we achieved many things with Microsoft Azure Cosmos DB, which helped improve our products efficiently.

It helps in many ways in my current projects such as brokerage operation, which shifts multiple data in different regions. It helps significantly in storing and retrieving data from different countries for shipping details, shipping ID, and all data records in different countries.

Microsoft Azure Cosmos DB is a fully managed globally distributed NoSQL database. It is highly available with low latency and scalability. It supports multiple data models and APIs, making it flexible for different applications. Its features include multi-model support, global distribution, automatic scaling, and support for multiple APIs such as SQL API, MongoDB API, Gremlin, and Cassandra.

We can use Microsoft Azure Cosmos DB for storing and managing all types of data manipulations including inserting, fetching, and updating records. These operations can be performed efficiently.

The storage in Microsoft Azure Cosmos DB is globally distributed and highly efficient. Storing and retrieving data is much faster and more efficient.

It is cloud-friendly and easy to use. We can easily insert data and retrieve information from this cloud platform. The UI is better, faster, and efficient.

It supports various types of APIs and is a fully managed, globally distributed database that helps in different regions. Microsoft Azure Cosmos DB is a distributed and multi-model NoSQL database that supports SQL, MongoDB, and other platforms. Its scaling is managed using the request per unit, and it has auto-scaling based on business requirements.

The features include support for multiple NoSQL data models such as documents in JSON format, key-value store, graph database, wide column store, and MongoDB compatibility. In the document model, we can use the SQL API, while in the key-value store, we can use the table API. The Graph database is used for Gremlin.

It has a large capacity of up to 12 GB per physical partition per container. I have used up to three to four GB.

Its latency is high and impressive. The support is very high, with read-write latency at 10 ms per second.

It handles large-scale operations efficiently, such as tracking views, logs, or events. It has high write throughput and handles partition issues and storage growth effectively.

There are some disadvantages as it is costly compared to other NoSQL databases. It has a complex pricing model and has a strict partitioning strategy. There are limited SQL query capabilities in Microsoft Azure Cosmos DB.

It is more expensive than other server cloud service providers with its request units pricing model.

I have one year of working experience with Microsoft Azure Cosmos DB in my current organization.

The solution scales very well.

I'm not sure about technical support. I haven't worked with them. 

Before Microsoft Azure Cosmos DB, I used SSMS and MySQL server management. For cloud solutions, I have only used Microsoft Azure Cosmos DB.

Initially, we logged into the Azure portal and create a new Microsoft Azure Cosmos DB account. Then we chose an API such as SQL API or MongoDB. We set up account details, subscription, region, and enable geographical replication and multi-write regions. After that, we created a database and specify the name and provisional throughput. Then we created a container inside, providing the container ID, partition key, and index policy.

It took around 15 to 20 days for full-fledged training.

Initially, it took approximately three months to get comfortable for learning purposes. I encountered some difficulties while learning, however, through the project, I learned many things.

It's fully cloud-based, so there is no maintenance.

We have six developers for deployment and related tasks in Microsoft Azure Cosmos DB.

AWS is another choice available. I find Microsoft Azure Cosmos DB better suited for my needs.

Microsoft Azure Cosmos DB and AWS DynamoDB are basically the same, however, Microsoft Azure Cosmos DB supports multi-region support and can replicate and auto-replicate the data. It is highly manageable, which is why I chose Microsoft Azure Cosmos DB.

I definitely recommend Microsoft Azure Cosmos DB. It handles large amounts of data, is highly reliable, and operates in a very fast and efficient way. Users can deploy their applications in the cloud, and it supports various APIs. On a scale of one to ten, I rate Microsoft Azure Cosmos DB a nine out of ten.

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.

The most valuable feature of Microsoft Azure Cosmos DB is its ability to handle concurrency and consistency. In scenarios with heavy usage where multiple users or services are accessing Microsoft Azure Cosmos DB or updating and creating new documents, its ability to manage such interactions in a performant way is outstanding.

For me, it is easy because I have a lot of experience with it, but it is easy for most people to get started with Microsoft Azure Cosmos DB. The more challenging aspect is modeling your data for the best performance. That is one of those things where there is a little bit of a learning curve to do it correctly, but there is a lot of good information out there on how to do that.

One thing that we do as a best practice is lock down Microsoft Azure Cosmos DB to where you have to use an identity to connect to it. For instance, I have a service running in Azure Container Apps, which is using my Azure account or identity. You cannot connect with the connection stream. You cannot connect with an access key. In that scenario, two things can be improved. The first one is the ability to assign role-based access control through the Azure portal for accounts to have contributor rights. Currently, you can only do that by executing a script using the Azure CLI. Being able to do that in the user interface would be more convenient.

The other thing is that when you are in that type of configuration and you want to use the data explorer through the Azure portal, you have to separately click the button to authenticate with your Entra ID. That times out after an hour or so, and then in order to reauthenticate, you have to leave the data explorer and come back so that any queries or anything you have up and running go away. That is another area of improvement.

I have been using it since before it was Cosmos DB. Back then it was called DocumentDB, so I started using DocumentDB in 2016.

Microsoft Azure Cosmos DB is highly stable and built for stability and scalability. Outages are rare and usually due to regional issues rather than the service itself. I have not experienced Microsoft Azure Cosmos DB as the only service being down in a region.

The ability to scale workloads is one of its strongest points. About three years ago, they added the auto-scale feature which helped a lot. Before then, if we were going to do a big batch processing workload against Cosmos DB, we would manually scale it up. Manually scaling up usually takes seconds. It is immediate, depending on how high you are scaling it up. If you are scaling it up by a certain high factor, it can take a little bit longer, but, generally, it is fast. Now, auto-scale throughput is what we use in all of our deployments. In cases where it has to automatically scale up to your maximum, that happens very quickly.

I contacted their technical support once a few years ago to restore a Cosmos DB backup point. The response was quick. It was all done electronically. I did not talk to anyone on the phone, and it was a quick resolution. Their support was good for that one case.

Positive

I have used RavenDB, which is probably the closest to Microsoft Azure Cosmos DB. I have also used MongoDB through Atlas, which is very similar to the MongoDB API available on Microsoft Azure Cosmos DB.

The initial setup is easy. You can quickly deploy it through the Azure portal. You do not need a whole lot of configuration to get started. If you want to programmatically deploy it, that is also a simple process. You can do it through ARM or Bicep templates or even through Azure CLI. It is quite simple.

In terms of the learning curve, back when it was DocumentDB, it did not take very long to get onboarded. It is a matter of getting used to the conceptual differences. If you are a traditional database administrator, you would not have to do your typical tasks that you would do with SQL database as an example. That is a little bit of a mind shift. If you are a developer and you are used to working with relational databases, that is also a very big mind shift, but it is not any different than using any competing NoSQL database.

We teach a lot of people how to use Microsoft Azure Cosmos DB. People generally get it quickly. A lot of the learning curve comes in the details. It is quick for people to get up and running and do something with Microsoft Azure Cosmos DB. There are a lot of quick-start examples and resources out there. The longer learning curve is how to properly optimize and take advantage of the features that I already talked about. You can get up and running and start using Microsoft Azure Cosmos DB in a day, but to fully understand how to properly optimize it and configure it requires a couple of weeks of experimentation and learning. Then you get very proficient at it.

Its maintenance is being taken care of by Microsoft. That is one of the benefits.

The pricing for Microsoft Azure Cosmos DB is good. Initially, it seemed like an expensive way to manage a NoSQL data store, but so many improvements that have been made to the platform have made it cost-effective. With so many improvements to the platform and ways to optimize, in our big enterprise deployments, Microsoft Azure Cosmos DB tends to be one of the least expensive services even though it gets a lot of use. The pricing has improved a lot over the years.

My biggest advice is to learn how to correctly model your data. Learn how to select the appropriate partition key. Learn how to use the change speed if you need to use more than one partition key. These are all performance-based things that have a higher learning curve. These are the most important things to get down so that you are not overspending and so that you do not have to scale it up higher than you otherwise would have to because things are not set up properly.

Microsoft Azure Cosmos DB can decrease the total cost of ownership if you are taking advantage of certain things such as being able to do some downstream processing of data using the change feed, which simplifies how you can process incoming data versus having multiple services set up. That is one example. Another example could be doing analytical queries against Microsoft Azure Cosmos DB. You can use something like Synapse Link so that the data gets stored in parquet files in the storage account automatically for you, and you can query over those using something like Spark. That saves you time and money because you are not hitting your operational store. You are not consuming RUs, so you are not worried about data movement, and you are removing having to set up a separate data pipeline to do that. That is a potentially big saving, and then you are not consuming your transactional resource units on your Microsoft Azure Cosmos DB containers doing those analytical queries. That is another way to save a lot of money. If done properly and using the available features, Microsoft Azure Cosmos DB can decrease the total cost of ownership.

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

It has not been a direct approach for me because all of my enterprise-level applications are deployed in MongoDB. At some point, we usually face issues where we need multi-directional and different contexts to connect with the database. Sometimes we use SQL and need to retrieve data from the database. If using a typical MongoDB, this is not possible. Microsoft Azure Cosmos DB has bidirectional support for cross-platform connections, so we don't need to recreate our entire database structure in our application. We can work with the MongoDB driver and interact with Microsoft Azure Cosmos DB. The applications under my portfolio currently rely on that, mostly indirectly. We created the models, deployed our data, migrated it, and are using it heavily in Microsoft Azure Cosmos DB. 

Recently, we are building an AI-powered application where we heavily rely on Microsoft Azure Cosmos DB to bring data from ServiceNow, SAP, Salesforce, Cisco, and other customers we have at our organization. Reading and inserting data into Microsoft Azure Cosmos DB is a very smooth process.

Its scalability is great. Microsoft Azure Cosmos DB offers auto-scaling both horizontally and vertically. We haven't faced any issues.

For the third-party driver support they are currently providing, they need to ensure it stays up to date with the market throughout development. If MongoDB updates a particular feature in their drivers, we as developers expect that service and support to be available in Microsoft Azure Cosmos DB as quickly as possible in production.

Its scalability is good and depends on the traffic, with auto-scaling functionality ensuring we don't need to worry about database crashes or data loss during insertion. These problems were common when deploying our data on-premises. With Microsoft Azure Cosmos DB, we have overcome those struggles and are now operating smoothly.

It depends on the application. In some cases, we use Microsoft Azure Cosmos DB directly with Azure Functions to store customer details and manage the customer onboarding process through our enterprise applications. In several instances, operations happen directly with Microsoft Azure Cosmos DB.

For legacy applications built on MongoDB that need to transition to Microsoft Azure Cosmos DB, we take a different approach. If a company is migrating from on-premises systems to the cloud—whether it’s Microsoft Azure or AWS—sometimes it’s necessary to adopt different tools for the billing process and other infrastructural needs. In such cases, we may choose to use Microsoft Azure Cosmos DB to avoid having to restructure our entire legacy application. In these situations, we utilize MongoDB and its drivers as a mediator. These drivers interact with Microsoft Azure Cosmos DB to perform the necessary operations within the application.

On another note, when using Azure Functions, we typically handle cases such as creating, updating, or retrieving customer details. This process directly connects Azure Functions to Microsoft Azure Cosmos DB. Currently, we are managing these two different patterns effectively.

If you are an engineer with good experience in microservices and the Azure platform services, it's a one-day setup process, based on requirements. If you are new to the entire Azure platform and services, it can be a bottleneck. It takes time to understand the configurations and related aspects. If you're new, there is a learning curve. You need to understand which version you're using, what features are supported fully or partially, and which features are not supported. For example, when using MongoDB drivers to interact with Microsoft Azure Cosmos DB, understanding which version (4.1, 4.2, or 4.3) you're using and what features are supported by Microsoft Azure Cosmos DB for that particular version is important. Understanding query performance improvements based on supported features is crucial. For newcomers, it might take several days to understand and review documentation. For mid-level engineers with two or three years of experience, it's a straightforward, one-day process.

Pricing is a complex process at the enterprise level. While I'm not handling the pricing directly, through stakeholder meetings and conversations, we understood that having everything in a single platform with billing up and running for all required application services is beneficial. Microsoft Azure Cosmos DB comes into a single billing system for gold or silver partners, though I'm not familiar with specific company policies and terms and conditions as I'm not an infrastructure specialist.

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

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 appreciate Microsoft Azure Cosmos DB's robust document management and consistent availability. The databases are always operational, ensuring continuous accessibility and simplifying disaster recovery procedures. The geo-redundancy feature is particularly valuable, especially for European operations.

Cosmos DB needs improvement in a few areas, primarily the ability to join data across containers. Currently, it doesn't support cross-container joins, forcing developers to retrieve data from each container separately and combine it using methods like LINQ queries. This workaround is inefficient and cumbersome. A built-in join functionality would be a significant improvement. Additionally, Cosmos DB's SQL queries are susceptible to injection attacks due to limited parameter support. Currently, only one parameter can be used, compelling developers to use string interpolation, which introduces security risks. The ability to pass multiple parameters would enhance both security and code quality.

Sometimes, clients may lack technical expertise and run queries without utilizing partition keys, leading to significantly increased request units and higher costs. While Microsoft Azure Cosmos DB currently leads the market, enhancements are needed, particularly regarding data statistics across different containers. Dealing with clients who have multiple containers often requires custom code to stitch data together, highlighting the need for functionality supporting joins across containers. Additionally, a more stable and predictable pricing plan would benefit both developers and clients.

I have been using Microsoft Azure Cosmos DB for more than four years now.

Microsoft Azure Cosmos DB offers exceptional stability, boasting a reliability rating of 99.95 percent. This ensures continuous availability without downtime.

I rate the scalability of Cosmos DB highly, with a score of nine point five out of ten.

Microsoft's support services are inadequate, especially during critical incidents. The faster response times found in community-driven resources, such as Stack Overflow, underscore the shortcomings of Microsoft's customer support.

Negative

While Amazon DynamoDB offers extensive configurability, this can be time-consuming. For projects with tight deadlines requiring a NoSQL database, Cosmos DB is a preferable choice due to its ease of setup and minimal configuration. Additionally, Cosmos DB provides superior support for the Jira application and offers better uptime than DynamoDB.

The provided templates help us deploy Cosmos DB quickly.

Cosmos DB's billing is based on request units, which isn't ideal for all clients. Pricing plans offering set benefits, similar to Azure's platform resources, could be beneficial. The current method lacks clarity for clients new to cloud-native architectures, hindering migration from on-premises systems.

Billing is based on request units, so it's crucial to optimize queries to minimize consumption. A standard estimate is one to one point five request units for read requests and four to five for insert, update, or delete operations.

I would rate Cosmos DB's cost at seven out of ten, with ten being the highest.

Cosmos DB can provide improved search result quality, but we must understand the partition key of our container. Using the correct partition key in our queries ensures precise results. Without it, queries may consume excessive Request Units of over 5,000 and ultimately fail.

Microsoft Azure Cosmos DB is a strong product with the potential for improvement in supporting joins from different containers and providing more stable pricing plans. Despite these areas for growth, Cosmos effectively competes with services like AWS DynamoDB and currently leads the market. Overall, I rate the solution an eight out of ten.

Our Cosmos DB deployment spans across Europe, with the primary data center located in Italy to serve our European users. Additionally, we have another customer based in the eastern US, where their data is replicated across three data centers in the eastern US and three more in the western US for redundancy and high availability. We currently have 40 projects using Cosmos DB for clients in different industries ranging from oil and natural gas to sports and media.

We use Azure WebJobs to maintain our databases by removing expired policies and contracts. However, Microsoft should implement a similar system in Cosmos DB, utilizing its Hot and Cold Tier functionality for archival storage. This would allow us to efficiently move outdated data to archival storage, mirroring the functionality we have with Azure WebJobs.

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.