Microsoft Azure Cosmos DB Reviews

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

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

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

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

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

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

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

I have used the solution for five years.

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

Being serverless, the scalability is very good.

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

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

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

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

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

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

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

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

I develop applications. I developed an application where I had to search the Azure Cosmos DB database for values related to suspicious entities. It involved retrieving, sorting, and manually searching data through queries.

Azure Cosmos DB helped improve the quality of our search results. We could see its benefits immediately after the deployment.

The availability and latency of Azure Cosmos DB are excellent. It handles large data insertions efficiently without any problems related to scalability. It scales workloads very well.

The library of Azure Cosmos DB is like JPA, but it is not exactly JPA. We could not integrate that.

The size of the continuation token in Azure Cosmos DB should be static rather than increasing with more data, as it can lead to application crashes. They should use a static key size.

If we want to update some data, we cannot use the SQL command line. It is not like SQL Server or any other relational database. We have to send the JSON file or send the text to the Azure portal.  These are the only two options. We cannot use the normal SQL statement.

I have been using it since December 2021.

The scalability is very good. We performed performance tests, inserting objects with more than 10,000 records without any issues, although, on the application side, we started to see high memory consumption. That is because, with larger JSON files, you will have more objects in the Java application. These things consume memory, but there are no issues regarding scalability.

I have not contacted their support.

Neutral

I have experience with MongoDB but only for personal studies. I only learned the basic things.

It was easy because we have Terraform embedded in the Jenkins pipeline. Once I deploy the application, it connects with Azure Cosmos DB. It is already configured, so I do not have to worry about this part.

It took us about one month to get onboarded and understand the basic functionalities. 

It does not require any maintenance at our end.

We usually have a team of three to four people.

I am not aware of the price, but a challenge that I have faced occasionally is that running longer queries requires more RUs, so I have to ask someone with permissions to execute the queries.

I would advise learning more about queries and select statements. You can use that on the Java side and Cosmos SDK.

It is easier to learn if you already know relational databases. You can use some of that knowledge to work with Azure Cosmos DB. Also, if you know JPA, it would not be so difficult to work with the Cosmos SDK for Java application development. Inserting data is also simple.

It is at a medium level in terms of ease of use. There is documentation for gathering the information. Azure Cosmos DB does not have any constraints for the column names. If you want to create a specific query, you can find information related to that in Microsoft documentation. You can find queries to solve specific problems.

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

We use it as a data storage platform for several proprietary applications that we have designed and built and now support. We generally use it to be able to scale so that our customers can search a sizable amount of data. We have millions of records that include an extensive amount of text.

We implemented Azure Cosmos DB for our tokenization process. We had originally built a data dictionary to be able to tokenize different words within our MongoDB collection, but over a period of three years or so, we found that there were some limitations to doing that. The data dictionary needed to be updated, so we turned to the vector search feature because it essentially allows us to measure the similarity between words. Those sorts of comparisons could be done very easily. There is the ability to tokenize words, which we then use in the search functionality provided for the users of our applications. It has helped us improve the search functionality of our applications.

I landed on it as an architectural component of one of our first solutions. I went in expecting its benefits. It delivered the benefits of being able to quickly scale and being able to support semi-structured, unstructured, and structured data sets or data properties. All of these aspects are supported. We were able to realize its benefits early on.

We have used the vector database with Azure AI services. It works fine. They are embedded vectors. We are running some text through Azure AI. It then returns these embedded vectors, and we store those. We are able to use those vector values or vectors to determine the similarity between various words that are being searched in our applications.

The Azure Cosmos DB's ability to search through large amounts of data is excellent. It is fantastic. We have benefited from it. It is great.

There are a number of different APIs or data storage supported in Azure Cosmos DB. Specifically, we are using the MongoDB API, so we leverage it in that way. I like the flexibility that it offers. My team does not have to spend time building out database tables. We can get going fairly quickly with being able to read and write data into a MongoDB collection that is hosted inside Azure Cosmos DB.

I found it very easy to use. We have been using it for five years, so it is quite flexible for us. The ease of use is quite high for us.

It is easy to use, but optimization has been a mixed experience. It has been more of trying to figure out how to do so. We have not found much support there, so we have to come up with our own way of optimizing it in different ways. That is one area of improvement. We would like to have more tools that support the optimization of Azure Cosmos DB. There are not many tools out there. We have had to develop our own tools internally, such as a clean plan or query plan, and look at the index usage, throughput, and those sorts of things. The portal experience for optimizing and monitoring the service needs a few enhancements.

I am looking at it through the lens of MongoDB API. There are four or five other APIs that are supported in Azure Cosmos DB. The MongoDB API experience could be improved substantially by having a more user-friendly set of administrative tools so that I can go out there and query the documents that are part of the collection. Currently, I am working around that by using third-party tools like 3T. I also use MongoDB's Compass client tool. They can make this part of managing the database or the collection a lot easier by providing some built-in toolsets, similar to what is offered by Azure with Azure Data Studio. That is a big area for improvement. 

We should also be able to better manage the cost. There have been some improvements there, but there is still room for improvement in terms of how costs are managed through the Azure portal relative to Azure Cosmos DB. To me, it is one of the more expensive services out there depending on how it is being leveraged.

One of the key limitations is that only so many vectors can be supported. It does not work very well with the large amount of text that has to be embedded in the vectors. That is one limitation we have run into with the feature set.

It has been five years. 

The SLA is pretty good. We have been able to at least get past 99.9%. We are probably closer to 99.99%. So, overall, it has done well over the five years. Just like with most things, there were a few instances where it crashed or was not available. Those instances are memorable, but they are few and very far apart.

Its latency is good. The availability is also good.

Its scalability is good. However, redundancy does not work very well. Redundancy is having a set of backups. It is also a part of high availability. We have used some of the redundancy features in Azure Cosmos DB, and it created problems for us consistently. We recently had to move away from having a redundant copy of the data and just having a single copy. Of course, we have adequate backups.

Through the lens of MongoDB API, the scalability can be better. However, the limitations are core to the actual platform. MongoDB is not designed to scale horizontally, so that is how Azure offers it. It scales vertically which means that I can go and request more compute and more memory RUs for the instance that I am using. If I was supporting multiple workloads that had different read/ write patterns, it would work, but it is not designed to do that well at its core, as I understand it. It is less of a function of Azure Cosmos DB and more of a function of MongoDB itself.

The dynamic scaling has helped decrease our organization’s overhead costs. We are able to scale up during business hours, or when there is demand, we scale automatically. There are some tools that we have built and some processes that do that. We can also scale down during non-business hours or when the demand drops for the database or the data store. It has helped to manage scaling costs.

I contacted their support this year when we had some issues. When it comes to customer service, it always comes down to the person you get on the phone or who picks up your ticket. 

Regarding Azure Cosmos DB, we felt frustrated when we needed that support from Microsoft. It has not been there because the things that we are dealing with are generally more complex than most customers would have to deal with. At times, the representatives or engineers we got or who picked up the tickets we submitted did not have the breadth of experience needed to support us or resolve the issues. So, we resolve the issues ourselves the best we can.

Negative

We use some of the alternatives because it does not solve everything. There is no such thing as one perfect data store. We use Azure SQL instances. We use SQL and VM in Azure. We have started doing a lot more Postgres, which is the flavor of the time. Everybody seems to be moving to Postgres all of a sudden.

Synapse is another tool. It is another Azure service that we use. It just depends on what type of data we are using and what makes sense in terms of the implementation of the application. Those are some of the alternatives that we have used.

Its deployment is easy. Setting up the service is easy. You make a decision around where you want to deploy and those sorts of things. There is a lot of pointing and clicking. That was very easy.

Taking it to production was a lot harder. It was a lift to get the data loaded into Azure Cosmos DB. At the time, there were about 750,000 resumes that we uploaded for a customer, so it took a lot of time. We had to build a custom app to load those documents on data records into Azure Cosmos DB. We had two people working on it for two weeks. We probably spent somewhere around 60 hours around the lift to get that all loaded up and going in Azure Cosmos DB.

It took us about 18 months to feel fully confident in working with this and reach a level where we can go and teach others. We feel that we have got a firm grasp of the service after about 18 months of production support.

Its maintenance has been taken care of by Microsoft. However, at the end of last year going into this year, there were a few disruptions with the service that hampered our customers or users. There have been times when the service went down, or the service was upgraded but the SDK or NuGet packages used to support or connect to Azure Cosmos DB were not in sync. Overall, Microsoft takes care of the maintenance.

It was all done in-house. We had two people involved in it, myself and my lead developer. It was mainly about loading data into Azure Cosmos DB. That was a big lift.

Azure Cosmos DB helped decrease our organization’s total cost of ownership. It is hard to provide the numbers, but managing the data store is easier for us with Azure Cosmos DB with the MongoDB API because there is no need for a DBA. We do not have a DBA on the team who is just taking care of the indexes and making sure that the database is healthy. It pretty much just runs. If we had a DBA in the team specifically for MongoDB, we would be paying about 150,000 dollars a year. We have to somewhere in the neighborhood of 50,000 dollars for the service in Azure. In terms of the total cost of ownership, it saves us about 100,000 dollars.

Pricing, at times, is not super clear because they use the request unit (RU) model. To manage not just Azure Cosmos DB but what you are receiving for the dollars paid is not easy. It is very abstract. They could do a better job of connecting Azure Cosmos DB with the value or some variation of that. 

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

I am using it to store our data. We are using Azure Cosmos DB to store our JSON-based documents.

The high speed of Azure Cosmos DB compared to other competitors is remarkable. It is one of the most powerful features, offering high availability and high speed. Its benefits can be seen immediately after the deployment.

Overall, it is a good resource. I am not aware of the background, but it seems to currently support only JSON documents. They could expand their scope to support other types of data, such as XML or EDI formats. EDI is an old technology, but it is still in high use in supply chain and retail industries.

I have more than two years of experience with Azure Cosmos DB, whereas with Azure, it has been more than four years.

Choosing the correct partition key is crucial, as it affects our database speed and related operations.

Latency and availability depend on the consistency level.

It is a Platform as a Service, so we are concerned about the underlying interface. We can move to a higher tier as all Azure cloud resources are open to easy scaling.

It offers an option alongside the Azure SQL database. Azure SQL database has its own capabilities, whereas Azure Cosmos DB supports all major big data requirements like Cassandra and Gremlin. Azure SQL database is more focused on transactional data instead of analytic data. Azure Cosmos DB covers a wider area.

I have not personally deployed Azure Cosmos DB, but DevOps pipelines provide options for this. It should be easily deployable with the help of Microsoft's documentation.

It takes a couple of minutes to be up and running. It also depends on how we are deploying, whether it is via an ARM template, Azure pipeline, or directly via Azure release.

Azure Cosmos DB is generally a costly resource compared to other Azure resources. It comes with a high cost. We have reserved one thousand RUs. Free usage is also limited.

It is not like a traditional database. Choosing the partition key needs an understanding because it will affect the database speed. By making your partitions in a logical and efficient way, you can improve the speed of search analysis.

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

In my role, I use Microsoft Azure Cosmos DB fairly extensively across various platforms. At ASOS, we utilize it for order processing to record incoming orders and for commercial integration platforms. Overall, we have numerous use cases.

Overall, Microsoft Azure Cosmos DB is easy to use.

Microsoft Azure Cosmos DB has provided benefits compared to SQL databases, particularly in terms of availability.

Microsoft Azure Cosmos DB has helped to improve our total cost of ownership.

Microsoft Azure Cosmos DB offers a relatively easy learning curve due to its limited programming service area compared to SQL Server. This streamlined functionality allows users to quickly grasp the SQL query language.

The autoscale feature is the most useful for us.

There should be parity between the various APIs. I often work with the Mongo API, and features for it sometimes lag substantially behind the core API, such as the Analytical Store feature. Additionally, I am waiting for the full fidelity change feed that would surface all changes, including deletes to documents.

While Microsoft Azure Cosmos DB is generally easy to use, it has some limitations. Certain areas are more restrictive, and we are awaiting features that will simplify development. For example, currently under development, the full fidelity change feed will expose all document changes, enabling tasks like synchronizing collections while accounting for deletions. This is challenging because the existing change feed doesn't provide information about deleted documents.

I have been using Microsoft Azure Cosmos DB for around seven years.

Cosmos DB demonstrates good stability and great reliability, with technical issues arising approximately once per year.

While Cosmos DB offers good latency and availability, careful consideration must be given to selecting appropriate consistency levels.

The scalability is excellent, and as long as the data can be partitioned, the scalability is nearly infinite.

Cosmos DB's ability to scale workloads is a significant advantage, as evidenced by our successful management of multiple terabytes of data without encountering any issues.

The quality of customer service and support varies. We always get an answer eventually, but the speed of resolution depends on the reason for the support ticket. If there is a bug in the product, we have to wait for it to be fixed.

Positive

The initial setup of Microsoft Azure Cosmos DB is straightforward. Even someone with no experience can easily deploy the solution.

The deployment can be completed by one person on the same day.

The deployment can be done entirely in-house. Whether we are doing it manually in the portal or deploying it through Terraform, it is straightforward. We do not require help from an integrator or consultant, although there are considerations about partitioning collections when creating resources.

The pricing for Cosmos DB has improved, particularly with the new pricing for Autoscale. Previously, we were charged according to the busiest partition across all regions, but now, each partition is only charged for what it uses. This change has substantially reduced our costs.

When evaluating new projects, we determine whether data storage is best suited for a relational database, such as Azure SQL Database, or a non-relational database like Cosmos DB.

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

Understanding some of the subtleties of Microsoft Azure Cosmos DB can take time, and some individuals at ASOS still find concepts like partitioning unclear. However, getting started with Cosmos DB and developing functional applications is quick and can be achieved in a short timeframe.

We require minimal maintenance to validate that we've configured, for example, the correct indexing policies as required by our queries.

New users should make sure they understand partitioning because once it's selected, it is difficult to change it. Otherwise, you would need to migrate everything over to another collection.

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.

Our primary use case for Cosmos DB is unstructured data. We utilize it to spin up databases quickly.

We previously used on-premises databases. Switching to the cloud significantly improved scalability, flexibility, and uptime. It also addressed our uptime issues and greatly benefited our organization. We've never had issues searching through any amount of data; it's more than capable of searching large amounts of data. 

The connectors, such as the MongoDB connector and the integration with SQL, are incredibly valuable.

There's a little bit of a learning curve because I was new to Azure. But once you learn the tool, it's pretty straightforward.

I have been using the solution for about three years now.

We haven't noticed any significant issues with latency, but we don't have many applications. The availability is excellent, and we have multiple availability zones, so nothing goes down. 

The solution can scale very well both up and down, although we predominantly work with smaller databases. We haven't needed extensive scalability yet, but it seems very capable.

We previously used MongoDB. The shift to Cosmos made sense as we wanted to move to the cloud and benefit from its MongoDB API connection.

The setup was straightforward. Team members could start using the tool within a few hours, although not at an expert level.

As far as I know, it's cheaper compared to running on-prem, although comparing costs exactly can be challenging.

I personally don't deal much with budgets, but our financial analyst hasn't raised any complaints. The pricing aligns well with budget expectations.

I would rate the product an eight or nine out of ten. We are very happy with it as it runs smoothly right out of the box.

I am building an extension app for DocuSign. One of the ways for me to demonstrate this is by using a third-party database. I read and write data from Cosmos DB using DocuSign tools.

We wanted to use Azure function apps and Cosmos DB because Cosmos is serverless and non-relational, so it's easy to set up and simple to scale up and down. Overall, it was a good fit. 

I like the way you can create and delete records. You pass a JSON, and then it creates a record. It is easy to use because you don't need to know much about Cosmos DB or have prior experience. 

Cosmos DB does a pretty good job of searching. I've never had trouble as long as I search for a unique key or value I'm looking for. If my query is right, it returns the value.

Once you create a database, it calls the container, and then items show up. A better description and more guidance would help because the first time I created it, I didn't understand that a container is similar to a table in SQL. 

I have been using it for six months.

My use case is like a proof of concept, so the data set is not extremely large, but I know from reading about it that it can scale up well. It should do a good job on large amounts of data. 

The initial setup was simple the first time I used Cosmos DB. It took just a few hours for my small technical team to get used to how Cosmos DB works.

The pricing model has aligned with our expectations. In Azure, setting it as consumption-based or serverless keeps the cost low, but we had instances where automation increased the cost significantly. It was more of a configuration problem, where options to keep it minimal are still present.

We wanted to go with Azure function apps and Cosmos DB to keep it serverless and non-relational, making it easy to set up, scale up, and down.

I rate the product as eight out of ten.

We use it for different companies and different clients. We have Fortune 500, startups, and mid-sized companies as our clients. They are in healthcare, finance, fintech, tech, manufacturing, construction, real estate, telecom, and a lot of other industries. They all love it.

It is the best in terms of performance and scale, and it can do both SQL and NoSQL workloads, so it is pretty impressive. One of the least understood use cases happens to be cost and caching. It has a pretty amazing caching engine, and its cost is amazingly low. Especially with the strategies we have designed, we can show a cost reduction of 99% in certain cases. The request charge reduction is anywhere between 75% to 99%. It has been pretty amazing to get cost, quality, and time. We can get all three with it. It is one of the very few databases that can even get there.

We use the built-in vector database capability. It is pretty fascinating. You get recalls that are pretty high. In the competitive landscape of databases, it is surprisingly better in terms of p95 latency and also requests per second, which is something that every customer wants but does not easily get by default. You can also use HNSW, for example, a lot cheaper than you would otherwise because of the DiskANN technology. It is similar to HNSW, but it is on the disk, so it is cheaper. You are not going to the memory. That saves you a lot of money, which is important because when you are running workloads that are getting to terabytes and terabytes, the cost is a huge concern, especially to support the underlying business. That is pretty amazing in terms of DiskANN, which is a Microsoft technology that is very well implemented in Azure Cosmos DB.

Usually, the vector database is integrated with a bunch of other applications. It could be a CRM system behind the scenes, or it could be any LLM-based application. The interoperability with other solutions is fairly simple because, at the end of the day, it is just an API. You can make it work with anything.

We use a lot of different models including Azure OpenAI and some open-source ones through Azure AI Studio. They are very easy to use with it because it is just an API.

It is as fast as what you would find elsewhere. It scales, and they do that part for you. Performance and scale are the things that Azure Cosmos DB got right. That is definitely a positive. If you do not use the vector database, you may get into hallucination issues. Things might slow down. Such issues do not happen if you are using the vector database correctly. Your LLM is now supported with the rack pattern, which is done very well by DiskANN and Azure Cosmos DB.

DiskANN does a great job with recalls. We can decide how high we want them to be. That is the best it gets. If you are using vector searches, it does a great job. I do not usually use Azure Cosmos to compete with a regular or classic search engine.

In terms of Azure Cosmos DB’s ability to search through large amounts of data, currently, the maximum we have on it is in terabytes, but a lot of that depends on how you do a lot of things. That includes data modeling and partitioning, and then your entire vector strategy, which is what we specialize in. We have seen great results. You get the best of all worlds. For example, there is a higher recall at pretty amazing requests per second, which in some cases is 10x to 15x of what you would get for the same recall with another engine. Your latency is also a lot lower. In some cases, it is incredibly low. For example, it is 10x to 15x lower than others. This combination is very hard to get with other databases that we have tried, so from that angle, Azure Cosmos DB has done a terrific job.

A few years ago, we put out a report that took Azure Cosmos DB as it is and compared it with other databases out there, and it was 92% cheaper on reads and 20% cheaper on writes. After that, we used our optimization, and we were able to further reduce that by another 75% to 99% in different cases. We have an online talk about it where we partially show how to get there. Those are not full solutions. It was a conference where I had 15 minutes, and I ended up doing a demo. 

It is pretty fascinating because it is very hard for other databases to come anything close to it in terms of the cost given the fact that you have pretty amazing performance and scale. A lot of people can beat you on Azure Cosmos DB, but they do not give you the right performance and scale you need for business, so those cost savings are meaningless. For our customers, it has got to be the best of all worlds, and fortunately, Azure Cosmos DB has that.

Pretty much all of the features are valuable. Change feed is a pretty amazing feature. Once you make the changes, they are quickly read for you, and then you also have geo-replication. You can do a lot of things in your region, and the same regions can be replicated all over the world. There are different geographies. I can have my servers pretty much anywhere in the world. The data could be within the country or continent when there is a data restriction policy and things like that. Security is big. There are a lot of very good features.

It is very easy and very simple now given all the improvements, but it is also designed very well. Especially because we specialize in it, it is the easiest thing on our side. Data modeling happens to be a lot easier than SQL and others. The learning curve is a lot smaller than a typical RDBMS. It is very like code, and that is another benefit. Developers love it because you do not have to learn something new. You can use the same object that you are using in your code, and you can write stored procedures in JavaScript if you want to. If you want to do anything else, you could use the SQL API or NoSQL API, or you could use MongoDB API. It supports a lot of different APIs. You do not have to learn anything new, so the learning curve is way smaller than pretty much anything out there.

The best part of Azure Cosmos DB is that you barely have any maintenance. This is what I liked about it in the first place. 

In the long run, there should be an addition of more features, especially because this space is evolving quickly. It all boils down to how many more features you are adding, how many integrations you are supporting, and how many more APIs you have that are standard APIs. The team is already doing a great job. They are already doing all that is needed, but the more features we have, the easier it is for us and our clients.

For example, when you have these vectors, it requires us to know a little bit about the configuration behind things such as HNSW. When it comes to the MongoDB vCore piece of Azure Cosmos DB, people like us know how to get to higher recalls easily but a regular user may not. If they have a feature that provides an easy way to get to a certain recall you need, and that is a configuration by default, that would be great. Currently, the flexibility is amazing, and we love that. The competition is usually not providing that. The competition sometimes gives you a recall of 80%, but they are taking away the latency and requests per second. Azure Cosmos DB does not do that. It is a better solution. If Azure Cosmos DB has configurations and a feature allowing us to pick any of the use cases we want, it would be great. For example, if I have an application that I am okay with, and my application does not require a huge recall that is 80% but needs one that is 60%, for us, it is very easy to take HNSW and do it that way and reduce the requests per second because that might not be a concern. If there is a feature that allows people to pick out of five different permutations and combinations, it would be very easy for anyone else to do it. However, keep in mind that competition does not even have that flexibility, so competition is lagging behind on that, at least in the case of the ones we have tried. If Azure Cosmos DB has such a feature, it will be easy for more people to take advantage of the things we are taking advantage of.

I started using it when the first version of DocumentDB came out, and then a couple of years later, it was renamed to Azure Cosmos DB. I have been working with it even before it was called Azure Cosmos DB. I am still using it, and it is my favorite database.

In 2020, we put out a report. It is on our website. This was the only one out of all the major databases out there that had a linear throughput increase for hundreds of servers. What is crazy is that everyone else said that they do it, but you could literally see that after a certain number, they would slow down. One of them was a pretty majorly known, multibillion-dollar NoSQL database, but after 50 servers, it would just slow down completely. You could literally say, "Wow, it is taking time to go to the next level." Azure Cosmos DB was the only one that had linear throughput. Our team thinks that the underlying infrastructure of Azure Cosmos DB is procured in advance, and that is why they can have a linear scale for as much as you want to go. It totally depends on how big, literally, Azure is. The competition is running on someone else's cloud mostly. They probably procure machines as they go, and maybe that is why they are slow. This is an interesting thing that made us love Azure Cosmos DB.

Latency is pretty straightforward. They guarantee 10 milliseconds read and write times now, which used to be 10 and 15 earlier. That is one thing that is pretty incredible. A few things that we have shared with customers is that there is always a wrong way of doing things. You may know the right thing, and it is easy for you to get the latencies, but you may completely mess up the data modeling as well as your code and hundreds of different things. You may be making five calls when you need to make one. You may be doing a lot of other things that are not necessarily best practices. In some cases, we have seen people having a latency of more than 200 milliseconds, which we brought down to 10 milliseconds.

Azure Cosmos DB’s dynamic scaling decreases an organization’s overhead costs big time. This is where it stands out. A lot of our clients who were previously using RDBMS kind of solutions found them to be slow. It would take forever. They would not scale beyond a certain point, and they would get extremely costly after some time because you have huge machines. Some of them were paying millions of dollars for one machine, whereas now, they just pay and go and they can scale. They can go all the way up, and if they want to go down, they go down. For example, on Thanksgiving, they may be scaling to hundreds of nodes behind the scenes, and the next day, they could be scaling back to three nodes. Imagine the cost savings when you never had to procure those servers or anything else. This is the genius of this whole thing. They are being able to take advantage of a scale that they could have never had as an organization. This is not just for startups. Even big corporations can take advantage of the same exact thing. It works for every single one out there.

I never had to contact support. If you know what you are doing, then it is really good. I do not even know of anyone calling Azure Cosmos DB support for anything.

I have worked with almost all of the competitor solutions. I cannot think of any disadvantages of Azure Cosmos DB unless the competition is for a specific use case. For example, in the beginning, Redis was great for caching. It had a great Pub/Sub Over a period of time, Cosmos DB got there, but Azure Cosmos DB is a lot more than just that use case. Today, it is easy for me to pick Azure Cosmos DB as a caching engine. I would not have done that five or six years ago.

We do not do much with the on-premises version. We only work with the cloud version.

Its deployment is pretty easy. I have been doing it for a long while, so it is easy for us and our clients. I do not know about others.

Our implementation strategy depends on what kind of project it is. We do greenfield, brownfield, and all of the projects. We do integration projects. We also do projects where they are only doing an addition of LLM. We start with understanding the client's needs and then figuring out what is currently there. If there is nothing, we data model the whole thing from scratch and go with the best practices. A lot of times, if it is brownfield, a bunch of work is already done, so we are not going and figuring out what is the most optimum way to do it within client constraints. We create a strategy based on that and implement it based on their tech stack because everyone has a different one. Once we get the approval on that, we move forward with the implementation.

The number of people required and the time required depend on the client and their workload. If you have a small app, you could be onboarded on day one. If you have a big app with petabytes of data, it is usually a month of work. It totally depends on what we are looking at or the use case.

In terms of the learning curve, Azure Cosmos DB is one of the simplest ones out there. It is on the easier side. There are a couple of them that are pretty easy. 

To new users, I would advise understanding different propositions. Start with understanding what kind of data set you have and every single thing. Also, know the tech stack you have and pick your strategy accordingly. What you do not want to do is go with the flow without understanding what a NoSQL database is supposed to be like and make changes down the line.

A lot of people with an SQL background, unfortunately, start using any NoSQL databases, not just Azure Cosmos DB, in a way that is not very good for them because the patterns that usually are the best patterns for SQL may not be the best patterns for NoSQL. For example, there is a reason we do normalization in SQL. That takes away duplicate data, which is perfectly okay, but in the case of NoSQL or Azure Cosmos DB, we can scale and have duplicate data in places if we have a different kind of use case. If I want to make different kinds of searches available, I can have three different kinds of searches available for similar kinds of parameters. I will not be worried about doing that in a NoSQL environment because I can scale out pretty easily, so data does not hold me back. In an RDBMS environment, I might be doing two or three joins to make sure that I am making it fully normalized because if my data increases drastically, that will create a scale up situation. Scale-up is the only thing you can literally do with RDBMSs. Mostly, scale-out is not that easy unless you are on the cloud and you are using the scale of the cloud, and then you have performance issues. In those kinds of different scenarios, the DBAs or people with an RDBMS background need to come up with an open mind and understand what this is.

It is not that you have to learn a lot about Azure Cosmos DB. You will have to learn about this new paradigm. It is not very new. It has been going on for more than a decade. We have been doing it for more than a decade, but we see a lot of people coming from an RDBMS background and getting it wrong, and then you're paying people like us a lot more money to fix it. It is easier to work with someone like us in the beginning or do a little bit more due diligence and learn that paradigm before you get started. That will save you a lot of money and time, and hopefully, you will not need our services at that point of time. That is definitely my advice.

I would rate Azure Cosmos DB a ten out of ten at this time.

We use Cosmos DB to store the concept of data and how it is entered by the user.

Cosmos database has helped improve search result quality, allowing more results. We implemented the ASR service to gather data from users. Cosmos database does an excellent job of searching through large amounts of data. The speed is impressive, and integrating our power-up database with Kafka was an improvement.

The most valuable features of the Cosmos DB include its ease of use and optimization and its seamless integration with code. We do not use the built-in vector database capability, but its interoperability with Azure AI services is noteworthy.

One area of improvement for Cosmos database is the auto-scaling of RUs during high loads. It would be beneficial if the database could automatically scale resources rather than requiring manual adjustments.

I have been using Cosmos DB for two years.

To scale workloads effectively with Cosmos database, we must manually increase the RUs. During the initial implementation phases, we encountered issues with scaling, but it appears to have been resolved.

We replaced our SQL database with Cosmos and Kafka, resulting in an improvement in operational performance.

The initial setup was straightforward and did not take much time.

I rate Azure Cosmos DB eight out of 10. The system itself is effective for our current use cases.