Microsoft Azure Cosmos DB Reviews

Our use case for Microsoft Azure Cosmos DB is storing track and trace data, mainly for regulated markets.

The recent introduction of autoscale V2 has been a big benefit for us, as well as the compression has helped us reduce our costs without much impact.

It's a platform as a service; it definitely helps us operate better. We are not a big company. We have 200 people. It would be impossible for us to run the systems without a platform as a service.

It is pretty fast to learn the basics. However, when it comes to optimization and understanding all the details, it takes a little bit longer. Its learning curve is pretty short. It's pretty intuitive.

I would assess Microsoft Azure Cosmos DB's ability to search through large amounts of data as an eight out of ten.

What I appreciate most are the latency and the access, which are guaranteed by the tool, which is really impressive. I appreciate that it's a platform as a service that allows me not to think about capacity or operation, which makes a big difference for us.

What is missing in Microsoft Azure Cosmos DB is definitely cold storage. We know it's coming, but that's currently what is missing—the possibility to park older data in a cold tier. Aside from the storage, we are pretty happy with the rest.

I have been using this solution for six years.

I would rate the stability of Microsoft Azure Cosmos DB a nine out of ten. It is super stable.

Microsoft Azure Cosmos DB is highly scalable. I would rate it a nine as well, although we sometimes encounter data center capacity issues because we are in the top three biggest instances of Microsoft Azure Cosmos DB.

Our clients are enterprises. We have 20 people working with this solution.

We have regular contact with the product group, who listen to us to optimize our consumption and help us improve our solution to get more benefit from it. We had one incident, and they were very supportive during the incident, resolving it within the SLA, so it has been a good experience.

I would rate the technical support for Microsoft Azure Cosmos DB an eight out of ten.

We did not test or use another solution. We went with Microsoft Azure Cosmos DB from the beginning, so I cannot really judge any improvements compared to what we were doing before. My experience is only with Microsoft Azure Cosmos DB.

I would rate its initial setup a nine out of ten. Implementing the solution takes weeks, but the deployment of a new instance takes less than a day. 

I believe Microsoft Azure Cosmos DB has decreased our total cost of ownership by clearly decreasing operational costs; the solution is highly reliable. On the other hand, the cost of the tool is still pretty high, which is a common complaint among customers. Looking at the spread of Microsoft Azure Cosmos DB on our total Azure landscape, it is by far the biggest cost point, so it is still expensive, but it is highly reliable and high-performance.

It is pretty easy to use, but it is tricky to optimize because of the way the pricing works. You need to understand exactly the details of how the pricing works technically to stay within reasonable pricing.

We do not utilize the built-in vector database capability yet, but we have plans to.

I would recommend Microsoft Azure Cosmos DB to other users. I would highly recommend digging into the details of how it works behind the scenes and discussing with the technical team prior to implementation to avoid mistakes that could lead to a gigantic invoice at the end of the month for nothing. Ensuring a good understanding of how it all works.

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

We have a very large team of developers who develop a solution for our customers. In the part where they need some infrastructure on Microsoft Azure, we deploy entire environments of different types such as development, testing, production, and pre-production to Microsoft Azure and configure it, monitoring that infrastructure, one of them being Microsoft Azure Cosmos DB. Later, we hand over those resources to our development team and they can start to use it.

For example, we have one application which is for one of our post offices where they host their main application for tracking packages, for sending packages, and for everything they provide to their customers. The main database for this solution is Microsoft Azure Cosmos DB.

In production, we definitely are using automatic scaling because of the workload, since some days there is a workload which is very high and some days it is not so high. For non-production environments, it's a minimal setup with minimal SKU on Microsoft Azure.

Availability is for sure better with Microsoft Azure Cosmos DB, but it's also the biggest cost for that setup. We are a very small country from Slovenia, so our customers don't require so much high availability for their applications. This leads us to set up resources only in one region for most of them, while for the most critical workloads, such as those from banks, we use the multi-region setup and auto-scaling.

About the performance, I monitor everything that's going on, what is possible on the resource level in Microsoft Azure, and we also do the FinOps solutions for our customers, utilizing different metrics to optimize resources and the entire setup.

Overall, I think Microsoft Azure Cosmos DB works fine. I don't remember any case where our developers or our clients have been disappointed with it.

The benefits we and our clients have seen from using Microsoft Azure Cosmos DB are similar to those most platform-as-a-service solutions provide, where you don't need to take care of the underlying infrastructure, which is the main reason.

I have not utilized Microsoft Azure Cosmos DB multi-model support for handling diverse data types.

I'm not in the position to decide if clients will use Microsoft Azure Cosmos DB or any other database. However, I notice that there is more and more Microsoft Azure Cosmos DB setups in different applications.

The only problem I face is more with infrastructure as code templates that don't cover everything that can be set up or configured on the portal, requiring some manual work which is additional work for us. Some resource providers don't provide certain configurations, which I think is on Microsoft's side because they need to change Azure Resource Manager and the version of templates. Other aspects involve different providers for those templates including Azure Verified Modules with pre-configured templates on the community and the team working on them.

I have been using or working with Microsoft Azure Cosmos DB for the last year and a half.

I usually use Microsoft support, and I would evaluate them around one to ten as very bad for the first level. They have some instructions and procedures they follow without listening to customers, primarily seeking to get their checkboxes rather than fully understanding the customer's needs. However, upon reaching the product group or a higher level, the support was great. I currently have one critical ticket open for another solution and it has been handled excellently.

Based on my experience with Microsoft support, I would rate them around eight on a scale of one to ten. To make it a ten for me, they need to listen to customers more instead of just going through their automatic process.

Positive

Our clients see metrics in terms of ROI after some time, but not at the beginning. They usually observe cost saving and time saving post-optimization when we find the right SKUs because most of the time, they don't know what they need regarding the required SKU or size of some resources. After time, for sure, they see ROI.

On average, the kind of savings we see ranges from 15 to 25 percent. The savings I refer to are in money saving.

In my opinion, the main difference between Microsoft Azure Cosmos DB and other types of databases is hard to say. It's mostly how developers see everything, as it depends more on the development side—what they want to use and what features they need, such as relational databases or document databases. This leads us to select the right database based on those inputs. The selection is based on the use case.

We are implementing other Microsoft Azure solutions like Azure SQL and Postgres. We focus only on Microsoft Azure and do not work with other vendors like AWS. I gave this review a rating of ten out of ten.

Our current use cases for Microsoft Azure Cosmos DB include IoT-based applications such as home automation, conferencing, and industrial automation, utilizing devices like microphones and speakers.

The best feature about Microsoft Azure Cosmos DB is its interface, which is awesome for accessing data. Additionally, its indexing capabilities and responsiveness allow us to get information with a very excellent SLA, making it suitable for our IoT-based applications where we can update the statuses of devices in real time, which is an outstanding feature. Microsoft Azure Cosmos DB has helped us improve the search result quality in meaningful ways.

The user interface of Microsoft Azure Cosmos DB is the best part of the entire Microsoft ecosystem; I find it to be the best user interface you can ever hope for, especially when compared to AWS and GCP, which do not measure up as well.

The only area Microsoft Azure Cosmos DB can improve on is its documentation; while it is solid and very useful, enhancements in the indexing documentation would help users save costs and make it more cost-effective. This is often a missing piece from Microsoft's side regarding how we can utilize it in the most cost-effective manner. The documentation for the FSx tab was not very good, and we faced a lot of struggles with it a few years back. I believe that has improved, however, Microsoft should really focus on these features since data analytics is very important today.

I have been using Microsoft Azure Cosmos DB for the past seven-plus years.

I have never encountered any issues with lagging, crashing, or downtime in Microsoft Azure Cosmos DB.

Recently, we have started using AI in Microsoft Azure Cosmos DB, particularly in AI-based search and related capabilities, which is pretty good.

I have contacted their technical support, and I find them to be pretty good. The speed of Microsoft Azure Cosmos DB support sometimes depends on the tier of support you have. I have noticed that even if you have the highest tier support, the attention given may vary based on the business relationship; I experienced this in organizations where the level of investment in Microsoft services differed, impacting the quality of support.

We have used AWS DynamoDB as an alternative to Microsoft Azure Cosmos DB, which has similar features, however, I found AWS to be much more user-friendly. AWS provides a slightly better SLA, but Microsoft Azure Cosmos DB is not far behind in that regard.

The initial deployment of Microsoft Azure Cosmos DB was pretty easy and went smoothly for me.

Deploying Microsoft Azure Cosmos DB requires only a couple of people, which is good enough. That's how we started, though now we have a very large team. We considered deploying Microsoft Azure Cosmos DB across multiple regions. However, we ultimately decided to keep it in a single region.

There's a feature called AWS FSx tab that allows data in Microsoft Azure Cosmos DB to be utilized for data analytics purposes. However, querying data on Microsoft Azure Cosmos DB incurs costs, especially after crossing their tiers.

The pricing for Microsoft Azure Cosmos DB is more or less the same as its competitors, making it challenging to declare a clear best option.

I haven't used the built-in vector database feature of Microsoft Azure Cosmos DB.

In my previous company, we were partners with Microsoft about six or seven years back. Currently, we are just customers, and the same holds true for my current company as well. 

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

We use it for our internal operations, including order history and other things related to e-commerce.

We do not use the built-in vector database capabilities since they are driven by another team in our organization. We just access through the API.

We find Microsoft Azure Cosmos DB easy to use. We are provided APIs for each and every write or edit access, even for read operations. We don't directly query the database. API-based access makes it easy.

Previously, we used to have maintenance or server issues. We don't have those issues anymore.

The best feature of Microsoft Azure Cosmos DB is API access, which makes it very easy to interact with the database without needing to write queries. It's also fast. As it's Microsoft-provisioned, the cloud is very accessible and reliable as well.

There is room for improvement in Microsoft's maintenance aspect. For example, we had a major incident at the end of December where the entire South Central region was down for our application, causing many problems due to a lack of access to the database. It led to missing data in some systems. They can implement a better backup system or alert system on Microsoft's end. We do receive notices for regular maintenance or updates, but sudden issues create significant problems.

I've been using Microsoft Azure Cosmos DB for more than one year.

In the past year, I have only been using Microsoft Azure Cosmos DB for a year, and previously we encountered Microsoft issues such as maintenance or server problems, but these days we are not observing that as much.

For stability and impressions of latency and availability, I would rate it an eight or nine; we have not seen significant issues recently.

I rate scalability as pretty good. Because it's in the cloud, scaling is easy.

We are a very large organization. It is hard to know how many teams use Microsoft Azure Cosmos DB or still rely on the older systems. I am in India, and our team uses Microsoft Azure Cosmos DB, and I believe teams in the U.S. use it as well.

I would rate the technical support a nine out of ten.

Positive

Before using Microsoft Azure Cosmos DB, we had a different database system in place. The main factor for switching was cost-related. It was a leadership decision, and as a fresher, I wasn't involved in these discussions.

We were not part of the deployment. We were involved in migration activities, but I'm not very sure about the deployment experience. We aren't seeing any major issues now.

Maintenance of Microsoft Azure Cosmos DB is ongoing. There is a Cosmos DB team in our organization conducting maintenance, though not very frequently.

I'm not aware of the exact costs. We received one report a long time ago regarding savings after we started using Microsoft Azure Cosmos DB, but I don't remember the details. It seems to have helped significantly. We were using a different database system previously, and one of the reasons for acquiring Microsoft Azure Cosmos DB was cost.

I definitely recommend Microsoft Azure Cosmos DB, although I'm still learning. It's been just two years, but I've taken courses on Microsoft Azure. I recognize the advantages in scalability, availability, and cost factors, with maintenance issues being minimal as well. 

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

Azure Cosmos DB is our database of choice for new applications and cloud-native applications. I use it anywhere.

Because it is NoSQL, it has the capability to adapt to changes. As compared to Azure SQL or other SQL databases, Azure Cosmos DB is schema-less. We can add new columns anytime, and the application will not break. It is very efficient for application-facing scenarios.

The most valuable feature of Azure Cosmos DB is its scalability. That is the biggest reason I use Azure Cosmos DB.

I also like its developer-friendliness. It is very easy to begin with. Microsoft and Azure are good with that. With all the getting started information and all the introductions, it is very easy to begin with. Optimization is where it gets a bit trickier. That is where you need to be more active and understand why things are not performing as they used to. Most of the time, performance is not a problem. It is always fast. The problem is more around the cost consequence of that performance.

Its vector capabilities are new. They were implemented just months ago. There are probably three things that we were looking to address by using the vector database. The number one is the cost of Azure AI search and indexing. Before this feature came out in Azure Cosmos DB, the alternative for me was using AI search, which is way more expensive if using it as a vector database. Now with Azure Cosmos DB, that price point becomes much more accessible. That is number one. 

Number two is the developer familiarity aspect of things. AI search is more around enterprise use cases or enterprise search and requires more specialized skills to begin with, whereas Azure Cosmos DB is more or less a commoditized developer platform that is much more accessible to a wider developer audience. That is another aspect that it has addressed. For example, if I have a new starter in my team, it is easier to train that person on Azure Cosmos DB than the AI search. With the explosion of LLMs, AI agents, and things like that, the vector database on Azure Cosmos DB is a good place for developer onboarding. It is just way easier. 

The third part is still related to the developer experience, but in terms of the SDK aspect, the libraries available for Azure Cosmos DB are already well-established in the ecosystem. With the vector database capability, it is just a matter of adding an extension of those existing libraries. That means if the applications that are already using Azure Cosmos DB want to jump to the vector database, the jump would not be that big. It is just a matter of implementing it directly with their existing Azure Cosmos DB that they are already using.

We have used the vector database with Azure AI services. The other aspect is using the vector database with document intelligence. We use document intelligence to process a raw PDF document and things like that. From there, we convert that into embeddings, and then those embeddings will be stored in the vector database. It is something we use as a landing spot for new LLM applications.

The quality has improved because, traditionally, we did things in batches. We processed documents once a day or every twelve hours or so. With this new capability, we are very confident to run those processes in real-time. As new documents come in, the process and the workflow can get triggered. It is not a batch anymore. It is in real-time.

Azure Cosmos DB’s ability to search through large amounts of data is yet to be determined. Large is subjective at the moment. I have only tested it up to 2 gigabytes, and for that, it is working pretty well.

Azure Cosmos DB is our default. We do not question it anymore. After migrating out applications from an SQL database to Azure Cosmos DB, the change in the organization is massive. Especially on the application side of things, app developers are much more productive and lean. Previously, we had to go through a very rigorous process. To add new columns, tables, and other things, we had to work with DBAs. With Azure Cosmos DB, we can have a PoC and POV in weeks, sometimes days, instead of six months. That is how the whole NoSQL ecosystem changed our life cycle and productivity.

Azure Cosmos DB has changed our total cost of ownership for old applications, but not for new applications. For those who are still using SQL Servers or other databases, there was an added TCO because different projects are using different databases, whereas about 10 or 15 years ago, we had just Oracle, SQL Server, or IBM. For new applications, it is the default for us, so there is no change in TCO.

There are several areas for improvement. Firstly, having a local development emulator or simulator for Azure Cosmos DB would be beneficial. It would be very handy to have a Docker container that developers can use locally. Although, I know there is a free tier and so on and so forth, having a local environment would be nice. For example, SQL Server is very portable. You can even install it on your machine. That is the number one thing that is missing in Azure Cosmos DB.

The second improvement area is the IDE of choice. That means how you interact with Azure Cosmos DB. For example, with SQL Server, you have SQL Server Management Studio. I know there is a little bit of support for Azure Cosmos DB in Azure Data Studio, but it is not heavily advertised or it does not feel like first-class citizen support. Developer experience or developer tooling is missing in terms of interacting with the database. Better developer tools or an IDE for interacting with Azure Cosmos DB would enhance the developer experience.

Lastly, there is some mixed messaging about what Azure Cosmos DB is, given its multiple APIs. There are so many Azure Cosmos DB APIs available. There is NoSQL. There are MongoDB, Gremlin, and others. There is still some mixed messaging for others who are new to Azure Cosmos DB about what Azure Cosmos DB is. Is this like MongoDB, but then there is also MongoDB in Azure Cosmos DB? I know it well, and I know that the default one is just NoSQL, but others I have interacted with over the last ten years or so get confused.

I have been using Azure Cosmos DB for over a decade. I have been using it since it was announced.

The solution is very stable, and I cannot recall a time when Azure Cosmos DB let us down. I would rate it a ten out of ten for stability. I never had issues with it.

Its scalability deserves a ten out of ten. I have never hit a limit with Azure Cosmos DB.

We have multiple locations and multiple departments. We are in different countries and regions. For our one project, we have multiple Azure Cosmos DBs. We have about seven developers, and we have tens of thousands of users or consumers. Our clients are enterprises and SMCs.

Early on, about a decade ago, when I started with Azure Cosmos DB, I just played with it and created many things. I ended up having a $10,000 bill. Because it was an accident, I had to send a support ticket. The support team was able to waive that cost for me. That left a very good impression on me up until today. I did not have to pay that money, especially when I was just starting. Now, there are very good partners out there, us included, who are well familiar with Azure Cosmos DB. That ecosystem is well supported now. It is not like you are going to a niche database and hoping for the best. That ecosystem is quite mature.

I would rate customer service and support a nine out of ten. The only reason why it is not a ten is because a lot more triaging is required when raising a support ticket. That is the problem I have.

Positive

Before using Azure Cosmos DB, we primarily used MongoDB and Postgres. I have a mixed experience with both of them. There are also Azure flavors of those. You have MongoDB Atlas on Azure and you have Postgres on Azure. That is why sometimes I am very conflicted about which one to use. Both MongoDB and Postgres have captured the audience around the open-source community and the non-Microsoft enterprise or developer ecosystem.

The deployment is a one-off. It is straightforward. For provisioning Azure Cosmos DB, everything is there. It has been straightforward so far.

Its deployment is done in minutes. In terms of maintenance, Azure Cosmos DB itself does not have any maintenance. However, the application that we are supporting and developing needs maintenance. That is it. Azure Cosmos DB does not require migrations like SQL Server where you have to manage a migration from version 17 to 19 and so on.

We achieved a strong return on investment. Using Azure Cosmos DB enabled us to bring a project to the MVP stage in six weeks. With one recent application that we had, if we had gone through another approach, the project could have taken six months in an enterprise setting where everything is slow and challenging. Getting an MVP of that project would have taken six to eight months, but because we had an active choice of using Azure Cosmos DB and other related cloud-native services of Azure, we were able to get to an MVP stage in a matter of weeks, which is six weeks. That was a very measurable impact that we had. If we went another route, just defining the tables, entities, and other things would have taken us a big amount of time. We had already identified base entities. We knew we could add more columns or remove some columns as we went along. That gave the agility to our project.

We do not have to look at it periodically. I do not get support calls that our application is down.

From a startup point of view, it appears to be expensive. If I were to create my startup, it would not have the pricing appeal compared to the competition, such as Supabase. All those other databases are well-advertised by communities. I know there is a free tier with Azure Cosmos DB. It is just not well advertised.

For mid-tier customers, its pricing is justifiable. The enterprise tier is where it is subjective. For organizations that have built a lot of capabilities around SQL Server, Oracle, or so forth, because of the lack of skills, understanding, and capabilities around Azure Cosmos DB, it would appear to be expensive. The professional services aspect of Azure Cosmos DB is what is driving the cost, not the platform itself. The skills required to manage the service can drive up costs more than the platform itself.

I would recommend Azure Cosmos DB for its scalability and performance. Do not be frightened to give it a try. Because there is no local way of doing things, Azure Cosmos DB will always be considered expensive. It is not very developer-friendly when you have to pay upfront, but there is a free tier. Microsoft needs to do better in terms of communicating that it is free to get started.

I would rate Azure Cosmos DB an eight out of ten because of the lack of local development and so on. It also gets confusing with so many APIs. There is a mixed messaging problem around that. The vector database and so on are also confusing. There is a vector database, but depending on which API you choose, there is a different implementation. It is just a bit confusing. I use this every day, so I know it by heart. I know where it is going, but it is just not very easy to get started for others. Messaging and product categorization are not clear. The way they are bundled or packaged is confusing.

As the technical lead of the Microsoft Azure Cosmos DB team in my previous company, I helped our customers. We had a team of around 20 people. We addressed any issues our customers faced when using Microsoft Azure Cosmos DB or related services. Once resolved, I worked directly with our operation manager to engage with customers, checked their user experience, gathered feedback, and made improvements. This work was primarily managed by a manager who collects feedback and monitors KPIs to improve our service.

Microsoft Azure Cosmos DB is very easy to use once you understand the process, and we have a very good team. Because it is more costly compared to other services, the Microsoft product team takes customers very seriously. If any issue arises, they immediately join calls with customers to troubleshoot problems.

Microsoft Azure Cosmos DB has significantly improved the quality of search results, making searching easier compared to other services such as ADF, data factory, or SQL databases. Compared to AWS, Microsoft Azure Cosmos DB is user-friendly and offers robust features.

The Microsoft product team is proactive and engages with customers, helping to update features and resolve issues promptly, demonstrating a commitment to customer satisfaction. The learning curve for Microsoft Azure Cosmos DB is manageable, as it didn't take much time for me to grasp the basics. With the right information, even new users can learn the fundamentals in about two to three months.

For areas of improvement in Microsoft Azure Cosmos DB, the cost from the RU perspective needs attention. The cost structure differs for internal and external customers, causing frustration among some internal customers. Additionally, outside of SQL and Mongo APIs, there is limited support for the APIs. Developing new features compatible for customers beyond SQL and MongoDB would be beneficial, and reducing the overall cost would make it more accessible for startups.

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

The stability of Microsoft Azure Cosmos DB is generally good, though there are instances of outages. I would rate the stability at seven because there is room for improvement. 

The scalability of Microsoft Azure Cosmos DB rates at six. We have documented guidelines to help customers scale, but there are still some issues where customers struggle with scaling down after scaling up. It is straightforward, but some customers might need more guidance on using the Cosmos capacity calculator before scaling up. Customers should be able to scale down easily without needing detailed formulas.

In our organization, about 100 users specifically worked with Microsoft Azure Cosmos DB. This technology is utilized across almost every organization today, and Microsoft provides robust support that is taken very seriously. 

Our clients ranged from small to enterprise businesses, and we managed support requests from various types of customers, including premier customers who required extensive assistance.

The technical support of Microsoft Azure Cosmos DB deserves a rating of eight because I have experience with other services where assistance takes longer. In other services, there are multiple layers to check, but with Microsoft Azure Cosmos DB, we can directly reach out to the Microsoft product team members who are developers, and within a day or two, we can get on a call with the customer to help them with their issues and suggest best practices. This quick support is not seen in other services, where it can take five to ten days.

Positive

I observed many customers migrating their data from native MongoDB to Microsoft Azure Cosmos DB, indicating significant improvement.

Microsoft Azure Cosmos DB stands out in comparison to AWS, specifically with DynamoDB. Microsoft Azure Cosmos DB offers unique and cost-effective features that AWS does not. Additionally, it supports various configurations beyond just SQL or Mongo, such as the Table and Gremlin APIs, which many customers prefer.

The deployment of Microsoft Azure Cosmos DB is very easy. With the right approach, migration can be done smoothly and quickly.

I was using the built-in vector database when I was with the previous organization. There are vector search capabilities and other related features.

I recommend Microsoft Azure Cosmos DB to other users because it has significantly improved, especially concerning visible outage scenarios. The portal now provides clear workload choices for production and testing accounts, making it easier for customers to decide what they need. 

I would rate this solution a seven out of ten.

We are basically a system integrator, so we use Microsoft Azure Cosmos DB in multiple projects for different things, often when migrating from other hyperscalers. We do many AWS to Azure migrations. It's our go-to solution, given its flexibility on the SQL driver and the MongoDB driver. When running a NoSQL database, it's our preferred choice. Recently, with the AI wave, we've been using it as our backing store for many things, from vectors to structured or somewhat structured data. 

One of the scenarios in which we have used the MongoDB driver on Microsoft Azure Cosmos DB was an AI project with the NFL. It was called the NFL Combined Copilot, and we needed to ground data and provide real-time insights to scouts and coaches on the sidelines. It had to be fast and precise, with significant stakes involved. The experience was fantastic in terms of performance. One of the most critical aspects was that there was no room for error - it's five days in February with 350 athletes and 32 NFL teams present. It needs to work, scale, be precise, and bring the required results, or you must wait a year. This has been one of the places where we have pushed it to the limit regarding availability, scalability, and the whole concept of search and grounding for AI applications.

Using Microsoft Azure Cosmos DB and getting started with it is super straightforward. As you scale and adapt along the way, it remains fairly easy to work with. However, as the complexity increases, one challenge is that you need to be mindful of properly structuring your data for world-scale applications. Fortunately, there is plenty of guidance, documentation, and examples available to assist with this.

As a developer or development firm, one of the aspects we appreciate most is the ability to prototype effectively. We can take a project from the initial prototype stage to production-ready status without the need to redeploy the database or switch products. This approach allows us to use the same tools for both prototyping and scaling. It's important to note that you don't have to face a super complex scenario to benefit from this product. It is well-suited for prototyping and remains capable when transitioning to world-scale applications.

With the current AI wave, the built-in vector database capability of Microsoft Azure Cosmos DB for model grounding or the RAG pattern is crucial. Previously, we had to consider alternatives such as Pinecone and other third-party software, dealing with all the problems of designing, scaling, and maintaining the database. Microsoft Azure Cosmos DB enabling this feature allows us to get it out of the box with familiar tools and context, along with the benefits of its scalability and elasticity, providing excellent support for the highly relevant RAG pattern for AI search.

We have developed several AI scenarios, one of which was recently highlighted in Gartner research. This scenario involves discovering multimodal media within the context of sports, showcasing how organizations like the NBA and NFL use Azure to locate specific pieces of content through interaction with an agent. This was built using the vector database functionality we have integrated.

The peace of mind that Microsoft Azure Cosmos DB provides regarding global distribution is invaluable. In traditional databases, you need to consider how to scale, whether horizontal scaling is possible, and handle multi-regions, multi-masters, redundancy, and other concerns when building a world-scale solution. We get most of these features with Microsoft Azure Cosmos DB essentially included.

I would discuss two separate streams. The first concerns the local developer experience. Microsoft Azure Cosmos DB is a complex cloud platform service, and when developing applications, the most legitimate way to test it is by using the actual product. The ability to run an emulator locally would reduce development costs and improve accessibility, eliminating the need to provision it for each developer. When developing an application, developers typically run everything on their own machine. With Microsoft Azure Cosmos DB, to get the exact same experience and features, we end up using it in the cloud on Azure and paying for it during development. As we add or remove developers from the project, we need to provision new databases or instances. Having the ability to run an emulator or replica in the local development environment would be fantastic for cost savings and developer onboarding.

The second area involves tooling around projected costs for queries. Microsoft Azure Cosmos DB has a unique way of using units to charge for CPU or compute while running queries. Having a calculator to determine query efficiency and expense based on current data structure and projected volume would be really interesting. However, if I had to choose one improvement, it would be the local development experience.

We have been using Microsoft Azure Cosmos DB since its release, approximately eight years ago, and we have witnessed its entire journey.

The resiliency aspect makes Microsoft Azure Cosmos DB our go-to solution for databases. It has the ability to run in multiple data centers. If there happens to be an outage, which is unlikely, you still have spare nodes and replicas available. The SLA ends up being extremely high from an overall service perspective. Having the flexibility to continue operations even if one Azure region goes down is significant, as you can still write to it and restore functionality when the region returns. With traditional database engines, you would need to implement complex workarounds, such as restoring backups in another location and attempting to sync back to the original location. The stability is excellent, and its resiliency in globally distributed deployments is outstanding.

The scalability is excellent, though it comes with associated costs. When you need more replicas, regions, or additional resources, you will need to pay for them, but you maintain the ability to scale. This contrasts with deploying your own database, where you would need to handle maintenance, and scaling to required volumes might not even be possible due to engine design limitations. Microsoft Azure Cosmos DB has been built with scalability in mind, which is evident throughout the product deployment. The ability to configure regions and replicas is crucial, and it feels unlimited in potential. As long as you can accommodate the costs, you have the opportunity to expand and improve the SLA without re-architecting the entire solution.

I have used MongoDB and AWS Aurora in different combinations, such as self-hosted MongoDB, MongoDB Atlas, Aurora, and Postgres. Compared to others, what stands out about Microsoft Azure Cosmos DB is its scalability. When working with MongoDB or traditional SQL databases, horizontal scaling and multi-region/multi-master scenarios are complicated topics that require significant work and planning. With Microsoft Azure Cosmos DB, it's simply a matter of flipping a switch. Though there is a cost involved, it removes many complexities and saves our team considerable time.

It's really straightforward and easy to get started with Microsoft Azure Cosmos DB. One of the main advantages is its compatibility with various drivers. For example, if you are migrating an application from MongoDB, you can use the same MongoDB driver to interact with it. The same applies if you're using SQL or DocumentDB; you can leverage the existing code with minimal changes. This is a significant benefit, especially in scenarios where you might be considering a switch in database engines. Often, developers worry about having to revise their entire application when changing databases, but with Microsoft Azure Cosmos DB, that's usually not necessary. For developers familiar with DocumentDB or MongoDB, the ability to use the same libraries and code brings a sense of familiarity, which is a major time-saver. Additionally, provisioning through the Azure portal is a breeze—it's as simple as clicking a button to get started.

The initial setup took less than an hour to do properly, approximately half an hour.

It does not require any maintenance, but as software systems are living and breathing things, you might need to adjust usage patterns and queries for efficiency. Compared to running your own database, there is no maintenance - you don't need to worry about indexes, drives getting full, or CPU scaling.

The implementation was completed by one person.

The pricing for Microsoft Azure Cosmos DB is good, but there is a developer factor to consider. It could be economical or expensive depending on usage. Guidance about query consumption of Request Units (RUs) would be beneficial, especially since costs can escalate if not used properly. When building solutions on Microsoft Azure Cosmos DB as intended, following guidance and documentation, it works well. Compared to traditional databases, it has a different pricing structure that factors in multi-region capabilities, number of requests, and multi-master functionality. While traditional managed databases simply consider CPUs, memory, and bandwidth, Microsoft Azure Cosmos DB's pricing involves more variables. When used properly, it can be more cost-effective, offering better value due to the included multi-region capabilities, which are quite expensive to implement in traditional database settings.

My advice is to start with the drivers you are most familiar with. If you have experience working with MongoDB, begin using Azure Cosmos DB with the MongoDB driver and the code you already know. From there, you can gradually learn about specifics such as request units (RUs), indexing, and partitioning—elements that contribute to what makes Microsoft Azure Cosmos DB powerful and scalable. By leveraging SDKs and libraries you are already accustomed to, you'll have one less thing to worry about: how to use the platform effectively.

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

Our primary use case for Microsoft Azure Cosmos DB is as a solution for customers who are not necessarily migrating an existing application but are looking to build something more cloud-ready and scalable. The objective is to provide a scalable and flexible database solution that does not require the compatibility requirements of Azure SQL, allowing for fast data access across regions without latency concerns. They are not looking for all the compatibility requirements for Azure SQL, but they are looking for something that they can scale quickly without latency.

I found Cosmos DB to be rather intuitive and straightforward. The documentation is pretty clear because it is a managed service. I could give the custom developers their endpoint and even set up managed identity in a way where we do not have to worry about having secret keys and all of those pieces. We are using private endpoints for everything and found it to be working just as advertised.

The most valuable features include the global write capability, which allows customers to read and write across different regions simultaneously, enhancing performance and availability. 

A lot of my customers like the ability to choose a different API with which they are familiar. The flexibility to choose different APIs, such as MongoDB or Cassandra, allows customers to leverage their existing knowledge while using Microsoft Azure Cosmos DB. 

We are using the vector database a little bit. We often use Azure AI search for that capability. We have an application that is taking in legal documents and needs to do a semantic search against those. It is a combination of using the embedding models and vectorization to get closer to the right chunks of the documents that they are looking for. We, in turn, send that over to Azure OpenAI services to fine-tune and get the best result from our initial results.

We integrate the vector database with another application. It is a custom-built homegrown application that provides a UI for their end-users to be able to use AI search and vector search to be able to get highlighted results of their PDFs.

The vector database absolutely improved the search result quality of our customer's organization. They are partially using Microsoft Azure Cosmos DB in that, but, in general, the two combined absolutely did help by not defaulting only to keyword search and being able to do a hybrid between the two.

For this project, there has been significant improvement in the time to process these documents. There has been a 5x time reduction for the end users in finding the data they are looking for, inputting it into their model, and performing their workflow.

In terms of Microsoft Azure Cosmos DB’s ability to search through large amounts of data, for this specific use case, we are probably on the low end of what Microsoft Azure Cosmos DB can accomplish. We have a decent dataset, but definitely not a gigantic one. So far, our experience has been great, but we are not necessarily testing it to its limits. The one that we are working on is still under a terabyte. We only have several hundred gigabytes for this specific customer. It is a lot of data, but in the grand scheme of things, it is not very much.

Continuing to educate customers on how they can take better advantage of Microsoft Azure Cosmos DB without having to completely rewrite their entire application paradigm would be beneficial. They can help them understand that there are multiple options to interact with it. They do not necessarily have to start from scratch. They can refactor their existing application to be able to use it better.

They can continue to find better use cases for it. It helps to be able to show our customers example documents or example applications. It definitely helps us to be able to show customers how they could be using this.

I have been using Microsoft Azure Cosmos DB for around a year to a year and a half.

The latency and availability of Microsoft Azure Cosmos DB are fantastic. It provides resiliency and business continuity without having to do much. Having it already built in is a big selling point.

I am not working with any customers who are going to have any problems with scalability. We are not going to push the limits of what it can do. My customer base does not have to worry about scaling because none of their applications are ever going to struggle with something as global and as resilient as Microsoft Azure Cosmos DB.

Microsoft Azure Cosmos DB’s dynamic scaling helped decrease the overhead costs for our customers. They have spikes, but most of the time, they have a pretty low baseline. Rather than overprovisioning to handle those spikes, they are able to settle in and ride the waves of their utilization throughout the days and weeks. They have seen a decrease in costs and expenditures. It is still early for a lot of it because a lot of new functionality was added. They did not necessarily have a true baseline to compare against, but they like the idea that it is so elastic.

The onboarding process was relatively quick, taking about six to eight weeks, as the team adjusted to using Microsoft Azure Cosmos DB.

We have not run into many challenges during the migration or implementation of Microsoft Azure Cosmos DB other than being novices and unfamiliar with it. We need to understand all the different components of it, but we have not necessarily run into any technical problems or issues with timelines or things like that.

It takes only a couple of months to onboard customers with Microsoft Azure Cosmos DB. We are able to go pretty quickly. Our onboarding path is about six or eight weeks.

There is a bit of a learning curve for the customers who have only worked with traditional Azure SQL VMs and are not familiar with having a fully managed or PaaS instance. There is some learning curve for them to understand that they do not just have x number of cores or memory available, and it just grows as they use it.

In a couple of use cases, Microsoft Azure Cosmos DB helped decrease an organization’s total cost of ownership. Oftentimes, when we are implementing some of these features, we do not have a baseline to compare against. In my own experience, there definitely is an opportunity if we are able to use the model to reduce cost instead of provisioning a VM or something like that, as we would historically do. It is hard to provide metrics, but when I have done comparisons or cost calculations, I have sometimes personally seen as much as 25% to 30% savings.

Most customers like the flexibility of the pricing model, and it has not been an issue. They can start small, and the cost grows with adoption, allowing efficient management of the budget. Its pricing model has not been a concern at all for any of our customers. They understand it. It is simple enough to understand. Oftentimes, it is hard to forecast the RUs, but, in general, it has been fine.

I would rate Microsoft Azure Cosmos DB a nine out of ten. There is always room to grow, but it is a highly capable solution. I am looking for more opportunities to use it as we help customers move toward more cloud-native technologies, rather than always defaulting back to what they are familiar with, which is sticking with Microsoft SQL Server or Azure SQL.