Microsoft Azure Cosmos DB Reviews

Our primary use case is a product to generate insights from several terabytes of data. The main problem was accuracy, as we couldn't get accurate insights because the data was hallucinating. After some trial and error, we found a solution with Azure Cosmos DB and MongoDB and got an acceptable cosine similarity score. We use Azure Cosmos DB collections and Azure functions to get the results we were looking for.

Cosmos DB improved our search result quality. Our response's accuracy rate is higher than 85 percent, which is amazing for such a large volume of data. We are searching several terabytes of data, and our harmonized data layer is pretty big. We get data from multiple global data providers. 

We use Databricks as well. The entire framework is built on Python. We have structured and unstructured data pipelines. There are multiple layers to our architecture, but Cosmos DB is the main one.

Our team has found the vCore index to be one of the most valuable features. We have tokenized and vectorized our entire database and stored this data in MongoDB collections with a vCore index, which works like magic for keyword selection. 

Additionally, the interface is user-friendly and seamlessly connects with other Azure offerings, making integration with other services easy. The learning curve was short. Our experts understand data well, but they had to build knowledge of the AI stack. It took a little bit of learning. However, it was easy to understand. In a couple of weeks, they could do everything.

The vector database is the core feature we use. Our data was not accurate, and we wanted to create a ChatGPT-type functionality where the user could ask a question in plain English like, "Show me the top 10 vegan companies in the US." But the vegan is not tagged as "vegan." It could be "plant-based," so you add that keyword. Then, it's not the end of it. Things are tagged as soya
milk," "oat milk," etc. 

There was no other way to solve our problem with hallucination and deal with a huge volume of structured and unstructured data. The only option is to vectorize. And we looked at several vector databases, but none came close. The vector database integrates seamlessly. When we use the cosine similarity search and retrieve the keywords. These keywords then eventually feed into our SQL query formation. After that, we use OpenAI to summarize everything. It seamlessly integrates with everything.

There aren't any specific areas that need improvement, but if there were a way to achieve the right cosine similarity score without extensive testing, that would be very beneficial.

I have been using Azure Cosmos DB for close to a year. 

Cosmos DB proves to be stable with its seamless integration, accuracy, and consistency, making it a reliable choice for our needs.

We have not extensively tested the scalability, but it appears straightforward with the Microsoft stack. Scalability has never been an issue for us.

Customer service and support have been great. We receive good cooperation not only from the Cosmos DB team but across the entire Azure stack.

Positive

Before adopting Azure Cosmos DB, we tried different vector databases, but none were working. It was suggested by a Microsoft colleague, and it has been fundamental to our architecture since.

The initial setup was seamless. During our proof of concepts (POCs), everything was within the Azure OpenAI stack. It worked for us and seamlessly integrated with the rest.

In the three months prior, our hosting run rate was approximately $550,000 per month, which has since decreased to $280,000 in October. Last year was more about building things. This year, we are trying to optimize things and getting the right support. 

The pricing aligns with our expectations, given our extensive use of the Azure stack. This year, we are focusing on optimization and cost reduction across the Azure stack.

We considered several vector databases. Being an enterprise customer with Microsoft, security and reliability were deciding factors. Open-source vector databases were also considered.

I rate Azure Cosmos DB as nine out of 10. The product is fit for purpose and performs well,

The use case for Microsoft Azure Cosmos DB is that some of the data we have is too large for the SQL database, but we want to be able to access it in a timely manner. I appreciate the ability to use the SQL language through a Linq type query. 

Microsoft Azure Cosmos DB helped improve our organization's search result quality significantly when we started using it about eight years ago. It greatly improved things at that time. We moved to Microsoft Azure Cosmos DB, we were in a round of product development for one particular product. Moving to Microsoft Azure Cosmos DB improved things substantially. We have been using it since then, so it could not improve anything further because we design and build our own Vector Analytics solutions.

Some of the best features of Microsoft Azure Cosmos DB are that it could scale, and we could still use SQL language through a Linq type query. 

The cost is a concern. Microsoft Azure Cosmos DB did not decrease our total cost of ownership. From the standpoint of the old way of doing DBA operations, it did, but our cloud cost increased significantly. 

Unpaid support is not very good at all.

I have dealt with Microsoft Azure Cosmos DB for eight years.

Microsoft Azure Cosmos DB is stable. We did not really have any problems with Microsoft Azure Cosmos DB for the whole eight years.

Regarding latency and availability with Microsoft Azure Cosmos DB, I did not really have a problem compared to other document databases. Compared to other Mongo-style databases, it is not any slower than the rest of them.

The scalability of Microsoft Azure Cosmos DB is fine; we did not scale to Salesforce levels. Our solution was not on that type of scale. 

The environment we are using Microsoft Azure Cosmos DB in involves thousands of devices and different customers across the country. Although we did not face any issues with Microsoft Azure Cosmos DB, our Cosmos operation wasn't complex; the only issues we faced were somewhere else within Azure.

Unranked, because we don't use it, except for the training materials.

Neutral

For the last year or so, we have been moving all of our data out of Microsoft Azure Cosmos DB into RavenDB, and we have plans for a couple of other types of databases too, so we will not be using Microsoft Azure Cosmos DB in the future. The cost is a concern, as we desire to be more agnostic and not just stuck in the Microsoft frame.

The initial setup was pretty simple for me. It took the development team a couple of months to get the UI squared away, but I had already been using SQL. They made it easy for people that were pretty good with SQL, so I did not have a problem with it.

There were six people in the development team that deployed Microsoft Azure Cosmos DB. Some of their job roles included the principal engineer, two UI developers, API developers, and DevOps development.

It's expensive. I would rate it a five out of ten for pricing.

We are still in the process of moving, so we are not completely sold on RavenDB. I have just used it more in the last couple of years than anything else, but things are changing fast. I have looked into Postgres, time series databases, and others, and I have looked into graph databases as well. I do not know if we are going to use one, but they are definitely impressive. We have to prepare for scale, but we do not have to have it to be successful, so I have looked at Apache Ignite, as well as adding open-source pub/sub on top of Postgres, and I have looked at Couch and Mongo, though we are not going to use those.

Microsoft Azure Cosmos DB is pretty easy to use compared to other document database types out there, but I prefer RavenDB more. RavenDB has better automated indexing that makes things really nice. With Microsoft Azure Cosmos DB and RavenDB, the main differences are that with RavenDB, I can move completely off and just use RavenDB while still having SQL type, relational capabilities, whereas with Microsoft Azure Cosmos DB and other document DBs, we are not really getting that. RavenDB is a great solution; it can also have costs that can get out of control, but it has built-in ETL and time series features for your vector analytics, and its automated indexing means it indexes as well as any SQL database without manual work, although you could do it manually if you wanted. Whatever combination of solutions I end up with is going to give me those opportunities as well as having the pub/sub capability, which I do not think Microsoft Azure Cosmos DB has. We never used it if it did.

I did not use Microsoft Azure Cosmos DB with Azure AI services. The core thing is that I did not want to use any Microsoft products. 

I would rate Microsoft Azure Cosmos DB a seven out of ten. It is better than MongoDB and Couch, but not as good as RavenDB.

My company developed an anti-money laundering compliance platform specifically for the gaming industry. This multitenant platform utilizes Microsoft Azure Cosmos DB as its core operational database.

We have a high-throughput, large-volume data ingestion process, with substantial data flowing into our environment. We needed to solve two problems: ultra-high volume, requiring speedy reads and writes of hundreds of gigabytes of data per day, and the ability to distribute our platform geographically. Azure Cosmos DB's geo-replication features and the ability to host and scale our database across multiple regions, keeping data close to our customers, were primary deciding factors.

Azure Cosmos DB is quick to adopt with a shallow learning curve. The average user can be operational within hours or days, handling small to medium data volumes. However, optimizing for ultra-high throughput scenarios involves a steeper learning curve, requiring substantial knowledge to master Azure Cosmos DB. Nonetheless, most users can leverage it as their operational data store with minimal effort.

Our platform boasts several extensive language model features, particularly around summarization capabilities. We use vector searching in Azure Cosmos DB to facilitate the retrieval of an augmented generation model with our LLM implementation. It's a standard RAG implementation using Azure Cosmos DB. Compared to other options, a key advantage of vector indexing in Azure Cosmos DB is the ability to query documents alongside vectors. This pinpoints the precise information required for RAG in our LLM solution, granting us greater flexibility than vector searching in other Azure services.

We integrated the vector database with the Azure OpenAI service for our LLM solution.

The Azure AI services were simple to integrate with the vector database. There was a slight learning curve, especially as we were on the private preview of vector searching. This led to some hiccups with our existing database configurations, specifically regarding continuous backup. We couldn't enable continuous backup and vector searching simultaneously. However, this was solely due to our participation in the preview, and I'm confident this issue won't persist in the general availability release.

Azure Cosmos DB is fantastic for searching large amounts of data when the data is within a single partition. Over the last two weekends, we ingested over 400 gigabytes of data into our Azure Cosmos DB database and saw no change in querying performance compared to when our database was only 20 gigabytes in size. This is impressive and powerful, but the scope is limited to those partition queries.

The first benefit we've seen is increased developer productivity. Azure Cosmos DB is an easy database to work with. Its schema-less nature allows us to iterate quickly on our platform, develop new features, and store the associated data in Azure. Developers find it easy to use, eliminating the need for object-relational mapping tools and other overhead. Geographic replication and the ability to scale geographically is another advantage. This is challenging with other databases, even other NoSQL databases, but Azure Cosmos DB makes it easy. Cost optimization is a major benefit as well. We've been able to run our platform at a fraction of the infrastructure cost our customers incur when integrating with us. This allows us to focus resources on feature development and platform building rather than infrastructure maintenance.

Azure Cosmos DB helped reduce the total cost of ownership. We don't need DBAs, system administrators, or typical IT staff to run the infrastructure because we can use Azure Cosmos DB as a platform or a software-as-a-service data storage solution. This makes the total cost of ownership significantly lower than any comparable solution using relational databases or other NoSQL solutions like MongoDB.

We enable auto-scaling on all of our Azure Cosmos DB resources, which helps us achieve cost optimizations.

The querying language and the SDKs they've provided over the years have been phenomenal, giving us a significant advantage. Being a NoSQL database with a schema-less design allows us to optimize costs and reduce the infrastructure we need to manage. While we don't utilize every feature, auto-scaling has been invaluable for optimizing both cost and performance on our platform daily.

Azure Cosmos DB could be better for business intelligence and analytical queries. While it excels at high-throughput data ingestion and point reads with low latency, querying within partitions is smooth. Complex cross-partition querying, and BI/analytical tasks often necessitate moving data to other solutions like Fabric and Azure AI Search.

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

Over the four years we have been building, Azure Cosmos DB has not caused us one second of downtime.

The latency and availability of the Azure Cosmos DB is excellent. We have single millisecond latency point reads, which is the majority of the queries that we run on our platform. So, it's an ultra-high performance, ultra-high throughput platform for managing data.

We are confident in Azure Cosmos DB's ability to scale and meet our needs even with massive data volumes. We ingest hundreds of gigabytes of data into Azure Cosmos DB daily, reinforcing our confidence in its scaling capabilities.

Our experience with technical support has always been great. We've been lucky enough to connect with the product team resources at Microsoft around Azure Cosmos DB, and we've received fantastic support from the Azure Cosmos DB team.

Positive

I've used MongoDB extensively, both self-hosted and through their SaaS solution, Mongo Atlas. I've also worked with relational databases like PostgreSQL, SQL Server, and MySQL. Additionally, I've experimented with non-document data stores like Cassandra, but not in a production environment. All the other databases have been used in deployed production applications.

Azure Cosmos DB offers a minimal total cost of ownership. No database administration or dedicated teams are needed to manage it, which increases developer productivity compared to relational database solutions. Azure Cosmos DB also provides higher levels of data consistency without the traditional data migration problems of relational databases, and its schema-less nature makes versioning easier. However, there is a steep learning curve for building large-scale applications and optimizing throughput with Azure Cosmos DB. Additionally, its analytical capabilities are not as strong as other solutions.

The deployment was straightforward to initiate. While numerous configuration items are needed for production workloads, particularly key management, getting started remains simple and accessible.

We deployed our infrastructure as code, initially using Azure CLI scripts to deploy AzureCosmos DB alongside other infrastructure components. We have since transitioned to Terraform for this purpose. From an implementation strategy perspective, we are a multi-tenant platform using logical tenancy, meaning a single Azure Cosmos DB database accommodates multiple tenants. We have a relatively large number of collections, approximately 40, within our Azure Cosmos DB database. To optimize cost, we share throughput where feasible and provide dedicated throughput for containers with high read or write volumes.

One person is enough for the deployment.

For the first three years of our company, we were able to run a production environment while spending less than $10,000 a month on our database. In contrast, our customers pay tens of thousands of dollars for the systems we integrate. Therefore, Azure Cosmos DB is a highly cost-optimized solution when used correctly.

I rate Microsoft Azure Cosmos DB ten out of ten.

We use Azure Cosmos DB extensively for searching alongside Azure AI Search, which offers full-text Lucene syntax-compatible querying. While a significant portion of our searches leverage these dedicated search indexes, we still conduct a fair amount directly in Azure Cosmos DB. Although it might not be entirely fair to say that searching isn't Azure Cosmos DB's strong suit, it's worth noting that its capabilities are constrained by partitioning requirements. This limitation places a ceiling on its overall effectiveness for specific scenarios. While Azure Cosmos DB can be extremely valuable for querying within partitions, alternative solutions are often better suited for queries spanning multiple partitions.

I've built tools around the Azure Cosmos DB SDKs to make them incredibly easy to use. My team had no learning curve and could leverage our shared libraries. It took me less than a week to achieve a production-quality implementation for accessing and saving data within a platform.

We have 20 people in the organization who interact with Azure Cosmos DB, consisting of 15 engineers and five others.

Azure Cosmos DB typically requires minimal maintenance, but if data partitioning is not done correctly, some overhead may be incurred due to the need to replicate containers and move data. Thus, while generally low maintenance, some maintenance can be required in certain situations.

For anyone thinking about implementing Azure Cosmos DB, first, understand your data and invest time in understanding the partitioning in Azure Cosmos DB. If you get your head wrapped around the partitioning, everything else will be straightforward.

I have three different products using Azure Cosmos DB. The most extensive use is in a survey platform we are developing as a SaaS product. Azure Cosmos DB serves as the primary OLTP database for this platform. We do not have any other RDBMS for this use case.

We also use it to store configuration information for campaigns for the other two products, but it is used extensively for the survey platform.

Azure Cosmos DB offers horizontal scalability, making it easy and cost-effective without additional effort from a DBA or DevOps team. Configuration for scaling is user-friendly through the UI.

It is easy to use and optimize once you understand the basics, partitions, and indexing. By default, it indexes every field and attribute, but you can customize it. The documentation is good. It makes logical sense. I have had some experience with other NoSQL solutions. It is easy to use. We do not find anything challenging. The way it indexes and does the filtering of data is easy.

The fact that scalability can be achieved by simply configuring availability zones is very attractive. We aimed to avoid managing a NoSQL database, especially when we did not have an upper limit on how much audio we would need while doing the initial development. The ability to easily scale with the increase in usage and adoption of our product is the most valued feature.

A limitation in Azure Cosmos DB is the 2 MB document size. Developers need more systemic support in chaining multiple documents if more than 2 MB is required. Compared to competitors like MongoDB, which allows for gigabyte-sized documents, Azure Cosmos DB's limit is small. An improvement could include increasing the document size or providing a method to manage larger sets efficiently. If they want to keep a 2 MB limit, they should provide a way to chain multiple documents in a systematic way so that developers do not have to figure out what to do when a document is larger than 2 MB. For some use cases, the 2 MB size is very small. If they improve this aspect, a lot of customers will benefit from it. 

Another area for improvement is making it available on different cloud providers. Currently, Azure Cosmos DB is an Azure-only offering. Not supporting other cloud providers results in Microsoft losing some customers.

I have been using Azure Cosmos DB extensively for the last four years. Before that, it was more of hobby research.

We have an account manager. We reach out to that account manager wherever we need level 2 or level 3 support. We have also followed the normal process of raising a ticket, but sometimes, it helps to speed up the process.

Ordinary issues are resolved through standard processes, but for complex matters, we leverage our account manager to access senior engineers. We have received great support. Support has been responsive and effective. I am very happy with their support.

Positive

We have not replaced any solution with Azure Cosmos DB for this use case, but we have used MongoDB, Elastic, and other NoSQL databases.

Almost anything that you can do in Azure Cosmos DB can also be done in MongoDB, but one of the things that I like about Azure Cosmos DB is called change detection. Changes in each document can be persisted in some other technologies. It could be in fabric or SQL Server. This feature gives Azure Cosmos DB an edge over others in use cases where you need to detect a change and then connect it with other things. I also like the functions and stored procedures that Microsoft has implemented in Azure Cosmos DB, but the change detection feature is probably one of the best features. It works natively within the platform and Azure.

The initial setup is very easy and seamless. An instance can be deployed in minutes, and the UI allows for easy configuration and scaling without disrupting operations.

I recently needed to upgrade an Azure Cosmos DB instance. In the UI, I clicked the option to scale it higher. It said that it could take a couple of hours. I thought it would take four or five hours, but it finished in two or three hours and notified me when the upgrade was completed. All this while, things were working and operational, and behind the scenes, it was upgrading to a bigger instance. It finished the upgrade in half the time. It can spin up a small instance in just a few minutes.

It took us about two weeks to do the PoC to make sure that Azure Cosmos DB was the right one for our use case. After the PoC, we started leveraging Azure Cosmos DB within a month. Our use cases have become more and more sophisticated because we are still developing software, which requires us to create different documents and different structures of those documents in Azure Cosmos DB. The onboarding itself was simple and natural. We did not feel that using Azure Cosmos DB slowed us. In fact, it was seamless because the JSON that our APIs needed could directly be persisted in Azure Cosmos DB. No other transformation was needed.

Its learning curve is small. It is easy to learn. The documentation of Azure Cosmos DB is good.

It does not require any maintenance, but a couple of times, we had to change our partition scheme and write a separate utility to transition from one partition scheme to the other. It was more of a migration that we had to do of the Azure Cosmos DB document that we had created. Because we changed the partitioning scheme, we had to migrate the old data to the new partition design. Azure Cosmos DB does not require any maintenance work. That is the beauty of how NoSQL, and Azure Cosmos DB in particular, have been designed.

All implementations were done in-house without any external consultants. It is a one-person job.

The horizontal scalability helps lower the overall cost of ownership as compared to managing MongoDB or any RDBMS solution. Because of its ease of use and the fact that the scaling, configuration, and backup are managed in Azure, we do not need a dedicated DBA. We do not even need the DevOps people to manage it.

The management of Azure Cosmos DB is easy because of the UI and the way it scales. We have availability zones and multi-region load balancing. When you take all that into consideration, the total cost of ownership is much lower than others.

Azure Cosmos DB is costly, especially if you have not optimized it. However, we are very satisfied with it. It provides the value for what we are paying.

Its price is very good for the basic stuff. When you go to a more complicated use case, especially when you need replication and availability zones, it gets a little costly.

It represents the biggest cost item for us. However, the cost is aligned with the value provided. It has served our needs perfectly, aligning with our scaling and development requirements, so the cost of ownership seems justified.

We did a number of PoCs to decide which NoSQL database to use, and we settled on Azure Cosmos DB. We could see its benefits when we incorporated the partition key with indexing. The performance started improving when our engineers started exploring some of the complex concepts.

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

The primary use case is focused on advanced analytics. We use Microsoft Azure Cosmos DB for storing results from OpenAI models, acting as a temporary information repository for APIs, and for log systems. We also experiment with its Vector Search capability.

Microsoft Azure Cosmos DB has helped to improve efficiency, providing good response times and allowing the storage of AI process results, which is crucial for feedback loops. 

The tool makes it easier for us to store data in a database. Our company is a Microsoft shop using Azure, and our big data ecosystems are oriented to solve needs in the Azure architecture. We are looking at maintaining the tools within the same ecosystem without breaking the whole scenario of the solutions we have to set up. Cosmos DB helps us do those types of operations. 

The performance is so good it creates an ecosystem that allows data scientists to develop applications without clashing too much or losing the security and governance over the information.

Microsoft Azure Cosmos DB offers the response times needed for advanced analytics applications. It supports multiple use cases, including storage of AI model results and temporary information repositories. 

Performance and security are valuable features, particularly when using Cosmos DB for MongoDB emulation and NoSQL. The platform's ability to efficiently tokenize AI models for later consumption is also a benefit.

Within the layer, we're using it with OpenAI. That is the main one. If we use document intelligence from the entire database layer,  it is where we have our developments deployed on Kubernetes pods that connect and leave data.

The integration with other solutions needs to improve because Cosmos DB's interoperability is lacking in some scenarios. For example, I'm currently implementing Fabric. That involves migrating from environments without apps, processing data and users, and taking them to Fabric. 

When I have the pile of information that I need a data scientist to look at, I tell them to use Fabric as the development center. They can't connect to Cosmo DB, but I have data there. The documentation could be clearer, especially concerning infrastructure aspects.

We have used Microsoft Azure Cosmos DB for about two years.

We haven't experienced significant stability issues with Cosmos DB. Occasionally, latency occurs between applications, but it has not caused major problems.

While the scalability of Microsoft Azure Cosmos DB is theoretically simple and efficient, there is a degree of uncertainty. Dynamic scalability doesn't instill full confidence and can lead to increased costs if not managed correctly.

The initial setup requires a steep learning curve due to the differences between the query language in MongoDB and NoSQL, making it a demanding task for developers.

It requires an educational process that can't be achieved quickly. It took us about four to six months. It's an adaptive process that's not difficult, but it is time-consuming. 

The training for using Microsoft Azure Cosmos DB has been ongoing for four to six months, indicating a lengthy adaptation process for the development team.

Cosmos DB is expensive, and the RU-based pricing model is confusing. Although they have a serverless layer, there are deficiencies in what I can define and assign to a database. Estimating infrastructure needs is not straightforward, making it challenging to manage costs.

I rate Microsoft Azure Cosmos DB seven out of 10. 

In our project, I used Microsoft Azure Cosmos DB primarily for storing new or updated JSON documents.

With SQL Server, we have to use a lot of joins when a lot of tables are present in different databases. When we join tables present in different databases, we first load a table in memory and then apply join on them. With Microsoft Azure Cosmos DB, we do not have to do that. It solves the problem of joining different tables.

We did not have to convert JSON files to a relational database format. We did not have to separate the JSON file into a data model. We could directly use those files. We did not need any primary-foreign key relationships or any relationships between tables. We just needed a partition key. Based on that, we could simply save data into Microsoft Azure Cosmos DB.

Its performance is good. Integrations are very quick. In my project, Microsoft Azure Cosmos DB was at the center of the business. Everything was running around Microsoft Azure Cosmos DB. Performance-wise, it solved all the latency problems that they were facing before.

Microsoft Azure Cosmos DB is very fast. Data retrieval and data storage are very quick. It is known for its speed and efficiency, with quick data retrieval and storage operations without latency. You can do a lot of operations in real time.

One area for improvement is the ease of writing SQL queries and stored procedures in Microsoft Azure Cosmos DB. Writing an SQL query and a stored procedure on top of that is a little challenging. It is not so easy with Microsoft Azure Cosmos DB. It requires some understanding. It is a relatively new product, so the knowledge gap is there. There should either be better documentation or an easier way to implement. We should be able to write a stored procedure in a simple language like SQL.

Additionally, there should be support for maintaining large files. It does not support files that are more than 2 MB in size.

Other than that, I do not have any input. It is a good product. It solves all the problems I have seen.

I have been using Microsoft Azure Cosmos DB for three years. I last used it about six months ago.

I have not encountered any stability issues with Microsoft Azure Cosmos DB. Its stability is commendable. I would rate it a ten out of ten in terms of availability and latency.

There was a challenge concerning scaling related to RU limits, but Microsoft has introduced dynamic RUs to tackle this issue. I am not sure about its recent effectiveness, but earlier, I manually increased RU capacity to address concurrent access.

It is capable of quickly searching through large amounts of data, but our project was not very extensive. We did not have a lot of records. However, it can support a large amount of data. From this aspect, it is a brilliant product.

We had about 40 people on our team using Microsoft Azure Cosmos DB.

I rarely needed to reach out to Microsoft for technical support regarding Microsoft Azure Cosmos DB. After it was up and running, we did not require much support.

Neutral

Other than Microsoft Azure Cosmos DB, I have used SQL databases. I have not used any NoSQL database.

It was a PaaS solution. I was not involved in its initial setup, but it is simple and quick, taking about five to ten minutes. If you want concurrency, some documentation is available, but it would be helpful to have some hands-on examples.

We used the ARM templates available in the Azure portal for deployment. We had CI/CD pipelines, and we deployed them using ARM templates. That is the strategy we use for the deployment of Microsoft Azure Cosmos DB.

It does not require any maintenance from our side.

It takes about three months to train someone on it. They only need to learn how to query the database.

It took me around one and a half years to understand the real benefits of Microsoft Azure Cosmos DB. It is a nice product.

In terms of performance, Microsoft Azure Cosmos DB benefited us greatly by solving latency and data retrieval issues, but I cannot comment on cost savings as the financial aspects were managed by others.

The pricing is perceived as being on the higher side. However, if you have large data operations, it might reduce costs due to performance efficiencies.

I did not evaluate other NoSQL databases; the client chose Microsoft Azure Cosmos DB based on its performance.

I would recommend Microsoft Azure Cosmos DB if you are looking for performance. I am not sure about the pricing, but if you have a large number of users, Microsoft Azure Cosmos DB is helpful.

If you are using proper indexes, data retrieval is fast and search is easy. Otherwise, it will take a lot of RUs to get the results.

If you are migrating from traditional or legacy workflows to Microsoft Azure Cosmos DB, it would require a lot of rework. For new implementations, Microsoft Azure Cosmos DB is advisable.

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

We have been using Cosmos DB for everything involving non-relational data. Recently, we’ve been utilizing it more for AI purposes, especially for conversation histories.

Cosmos DB performs well with production workloads that have many gigabytes of information. You can scale it to add more capacity while providing the level of performance that customers expect.

We value the replication and regional availability features that Cosmos DB provides. The replication includes read replicas and write replicas. The recent addition of vectorization and similarity comparisons add values for AI workloads. The performance and scaling capabilities of Cosmos DB are excellent, allowing it to handle large workloads compared to other services such as Azure AI Search.

The solution is straightforward in terms of the interface, API set, and automation capabilities. The learning curve is short if you're familiar with the world of non-relational data. It takes about three to six months to learn about the distribution capabilities of Cosmos as a service. It takes a bit more time to learn the networking settings that you can use for Cosmos in South Asia, including virtual networks, private networks, finance, etc.

The vector database is interesting. We haven't used it before. We were using Azure AI search for that, but we've had great conversations with the product team, and we realize that a couple of workloads are more appropriate for Cosmos. The search results quality is still determined by Azure AI search, and we haven't used vector databases in production workloads. However, from what we've seen from a hands-on demo, it can help.

A minor improvement would be enabling batch operations through the UI. Currently, to delete all documents in a collection, we must use an API, which some of my team finds inconvenient for admin tasks.

We have been using Cosmos DB for six years.

Cosmos DB performs exceptionally well and has not caused any issues that necessitate adjustments in nodes for improved performance.

The solution scales exceptionally well. Partitioning, indexation for collections, and the dynamic scaling feature allow us to manage performance and costs effectively. We like that it can auto-scale to demand, ensuring we only pay for what we use.

Before Cosmos DB, we used Python for non-relational data. However, choosing Cosmos was straightforward due to our focus on leveraging Microsoft services.

For our migration, we had to integrate both products. The source had its own interface and APIs. In terms of syncing data, we had to incorporate it directly with Cosmos. Cosmos has excellent APIs and operation services. It was easy to orchestrate migration from one data center system to the other.

The challenges were more related to network performance than anything else. We had to build our migration very close to the Microsoft network. We were working with higher network latency by doing it inside a VM on Azure.

Our team built a migration orchestration integrating both the source and Cosmos systems using APIs.

Since starting with Cosmos DB, we have seen an overall reduction in our total ownership cost of 5 to 10 percent.

Everything could always be cheaper. I like that Cosmos DB allows us to auto-scale instead of pre-provisioning a certain capacity. It automatically scales to the demand, so we only pay for what we consume.

I rate Cosmos DB nine out of 10.

Our primary use case for Cosmos is the storage of shell-fed signs and our pricing systems. We use it as a transactional database on the back end.

The ability to scale automatically is very valuable. Additionally, multi-region support automatically synchronizing to a different region for multi-region applications is a cool feature. It's more of a lift with other databases to configure that extra region and set up replication, even if it's on the cloud. With Azure, it's just a button click. It's that simple. 

The learning curve depends on your background. It takes time to learn if you're from a relational database background like us. However, it's fairly straightforward from a scalability perspective once you get the hang of it. You need to be aware of certain concepts like partitions and partition keys. Once you get those, I think it's fairly okay.

The auto-scaling feature adjusts hourly. We have many processes that write stuff in batches, so we must ensure that the load is spread evenly throughout the hour. It would be much easier if it were done by the minute. I'm looking forward to the vector database search that they are adding. It's a pretty cool new feature. 

I have used Cosmos for about five years.

The latency and availability are good. I don't have any complaints there. It goes back to how you're retrieving data and whether it's structured correctly. 

Cosmos can definitely scale well, but it comes with a cost. One of our databases is quite large and scaled up significantly due to our needs.

We have two databases, so it was challenging to define the partition key and ensure the workloads are spread out. We have millions of records in our Cosmos database, so spreading that out was difficult. We had to spread out the load to avoid a 429 error for a request that was too large. Partition key is more of a learning experience to understand the right thing to do. The entire process took around six months. It wasn't too hard.

We have reduced our overhead through dynamic scaling. I can't say precisely how much we've reduced our total cost of ownership using Cosmos DB, but we have a similar on-prem workload running on SQL, and we only pay a fraction for Cosmos.

Cosmos is cheaper than other solutions, but you must be smart about how you use it to keep costs down. We've made mistakes where the cost has increased more than we expected. You have the opportunity for it to be cheap or costly.

We were looking for a multi-region document database, and the ease of configuring multi-region in Cosmos was a significant factor in our choosing the solution. We also wanted to bring costs down, which was the other reason.

I would rate Cosmos an eight out of ten. Be cautious about spreading out the load evenly, especially when dealing with large volumes to prevent getting errors.