Microsoft Azure Cosmos DB Reviews

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

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

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

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

Unpaid support is not very good at all.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We are in retail and marketing, and Microsoft Azure Cosmos DB gives us the opportunity as a retail industry to store catalog data. This is essentially used for event sourcing. In my department, it is particularly useful for our catalog data storage and marketing operations.

Microsoft Azure Cosmos DB has improved our overall search result quality. It is very easy to use Microsoft Azure Cosmos DB to search through large amounts of data. This is one of the advantages that I can mention with Microsoft Azure Cosmos DB, which is not available or accessible with other solutions. Searching and working with large amounts of data while using Microsoft Azure Cosmos DB is one of the biggest advantages it provides for enhanced business operations.

The aspect I appreciate most about Microsoft Azure Cosmos DB is the scalability. Horizontally, we can add as many servers as possible, which is very key for us as a company. Another important feature is that it is a globally distributed product that comes with numerous benefits. The real-time analytic features it offers, as opposed to structured query language features, provide real-time analysis for our retail and marketing operations. The integrated features, such as Azure Snipes link, enable easier running analytics for our operations. Additionally, we have noticed that it positively impacts our transactional performances as a company.

In terms of improvement for Microsoft Azure Cosmos DB, while it eliminates the burden of managing database infrastructure, we realized it might not be possible to use various models simultaneously as it only accepts a single model at any given point in time. This is an area that could be improved upon.

The operational complexity of Microsoft Azure Cosmos DB can be challenging for individuals who are not tech-savvy. Making it simpler for companies to navigate through various features would be beneficial for future development in terms of reducing its complexity. However, it remains a good product that eliminates many bottlenecks we experienced before in terms of database management, storage, transmission, and retrieval for our business.

While there is complexity in Microsoft Azure Cosmos DB, we have found that software experts and IT professionals who are passionate about the product can overcome these challenges. We have not yet achieved fifty percent in terms of training our staff due to its complexity. However, the benefits significantly outweigh the complexity, particularly in terms of database storage, management, retrieval, and transmission in milliseconds. The global access, real-time capabilities, and low latency in terms of turnaround time make it an excellent solution once fully embraced and deployed.

We have been using Microsoft Azure Cosmos DB for one year.

The initial deployment of Microsoft Azure Cosmos DB was challenging at the beginning, but we overcame these challenges and ultimately achieved positive results.

The performance and stability of Microsoft Azure Cosmos DB maintains low response times in milliseconds. It is fast, effective, and reliable.

In terms of scalability for Microsoft Azure Cosmos DB, the servers can be horizontally scaled, and we can add as many servers as needed. This capability is possible with Microsoft Azure Cosmos DB, which is not common in other solutions. This is a significant advantage of Microsoft Azure Cosmos DB.

It took us approximately three to four weeks to fully set up Microsoft Azure Cosmos DB and get it operational. Our company utilizes multiple software solutions, so integration was a key consideration. With a team of six to seven software developers, along with additional IT experts, we completed the setup within this timeframe, which we considered reasonable for this type of product.

Our company has multiple software solutions, and integration is a crucial aspect. We have a team of six to seven software developers, along with additional IT experts, who assist in working with these software solutions.

I have used SQL as an alternative to compare with Microsoft Azure Cosmos DB. Having Microsoft Azure Cosmos DB come with additional features beyond SQL capabilities was advantageous for our company's deployment.

I rate Microsoft Azure Cosmos DB a 9 out of 10 because there is always room for improvement in any software.

The benefits of Microsoft Azure Cosmos DB were immediate for us. It was within our budget, and we cannot say it constrained our finances because it was approved. The cost-benefit analysis shows that the benefits outweigh the costs. The maintenance costs are also within our estimated budgeted projections as a company.

I am willing to provide references for Microsoft Azure Cosmos DB and can be a reference for anyone interested in purchasing the same product. I am available to be contacted by Microsoft regarding this review should they have any questions.

Our main use cases involve syncing client accounting data and containers, and we use it as a read database. We do not put much into it; we just sync from their on-premises data or from other APIs, and we collect things.

We have not used enough features of Microsoft Azure Cosmos DB yet, which is why I'm here to try to use more. We're trying to figure out how to do more by linking data from things like documents and our SQL structured databases into Microsoft Azure Cosmos DB. Our goal is aggregating our clients' data to run searches or reporting, and we're trying to learn how to use it more.

I evaluate the enterprise-grade security features of Microsoft Azure Cosmos DB in terms of data encryption and access control as excellent.

The scaling of Microsoft Azure Cosmos DB's automatic elastic scaling of throughput and storage works fine in our current projects, and we use shared throughput successfully.

The scalability and ease of use with the APIs of Microsoft Azure Cosmos DB have allowed us to meet our customers' expectations pretty easily with little barrier to entry.

The features have allowed us to become SOC 2 and NIST compliant relatively easily, so I would say that's been a good success for us.

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

We haven't really used the global features; we don't make it multi-regional and only have a backup, so there hasn't been a reason to utilize globalization.

There is nothing right now; that's something that we'd be interested in regarding Microsoft Azure Cosmos DB's consistency models and their role in fine-tuning the performance of our applications.

I have been using Microsoft Azure Cosmos DB for maybe five years.

I faced nothing that we couldn't overcome pretty easily; there were no significant issues. It's always a learning curve, but it wasn't hard to get past.

I wouldn't say we have benefited from the workload management by using it; we just sync data to it and make it available for people to retrieve.

I evaluate my customer service and technical support experience as great; anytime I've needed technical support, it's been excellent.

On a scale from one being the worst and ten being the best, I give my customer service and technical support a ten.

Positive

Prior to adopting Microsoft Azure, I wasn't using a different solution to address similar needs.

My experience with deploying Microsoft Azure has been relatively painless; it has been easy, and we haven't had any problems yet.

I have seen a return on investment.

We use it to sync data that is not easily accessible; the scalability and ease of integration into our system have been where our return on investment is.

We considered all Azure solutions before selecting Microsoft Azure Cosmos DB, including table storage, but Microsoft Azure Cosmos DB was a better fit, and we haven't looked at any other solutions.

I wouldn't know how Microsoft Azure Cosmos DB can be improved because I don't think we use enough of it; I need to learn more about what to use in Microsoft Azure Cosmos DB.

I find the pricing transparency of Microsoft Azure Cosmos DB to be a little confusing, but we're figuring it out.

I would recommend Microsoft Azure Cosmos DB to another organization that's considering using it. I gave this review a rating of nine.

Some of the use cases for Microsoft Azure Cosmos DB include storing log files and generating keys for our clients inside Microsoft Azure Cosmos DB. It helps us solve the problem of generating unique identifiers for our clients in Brazil, as we have many clients in our company. The system serves to generate unique keys for client attendance.

We are at the beginning of use, about 2 months in production, but it has been working well so far. We have not faced any problems.

Microsoft Azure Cosmos DB has improved our organization because there are various plans we can choose for different situations. We can scale and improve when needed, and the solution can be provided very fast when we want. The solution we use operates without problems.

We could see its benefits quickly because we can provide Microsoft Azure Cosmos DB very fast and when we want.

With Azure being our main cloud, the valuable features of Microsoft Azure Cosmos DB include integration with other Azure products that we're using and governance inside Azure. For integration with other products inside the Azure cloud, it was a better choice. 

It was easy to use and optimize Microsoft Azure Cosmos DB, as it was not difficult to configure. 

We are at the beginning of production, and everything is working very well. The price can always be lower, but currently, it's not a problem.

My experience with Microsoft Azure Cosmos DB is less than one year.

My impressions of the latency and availability of Microsoft Azure Cosmos DB are good, as we haven't faced any problems until now.

We have not scaled workloads with Microsoft Azure Cosmos DB yet, as we don't need it.

It's a large enterprise.

I would rate the support for Microsoft Azure Cosmos DB as excellent because the support team was very nice and helpful. We just send an email or call on Teams, and they quickly answer our questions.

Positive

I would rate the ease of setup for Microsoft Azure Cosmos DB as a seven out of ten. The setup was not very difficult because of the SaaS deployment, as we just needed to configure some things, such as the network and type of billing.

We did a detailed research on the solution we needed and decided to go with Microsoft Azure Cosmos DB. It took us one hour to set up the environment, tables, and connections.

In terms of the learning curve, another team is using it more extensively. I don't know if they have had any challenges. The learning curve seems to be pretty good.

For the deployment of Microsoft Azure Cosmos DB, we required two people. The roles involved in the deployment included one person from the network team and one person from the infrastructure on the cloud team.

We have seen a return on investment with Microsoft Azure Cosmos DB because we can have more control over our NoSQL solution. More control over our NoSQL solution helps us manage fraud, which can save money. We can better understand our data using this solution since we can integrate with other data and create views to understand the information.

We are not consuming so much yet since we are at the beginning of using this solution. I would rate the pricing of Microsoft Azure Cosmos DB a six out of ten.

We needed this kind of product. We are using NoSQL for the first time. We previously looked at MongoDB, but we switched to Microsoft Azure Cosmos DB because we preferred to use a native solution from Microsoft. The main difference is that Azure Cosmos DB is a Microsoft-native solution, and we prefer it because we have the support.

My advice to people considering using Microsoft Azure Cosmos DB would be that if they are using Azure and need a native solution, it is a nice choice. If they use MongoDB, they would need some APIs to integrate. 

As it is our first time using a NoSQL solution inside the company, we will probably continue using Microsoft Azure Cosmos DB. 

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

I used it in my last organization. We were creating a full-stack web application and used Microsoft Azure Cosmos DB to store user credentials and most of the transactional data, as well as user chats. We did many PoCs for the vector embedding of files for critical things.

We used the built-in vector database capabilities in Microsoft Azure Cosmos DB; we conducted different PoCs around that and tested many beta features. We tried them, and there were obviously hiccups because they were in the beta phase. The additional support provided was sufficient to help us with our PoCs.

RAG was something we wanted to deep dive into. We were trying to get a few machine learning models to run from the Kubernetes side. We wanted to take the data from our own database and then vectorize it and RAG over it so that we could have Q&A directly for what we wanted to do. 

We built an application internally for taking official documentation present on any publicly accessible website, chunking it, and vectorizing the data into vector embeddings. We used it to have Q&A so that we didn't need to go over much official documentation. That was the internal use of it, which helped significantly. We followed the guides present in the Azure official documentation and their YouTube channels. Operationally, it helped with efficiency. We doubled our productivity with this small application. When building something, if we didn't know about the technology, we typically searched the internet or ChatGPT, but with the application, we didn't have to follow the older practices of going to the official documentation, reading, understanding, and getting snippets there. With vector embeddings and RAG built over it, we could also optimize feedback from customers that guided our future enhancement, whether to build new features, enhance existing ones, or remove features that weren't beneficial.

Using Microsoft Azure Cosmos DB improved our organization's search result quality significantly. While running queries during the test phase, we were able to configure which particular dataset required fewer RUs and which required higher RUs. This way, when handing off the end product to customers, we ensured that only databases needing higher throughput would get more RUs. It positively impacted the costs. It helped us lower the overall cost of the database, dropping from 33% to 22%, reflecting an 11% decrease in the latest quarter.

The best part of Microsoft Azure Cosmos DB is that with the default configuration and the Azure functional pipeline, if your go-to cloud provider is Microsoft Azure, the whole integration is seamless. Doing it by SDK or any other way, through a POST request or HTTP request, is easy, and that is documented, so that is a plus point. 

Apart from that, the NoSQL database with SQL query support is a significant advantage. You can have both semi-structured and structured data stored in JSON and then have SQL queries run over it, which can be more advantageous compared to other providers.

The topic of RU consumption needs better documentation. 

Now that Microsoft has partnered with different LLM organizations, such as OpenAI, a bot could guide us through different metrics present in Microsoft Azure Cosmos DB. For enhanced productivity, it would be better to add information about the new features to the Microsoft Azure Cosmos DB admin dashboard itself. We usually have to rely on YouTube tutorials or the official documentation. 

Furthermore, while it is supported regionally, I did experience a rare case during our working time where it went down on their end and showed faulty previous data. Better error handling would be beneficial. We had to go to forums to check if it was failing for everyone else. It was surprising that a large organization like Microsoft doesn't provide an official statement about the maintenance or issues that could impact our overall usage.

I would rate the customer support of Microsoft Azure Cosmos DB a seven out of ten. The reason for deducting three points is that when you raise a support request, you don't know who will respond. Sometimes, the assistance is very helpful and effective, while other times, it might not meet expectations.

Neutral

It didn't take much time. We had a meeting for deploying certain elements, along with two environments for development and production, and completed cost estimations in one to two days. It took us about one to two weeks to spin up everything. We didn't only create Microsoft Azure Cosmos DB; we also migrated our data from the existing dataset to the new one. It took about a week. We were a small company starting up, so we didn't have that much data. If this involved a larger company, it would have taken one to two months of effort.

Initially, using Microsoft Azure Cosmos DB was uphill because we were just beginners, but it then got easy, and I was enjoying my ride. It was seamless; there was support for different language stacks. From that perspective, it was easy. We didn't need many tutorials or helper guides for it. We just read the official documentation, which made it easy to get hold of it.

The learning curve for Microsoft Azure Cosmos DB is straight; it's not steep. I didn't have extensive prior knowledge, but I followed the official documentation and a Kubernetes course recommended by a senior. After a few days of completing that course and reviewing a few documents, I was up and running.

Initially, our environment size had about three developers, which scaled up to four or five. Eventually, it included non-developers and an ML team. We were a small organization, so it never scaled over 10 developers, and including clients, it never went over 30.

Microsoft Azure Cosmos DB helped decrease the total cost of ownership. When I joined the organization, we were shifting from AWS to Azure. We were part of the Microsoft for Startup Founders Hub and had credits from their end. While trying to establish multiple PoCs based on our investors' suggestions and our client's recommendations, we aimed to have a data warehouse for clients' data for better future project developments and for enhancing current offerings or eradicating features from the current stack. 

That helped with cost estimation for the overall project and different features we gave, such as the image generation feature, which was one of the main client demands. We spun up an image generation model in Azure Machine Learning Studio, connected its data to Microsoft Azure Cosmos DB via a pipeline. The costs spiked for us, so we added a register cache on the frontend, and in the backend, we created a workaround to directly store the most searched or most recently created images into BLOB storage linked to Microsoft Azure Cosmos DB. This allowed faster access compared to re-generating through the entire pipeline, which also contributed to reducing our costs.

If you are a small organization or startup building from scratch without the Microsoft Startup Founder Club support, it could be expensive. However, if you have the budget and your use case leans more towards AI, Microsoft Azure is leading in AI integration compared to other cloud service providers, giving you an edge. If it's about the latest AI, especially LLM RAG, which often involves vector embeddings, Microsoft Azure Cosmos DB can handle that.

For mid-tier organizations that have thoroughly analyzed the data migration costs and potential new charges, Microsoft Azure Cosmos DB could be a viable option. For top-tier organizations, it's a better route to go through Azure itself.

It handles semi-structured data and unstructured data efficiently, which worked for us because we dealt with images, videos, and other multimedia formats that couldn't be structured properly. However, there was some uncertainty with increasing the RUs and other elements, which complicated things because when you increase the RU and limit it to say 800 or 1,000, even though you are not reaching that limit, you're still paying for it, which is a disadvantage for a startup. You're burning money for that.

We didn't have huge amounts of data to assess in Microsoft Azure Cosmos DB, but it was efficient. Its efficiency also depends on how you've configured it.

Overall, I would rate Microsoft Azure Cosmos DB 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.

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.