Microsoft Azure Cosmos DB Reviews

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.

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.

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.

I'm the primary systems architect at DocuSign. We just launched a product at called Intelligent Agreement Management, and a central pillar of that is schema understanding. We use Microsoft Azure Cosmos DB as our schema store. It's the brains of our entire system. 

It is integral to our business because it helps manage schema and metadata for all our documents and customers. The AI insights we glean based on Azure OpenAI also end up in Cosmos DB. We need a NoSQL store because the schema is dynamic and flexible, so Cosmos DB is a great fit. It has four nines or possibly five nines availability, excellent geo-distribution, and auto-scaling. 

Cosmos DB has improved search result quality, throughput, and query latency. There are trade-offs to finding the sweet spot among all of these. Having a NoSQL solution that can do that in a 100 percent Azure shop is the best fit we could want. 

The features that stand out as most valuable are the autoscaling and hierarchical partition keys. We use account IDs at a higher level and entity IDs at a lower level. That gives us optimal query performance for our workloads.

AI has been a game-changer for new people without expertise, making it easier to use and optimize. You can ask GPT or Copilot for optimization strategies. If you have queries that are not performing well, you can feed the same queries, execution plan, and other things to the AI. The AI returns reasonable recommendations for what to do. 

Cosmos DB is effective at handling large queries. At DocuSign, we're processing over a billion signers and massive agreements and contracts. These things are being used for business-critical workloads, so performance, scale handling, and latency are crucial. Without these, we wouldn't have a product that anyone would want to use. 

I have worked with Cosmos DB at my company for the past 18 months, but I have used Cosmos at Microsoft for nearly a decade.

Cosmos DB provides impressive stability due to its high availability and ability to handle massive data volumes, which is essential for our business-critical workloads.

We have found Cosmos DB’s scalability to be exceptional, enabling horizontal and vertical sharding and supporting massive scale with efficient auto-scaling.

The team behind Cosmos DB has been highly responsive, providing excellent transparency and high-quality postmortem reviews during incidents, ensuring continuous support and improvement.

Positive

The initial setup was straightforward. Cosmos DB's integration went quickly due to the team's prior experience with Azure services, allowing us to prototype within a couple of months.

The challenge for us is always scale. We needed to move all the tables in lockstep that are involved in join queries. In some cases, we came up with a structured pipeline where stage one would go to SQL, and some of the query hints for the Cosmos DB thing would come from that first stage and so on. That was a migration challenge in normalizing the data, bringing it into Cosmos, and then, again, denormalizing some of the data. 

The critical mass of internal expertise, particularly from people previously working with Azure, enabled a smooth implementation with Cosmos DB.

Cosmos DB has always met our targets. However, we've always had our schema store on Cosmos DB, so it's not like we started with something expensive and brought our TCO down using Cosmos. Still, it's an excellent option for NoSQL or semi-structured data because our agreements start as a morass of raw data from PDF, OCR PDF, or paper OCR scans. 

After that, we match the structure with a known entity and for that known customer and run queries on Cosmos DB to bring out the rest of the structure and use AI to enhance it even further. In some cases, the customer will add custom fields to their entities. Cosmos gives us a low turnaround time from when the dynamic nature kicks into when the results return from that new schema information back to the same customer. It's a rich, complex scenario, but also a massive scale of data and customers.

The pricing model for Cosmos DB has aligned well with our budget expectations. We did not encounter pain points related to costs and found it cost-effective compared to high-end SQL solutions initially considered.

When I joined, the company was already invested in Azure, so there was never a bake-off between Cosmos DB and offerings from AWS. We implemented Cosmos initially because we have a massive transaction database on SQL. On things like the total cost of ownership, Cosmos DB shines. It seems to be the correct approach for our semi-structured data and our schema and entity store. A combination of Cosmos DB and SQL Azure was how we shaped our architecture on this journey, but we didn't evaluate Cosmos DB against non-Azure NoSQL databases.

I would rate Cosmos DB as an eight out of 10 for its overall capabilities, responsiveness, and alignment with our needs.

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.

In my place of work, we use Microsoft Azure Cosmos DB to store data for our services and mobile and web applications.

The problems we were trying to solve with Microsoft Azure Cosmos DB primarily involve storing data that is not relational, such as hierarchical documents and data. It helps to store data and scale up when we are pushing large amounts of data.

We need to scale data. With Microsoft Azure Cosmos DB, we are able to scale up when processing large amounts of data or scale down as needed. It's also lightweight.

There is ease of use, especially for managing lots of non-relational data, which is easier to use than relational data. Azure is our enterprise solution, so we utilize Microsoft Azure Cosmos DB as it offers resources to store and manage non-relational data. Given that we run an e-commerce site, we have a lot of non-relational data, especially for items and all related aspects. It's very helpful because alternative solutions using relational data would not fulfill our needs. It effectively stores hierarchical data and data without defined relationships, making it quite useful for our organization.

Using Microsoft Azure Cosmos DB is fairly easy, but most importantly, the availability of documentation and community makes it easy to research information. For instance, if there are certain queries I want to run, I could easily go online. There's also the Copilot feature that helps generate the query I need to retrieve the data I want. It's fairly easy to use, and there are many tools to assist in utilizing the resource.

The best features of Microsoft Azure Cosmos DB include the speed to query data; as long as you index properly, retrieving data is fast and lightweight. 

Additionally, the scalability to scale your RUs when pushing large amounts of data to Microsoft Azure Cosmos DB and managing the speed or latency for read and write is crucial, depending on how you set it up.

Areas of improvement for Microsoft Azure Cosmos DB include indexing. While it makes data retrieval easier, it also increases costs. If there's a better way to improve indexing at a lower cost, that would be really helpful, but that's the major point for now.

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

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

For scalability, I would rate Microsoft Azure Cosmos DB a ten out of ten. The technology department that utilizes Microsoft Azure Cosmos DB spans approximately 500-1000 users. We have multiple locations and departments using Microsoft Azure Cosmos DB.

It offers us scalability. It saves cost because the system scales up when we have an enormous amount of data going in to allow a large flow of data. Once we are back to low traffic, it scales down, saving costs.

I would rate the technical support for Microsoft Azure Cosmos DB a seven out of ten.

Neutral

I have not used other vendors; I have only worked with Microsoft. Therefore, I don't have a comparison to make.

It took a couple of hours.

The learning curve for onboarding with Microsoft Azure Cosmos DB is quite short; as long as you get the portal, it is fairly self-explanatory on how to navigate around it.

The maintenance required for Microsoft Azure Cosmos DB is minimal. Maintenance is needed when Microsoft rolls out an update or when ensuring that our code packages are using the correct version of the Cosmos NuGet packages. It just means we need to stay up to date with the documentation.

I cannot quantify how much time or resources Microsoft Azure Cosmos DB saves me because I do not primarily work with cost management. I mainly focus on research and setup, but I think it saves costs—perhaps a few hundred pounds if we don't scale up. Putting it into perspective, it saves costs between 10% to 20%.

It is cost-efficient as long as you understand the right setup to optimize usage. Knowing the data needs of the organization and adjusting the Microsoft Azure Cosmos DB usage accordingly helps save costs, but if you don't know, you could end up spending more than necessary.

We do not use the built-in vector database capability of Microsoft Azure Cosmos DB; the nature of my department requires us to use the regular storage capability.

I would recommend Microsoft Azure Cosmos DB to other users without hesitation. I would rate Microsoft Azure Cosmos DB an eight 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.