Microsoft Azure Cosmos DB Reviews

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 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.

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.

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.

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 many use cases. We are using Microsoft Azure Cosmos DB for our event streaming framework. We are using Microsoft Azure Cosmos DB to store all the event data for AI activities.

We are also using it for a RAG-based solution, though it is not entirely RAG-based. We are using Microsoft Azure Cosmos DB as a staging solution, and then we are using the AI search to index it and continue to the RAG for the LLM.

We are just using it as a staging solution. We have use cases for extracting huge documents, which can be more than 500 pages or even 10,000 pages. We cannot directly use the LLM, so we have to use a RAG-based approach. For that, we have chosen Microsoft Azure Cosmos DB and we are using the vectors there. However, instead of directly querying the vectors in Microsoft Azure Cosmos DB, we are indexing that in AI search.

The searching capability is exceptional. It is very simple and incomparable to competitors. With SQL, we have to install everything, but this is pretty quick. We have a Bicep template. Using the Bicep template to create Microsoft Azure Cosmos DB containers and partition keys makes everything convenient. Scaling is also convenient.

The RUs still appear to be a black box for everyone. Even though they explain read and write RUs, it remains unclear for many users. With Microsoft Azure Cosmos DB, we are using event streaming in the entire organization. We are using a framework for event streaming, and we suddenly reached a huge amount - the capacity of 20 GB partition key. When it reaches 100% of RUs, we face issues. We have to work on rebuilding the partition key. 

Regarding billing, we need better control. Sometimes it exceeds the forecasted budget. More clarity on RUs would be beneficial, even though documentation exists.

There is a 2 MB limitation for a document, which is a hard limit. Additionally, modeling in Microsoft Azure Cosmos DB is more challenging compared to RDBMS and other NoSQL solutions because we cannot store everything in one place. Since it's NoSQL, we sometimes need to split one document into multiple containers due to the 2 MB limitation.

I have been using it for more than two years.

Its stability is good. I would rate it an eight out of ten for stability.

Scalability is pretty good. I would rate it an eight out of ten for scalability.

I would give a low rating to Microsoft support, as whenever I talked to them, I never got a solution. I had to guide them.

If the support ticket lands in certain regions such as Sweden, they have more knowledge and the ticket gets resolved easily. At times, it moves between departments, requiring escalation to get the correct person involved.

The support team needs improvement in understanding who they are talking to. They should not ask basic questions when speaking with experienced users. I am deeply knowledgeable about Microsoft Azure Cosmos DB, which I have had to explain to the support team.

Neutral

It is very simple. We can't compare it with any competitor. We just use the Bicep template.

Its implementation takes a maximum of one hour.

Because of the lack of understanding about RUs, the costs become unpredictable. It sometimes goes over the budget.

Currently, they are implementing Fabric and OneLake solutions. Fabric appears faster. According to Microsoft representatives, querying in Fabric instead of Microsoft Azure Cosmos DB will be quicker. However, I remain confident in the querying capability of Microsoft Azure Cosmos DB.

It is pretty good, and currently, everyone wants to move from Microsoft Azure Cosmos DB to Databricks, but when I query data in Databricks, it takes considerable time with huge amounts of data. It stores in the BLOB in the backend, but when we use Microsoft Azure Cosmos DB, it retrieves the data much faster. The main consideration is being careful with fixing the partition key.

I would strongly recommend it for new projects. When you create a project from scratch, it is easy to implement Microsoft Azure Cosmos DB because the library is very pretty good. You can just use the library and create a container. I do not see any complexity at all in using Microsoft Azure Cosmos DB. 

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

For retail, all the backend data, such as merchandise items, is stored in Microsoft Azure Cosmos DB. This data is processed by backend APIs, and the UI can perform displays, printouts, edits, creations, etc.

Cost-wise, it is transparent. It supports traceability. Any activity happening in your Microsoft Azure Cosmos DB can be seen from the Azure portal via log events. If you have some sort of observability, you can centralize logging and create historical insights or virtualization based on the activity. By default, Microsoft Azure Cosmos DB provides all of that on their main portal.

It is responsive when you have a large dataset stored in your Microsoft Azure Cosmos DB. It is no problem. You can quickly scale it. Unlike traditional solutions, you do not have to deal with a separate team managing the database.

Search results have been good. It is a good experience because you can search results via the Azure portal, via a query, or via CLI. You have plenty of options. Aside from that, you can do quick scaling of your Microsoft Azure Cosmos DB whenever you have an issue with the workload, capacity, etc.

Traditional database solutions require back-and-forth coordination between teams which can lead to delays in implementing simple tasks. With Microsoft Azure Cosmos DB running on the cloud, the developer can do a quick query, and the operator can do technical analysis or troubleshooting. It is beneficial overall in terms of operational effectiveness.

Optimization is achieved through indexes. It is pretty similar to other SQL or database solutions. Microsoft Azure provides Data Studio, where you can explore your schema, tweak it, create a backup, and restore existing data within Microsoft Azure Cosmos DB. These tools make your life easier if you do not like working with the CLI.

Microsoft Azure Cosmos DB is a good solution for distributed application requirements. We can perform multi-modeling. For modern applications, I would recommend Microsoft Azure Cosmos DB. It caters to different types of applications and also provides an API base wherein you can perform automated updates for your Microsoft Azure Cosmos DB resources.

It provides all the common features that other database solutions offer. The difference is that Microsoft Azure Cosmos DB is cloud-hosted. You can host it on-prem, but running in the cloud simplifies everything in terms of support and availability.

Overall, it works very well and fits the purpose regardless of the target application. However, by default, there is a threshold to accommodate bulk or large requests. You have to monitor the Request Units. If you need more data for a particular query, you need to increase the Request Units.

I have only used the technology for three to four months.

It depends on how you configure your Microsoft Azure Cosmos DB. If you are using it as a standalone service, you are unlikely to gain the full benefits of having Microsoft Azure Cosmos DB running on the cloud. However, if you consider scale sets and scalability, for example, you can achieve higher stability.

With Microsoft Azure Cosmos DB, we created an availability zone to ensure that there is a replica of the primary Microsoft Azure Cosmos DB instance. If the primary goes down, there is a secondary database that they can use for the application. The backend application gets repointed to the secondary instance.

I do not see any problem with the latency. Connecting from your local client like Azure Data Studio to your Microsoft Azure Cosmos DB can take time, but if you are going to connect an application to the database in the same region, there is no latency at all.

It is highly scalable. I would rate it a nine out of ten for scalability.

We can quickly scale using Terraform. We can perform horizontal and vertical scaling with Terraform and apply it. It will automatically reflect in our Azure environment.

Excellent support always comes from Microsoft. If you have a problem with different services, you just raise a ticket, and someone will reach out to you. I can elevate the severity depending on the criticality of your issues and the impact.

Positive

We did not use any other solution previously because this is a new project for modernizing the merchandising area.

The setup is easy, especially in the cloud, so I would rate it a nine out of ten for the ease.

All our infrastructure layers are being controlled by Terraform. If we want to set up a new environment, it can be done within a day for not only Microsoft Azure Cosmos DB but also all resources required for an end-to-end application flow.

You can do it yourself. They have good documentation, which is easy to follow.

You can get an ROI in a year, provided you deploy it properly with the right baseline forecasted plan in terms of resource sizing. There are many factors when it comes to ROI, such as how quickly you can onboard your application and consume the backend Microsoft Azure Cosmos DB. For those new to the cloud, it might be hard to get the ROI quickly, but those with existing resources in the cloud can achieve their ROI in the short term.

It can save a lot if you perform regular monitoring. If you have a monitoring team for checking the overall utilization of Microsoft Azure Cosmos DB resources, it will save a lot of cost. You can react quickly and trim down the specs, memory, RAM, storage size, etc. It can save about 20% of the costs.

Its cost is transparent. Pricing depends on the transaction and data size, but overall, it is cheaper compared to hosting it on your corporate network due to other factors like power consumption. 

Current pricing is fine, and you can scale it afterward. You can start with a small size and scale eventually. That is a benefit of having Microsoft Azure Cosmos DB on the cloud.

It was the primary platform choice of the client at the time.

You can quickly learn Microsoft Azure Cosmos DB if you are familiar with how databases work.

Microsoft Azure Cosmos DB offers all you need for a particular database solution. It is better if you can host it in the cloud, applying security controls like data at rest and data in transit. You must ensure Microsoft Azure cloud is only accessible in a secure manner.

Scalability-wise, you can quickly scale your Microsoft Azure Cosmos DB, unlike on-premises, where you must request and procure additional resources. There is no such need; you can use infrastructure as code like Terraform and adjust the resource specs whenever you like. There are no capacity and workload concerns.

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

We use Cosmos DB as a database for the cache mechanism. We have a product integrating e-commerce platforms with backend ERPs, pulling merchandising data. We maintain millions of products in the ERP and store them in Cosmos DB in document format. When a query comes from the e-commerce platform, it goes directly to Cosmos.  

Cosmos is preferred because of its speed, robustness, and utilization. We have all the merchandising information in Cosmos DB, which provides concrete and optimized data when searching for new products on the site. It is faster than other relational databases.

It can query large amounts of data efficiently, depending on how you write the queries. This is a Document Database, and the system needs to read the whole document. If that is correctly clustered, then it will be faster, but if the developer makes some mistakes, it won't be optimized. 

The most valuable feature is the data writing process, where we write data into batch segments. The built-in vector database is helpful. There's one vector for the product and another for the price. I don't have much experience with vectors because we use Cosmos as a cache DB. You won't see any major challenges when you use it as a more significant enterprise application. I would rate the vector database's interoperability with other solutions an eight out of 10. 

The main area of improvement is the cost, as the expense is high. Also, when writing processes into Cosmos, sometimes the threshold is met, which can be a problem if developers have not written the code properly, limiting calls to five thousand. These aspects need addressing.

I have been using Cosmos DB for three years.

I would rate the interoperability of the vector database with other solutions as eight out of ten. It's good, but the performance depends on how well queries are written.

We compared MongoDB and Cosmos DB. Cosmos DB is easier to configure, and our team is already familiar with managing it, providing an advantage.

The initial setup was straightforward, with no major challenges. We onboarded the team in no more than three days. 

The cost of using Cosmos DB is high, which sometimes raises concerns from clients regarding the increased solution cost. While it has helped decrease the overall cost of ownership, the specific figures are not readily available.

I would rate Azure Cosmos DB eight out of 10. The solution is variously challenging but manageable once the team is familiar.