Microsoft Azure Cosmos DB Reviews

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.

We develop SaaS applications for our products and external clients, utilizing Cosmos DB as the data storage layer for all semi-structured data.

We chose Cosmos DB because it addressed our need to store and query data with varying structures. While object storage is cost-effective for large datasets, it lacks querying capabilities. Traditional relational databases like SQL Server or Oracle are expensive and inflexible, posing challenges for our dynamic data models and frequent changes. Cosmos DB provided a solution with its dynamic data model and efficient querying capabilities, allowing us to accommodate diverse customer needs and evolving data structures.

Our focus is primarily on data filtering and querying rather than extensive text-based searches. While we previously utilized alternative products, we now predominantly rely on Cosmos DB for these tasks due to its ease of use and management. This allows us to quickly onboard customers, especially startups and smaller businesses with evolving needs, as Cosmos DB's flexibility enables rapid data model modifications without significant data management concerns.

For basic queries, Cosmos DB is a very fast and efficient option.

The main benefit of Cosmos DB is its flexibility. It's easier for our developers to work with than previous solutions, and it's better for our customers because we can quickly change and optimize the data structure as needed, eliminating the need to explain limitations. We've also observed that Cosmos DB has improved over time.

Leveraging our prior experience with similar systems, we immediately recognized the advantages of Cosmos DB. Its quick setup streamlined our implementation process, and after addressing a few minor challenges, we could utilize it effectively and efficiently.

Cosmos DB has significantly reduced our total cost of ownership compared to the more expensive alternative we previously used. It's a much cheaper and more efficient solution for our use cases. However, as some of our customers grow, we need to be more strategic with our implementation, requiring additional engineering and planning to keep costs down. While Cosmos DB is initially inexpensive, managing costs at scale requires proactive measures.

Cosmos DB is easy to learn if you're familiar with NoSQL databases, as the concepts are essentially the same. You'll quickly grasp it if you understand NoSQL principles. However, if you're unfamiliar with NoSQL, it might take longer, as Cosmos DB differs from traditional databases. This learning curve applies to all NoSQL products, as understanding the fundamental differences between NoSQL and traditional databases is crucial.

Cosmos DB's greatest strengths are its easy setup and affordability, especially for those who understand its usage. Compared to products like Oracle's Autonomous JSON, Cosmos DB offers greater driver and code support, making it significantly easier to learn and use.

Cosmos DB is quick at searching through basic datasets, though its indexing capabilities may not be as robust as some competitive solutions. This can make it challenging to perform complex queries on large datasets.

The current data analytics of Cosmos DB is inefficient for large-scale queries due to its transactional design. While tools like Synapse can transfer data to an analytical store, there's no effective way to utilize that data. Cosmos, in particular, is not optimized for analytical queries, especially with large datasets, and lacks the cost-effectiveness of solutions like Oracle Autonomous JSON, which seamlessly integrates analytical capabilities. Although Microsoft offers various tools, a comprehensive solution for efficient analytical queries within this system remains elusive, short of implementing a full-blown SQL Server.

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

The latency and availability of Cosmos DB have been excellent. I haven't had to worry about it; the latency has been consistently low, and I can't recall the last time we experienced an outage or performance issue.

Cosmos DB has only been down once the entire time we've used it, and the outage lasted only two hours.

I would rate the stability of Cosmos DB nine out of ten.

Cosmos DB offers scalability when implemented correctly, often in conjunction with other tools to achieve specific scaling requirements.

Cosmos DB's scalability has reduced our overhead by allowing us to efficiently manage costs across different environments, from minimally used development settings to high-demand production environments. Its robust architecture supports diverse applications, including medical and government settings, with sensitive data, ensuring reliable performance and scalability. While proactively addressing potential scaling challenges, we maintain a strategic approach by selectively utilizing Cosmos DB for optimal data management.

We have a good relationship with Microsoft engineers in our region, and some Cosmos leads in Australia. They have responded to any problems we have had with the system.

Positive

We previously used Oracle Autonomous JSON Database, a NoSQL version of Oracle database, and MySQLX, a variation of MySQL supporting unstructured data. Choosing between MySQLX and Cosmos DB is a tough decision. While MySQLX offers powerful SQL querying and analytics that Cosmos DB lacks, Cosmos's distributed nature eliminates concerns about backups and disaster recovery, unlike MySQLX.

Deploying Cosmos DB was remarkably easy. It's the one Azure product I install without worries, as it consistently performs reliably.

Cosmos DB is a valuable resource for our customers because it eliminates the need to set up and manage complex database systems. Its ease of use and global distribution capabilities make it a cost-effective solution for our SaaS product. Unlike alternatives such as SQL Server, which require dedicated database administrators, Cosmos DB allows us to achieve the same results without extensive engineering resources.

Cosmos DB is cost-effective when starting but requires careful management. In my experience with customers, I emphasize that improper use can lead to significant expenses, while correct implementation ensures cost-effectiveness.

I would rate Cosmos DB seven out of ten. If they can fix the analytics issues, Cosmos DB would be a great product.

Cosmos DB presents a trade-off: it's easy to start using and deploying systems, but optimization can be challenging and expensive without proper indexing and data modeling. Efficient querying, especially with large datasets, requires careful planning due to the platform's architecture.

Our organization has a few engineers who directly use Cosmos DB. We have a diverse client base, ranging from small to large enterprise organizations, who utilize our products built on various technologies, including Cosmos DB.

Our comprehensive suite of DevOps tools enables seamless transitions between databases as needed. This streamlined process allows most of our engineers to quickly onboard to Cosmos DB within a week.

If you're using Azure and need a simple, easy-to-start database, and NoSQL makes sense for your needs, Cosmos DB is a good choice. It's a solid product with excellent Microsoft SDKs and enterprise-focused support. While Mongo might offer more developer-focused features, Cosmos DB prioritizes security and scalability, making it easier for enterprises to get started quickly.

We use Microsoft Azure Cosmos DB emulator to display database contents and occasionally perform manual data edits when necessary. We utilize it for general database emulation tasks.

It has been very efficient so far. The team has been using it for quite a while. I am new to the team, but they always talk about how efficient it is. We are using the NoSQL version. It is easy to use for development. It is reliable and quick. 

It has been pretty efficient when it comes to search. I have no complaints about that. It is easy to use and very compatible with Java.

I had a challenging experience implementing the emulator with a Mac. I had to install the emulator in a Docker container because it is not natively compatible. A significant amount of time was spent researching how to enable HTTPS communication when connecting the container and the emulator. I encountered TLS and SSL errors but resolved most of them by setting an environment variable in the container and using HTTPS protocol communication. I also had to use gateway mode with the Cosmos client in my Java app. I am disappointed with the lack of compatibility of the Microsoft Azure Cosmos DB emulator with Mac. I also found a scarcity of online resources regarding this issue.

It would be great to include compatibility with various databases like graph databases, adding to the existing NoSQL and MongoDB compatibility. I have used that for various projects on other platforms, and such additions would be beneficial.

I have been using it for about a week now.

I do not see any stability issues. I would rate it a ten out of ten for stability.

It is scalable. I would rate it a ten out of ten for scalability. We have had no issues with its ability to search through large amounts of data.

We have thousands of users. We are a big organization, and it is being used at various locations.

I love the community forums. They provide a wealth of useful information, which gives me an advantage when it comes to support. The only disappointment was not being able to find any information about setting it up on a Mac.

Neutral

I have used the cloud-based Firestore database and MongoDB before. They largely perform similar tasks, and I have no problems using either one. They work and get the job done.

For me, the setup was not complex because my team had everything ready.

I watched a couple of videos on YouTube. The onboarding was seamless, especially the database part. It took me no more than two days to learn the basics and necessary setup.

In terms of maintenance, it does not complain if you do not update it, but there are always updates that you can add. For example, for the emulator that I am using, there are a lot of versions I can install, but it works with most of them.

I have no complaints. It does its job efficiently and is easy to set up. Our organization has been using it for quite some time. They must see a value in it. Otherwise, they would go for a better technology in terms of performance or pricing.

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

We mainly use it as the database for our platform, which is an application that users use as an interface for their IoT products. I work in the IoT chapter, and we developed an application where customers can manage their IoT devices and have a holistic view of their deployment. All data is aggregated in our database, cleaned up with ETLs, and stored in Cosmos DB.

When dealing with IoT products, we encounter massive amounts of data, unlike in commerce, where traffic and data fluctuate. IoT devices, especially ours, generate constant data streams every five minutes, necessitating robust handling. We chose Azure Cosmos DB, specifically the PostgreSQL version, for its ability to store massive amounts of data without performance degradation, thanks to its columnar storage feature. This allows us to compress older data, such as telemetry data older than two years, which is crucial for managing the ever-growing volume of information. Even with compression, we maintain fast access to the data, ensuring optimal application performance.

I had prior experience with MongoDB on Azure, a platform developed by Microsoft. Since we already used Azure, integration with Cosmos DB, Azure's native NoSQL database, was significantly faster than a standalone MongoDB instance. While Azure offers integration with MongoDB, utilizing Cosmos DB simplified the process due to the readily available APIs. Similarly, Azure PostgreSQL also streamlined integration because it is a Microsoft product, eliminating the need to work with a third-party vendor.

As the only database I've used extensively, particularly with Spark, I recently re-architected our application to identify performance bottlenecks. Surprisingly, Azure Cosmos DB consistently demonstrated exceptional speed, executing complex queries in under 100-200 milliseconds. This contradicted our initial hypothesis that the database was the primary cause of slowdowns. It proved to be one of the most efficient components, requiring minimal optimization. Therefore, Cosmos DB has proven optimal for searching through our organization's large datasets.

We have only used Azure Cosmos DB, so there isn't much reference to compare. However, within our chapter, when dealing with other chapters, there is a noticeable difference in performance in our application. The biggest differentiator in performance and speed for applications is typically the database, and having a speedy database solves a lot of performance issues.

Cosmos DB has provided excellent latency and availability. We have not experienced any database inaccessibility, downtime, crashes, or unexpected bills due to data spikes, even with the massive amounts of data we handle.

A single PostgreSQL node can handle a massive workload of telemetry data, eliminating the need for horizontal scaling in our case. Its impressive capacity and resilience ensure smooth operation even during spikes or large influxes of data.

The standout features are its ability to do data compression easily and the ability to scale horizontally. We initially used Azure Cosmos DB NoSQL, a document-based database, but as our application grew, we realized the relationships between entities were becoming more complex and NoSQL was no longer suitable. To address this, we migrated most of our data to Azure Cosmos DB for PostgreSQL, a relational database, while retaining the original NoSQL database for telemetry data. This approach offers two key benefits: simplified data compression, thanks to seamless integration with our ORM, Prisma, and horizontal scalability, providing the flexibility to expand our database capacity as needed quickly.

Azure Cosmos DB for NoSQL has a less developed interface and fewer SQL commands than MongoDB, and its community support is also smaller. Additionally, Azure Cosmos DB for PostgreSQL users face the challenge of not having a portal for running queries.

Microsoft could improve its pricing, and the way request units are purchased. The current system requires users to pre-purchase an estimated amount of requested units, often leading to unused units and unnecessary costs. This pre-purchase model is inefficient and inconvenient for users. Overall, the pricing structure must be more flexible and transparent to align with actual usage.

I've used Cosmos DB for three years now at Spark New Zealand, and even before that, I worked on Cosmos DB inconsistently until my current company exclusively used it.

I would rate Cosmos DB's stability eight out of ten. We haven't experienced any significant stability issues or downtime.

Scalability for Cosmos DB PostgreSQL is rated around eight point five out of ten. The single node is capable of handling massive loads, and we haven't needed to scale horizontally yet.

In the three years of using Azure Cosmos DB, we never needed to contact support, indicating its reliability.

Positive

I have used MongoDB previously. The integration with Microsoft Azure and its products is faster and easier compared to MongoDB.

Deploying the NoSQL database was simple, but the PostgreSQL deployment proved more complex. Initially, it was particularly challenging due to limited resources; it was around when Microsoft acquired Citus, and comprehensive materials were scarce. The lack of a dedicated portal further complicated the process, making tasks like running queries more difficult than the user-friendly Azure portal available for NoSQL.

The Cosmos DB PostgreSQL deployment, including investigation and testing, took one week, while the deployment itself only required two days.

There were around ten to twelve people involved in building the application using Cosmos DB. Other teams within our organization might also use it.

Pricing is mid- to high-end. The way request units are purchased is atypical, as they must be bought ahead of time based on expected usage, which can be inefficient.

I would rate Cosmos DB eight out of ten.

Cosmos DB, particularly the PostgreSQL setup, can be relatively maintenance-free. While the service itself requires no active maintenance, optimizing for cost-efficiency may involve implementing scripts to compress older data, as demonstrated in the PostgreSQL example. This proactive approach minimizes the need for ongoing maintenance, ensuring the application remains hassle-free.

Our Cosmos DB, deployed in a single region, primarily serves businesses and establishments rather than individual users. Each customer typically has only a few users on the app. Our primary concern isn't the number of users but the volume of telemetry data generated by devices at each establishment. These devices transmit data every five minutes, resulting in a constant influx of information 24/7, 365 days a year.

Within my chapter, around 15 people are using Cosmos DB.

For NoSQL, I would recommend it if you are already using Azure. For PostgreSQL, the lack of a query portal is a downside, but the features it offers can justify its slightly higher price.

We utilize the solution for big data, which is collected from IoT devices and streamed through a number of Azure services. The data is then landed in the Cosmos database for analysis later.

The solution is used because we get faster response times with large data sets than with SQL. It's essential for us because we have half a billion rows, and we need to return them quickly. 

Using it is easy. We are having trouble optimizing it. I'm not a technical person, so I couldn't explain why, but we're not getting the performance we were expecting. I'm sure it's probably an us problem instead of a product problem, but that's where we are.

From about half a billion rows, we're returning maybe 20,000 in two or three minutes. We don't know why, but we are working with Microsoft and a third party to figure that out. 

I have used it for about four years.

There are issues with latency between data arriving in Cosmos and showing up in a query. I'm told that's just the nature of the way Cosmos works. It can take up to five minutes to show up, but that's not a significant issue as we have workarounds in place.

I think the ability to scale workloads will depend on the outcome of tomorrow's meeting.

The customer service is lacking. We have a premier support agreement, but support is hit and miss. There are good engineers and not so good engineers. Premier Support has deteriorated compared to what it used to be, especially for small to medium-sized customers like ours.

Neutral

We used SQL previously, but Microsoft told us to use Cosmos DB because SQL wasn't performing.

The initial setup wasn't a long process. It took a couple of weeks. The whole thing was a proof of concept that eventually migrated into live use.

The solution was a new product, so we didn't have a cost of ownership before. The cost has not surprised us. It's not been an issue. If we were doing multi-master replication globally, the cost would increase significantly, but since we're not, it's manageable.

I rate Microsoft Azure Cosmos DB seven out of 10. If we can fix the problem we have, I could rate it a ten because there's nothing else I can point to for improvement if the performance meets our needs.

We use Cosmos DB in a multifaceted manner, primarily as an operational data store. Additionally, it serves as an analytics and reporting synchronization platform through Synapse Link, Azure's connective data warehousing solution. By connecting directly to Cosmos using the change feed, we project data into our data warehouse and data lake, facilitating both operational functions and analytical reporting needs.

Cosmos DB significantly enhanced our search result quality due to its impressive performance and reliability, bolstering the overall quality of our service offerings.

Realizing the full benefits of Cosmos DB took time, roughly one to three months. This was mainly due to the transition from a relational data store and the need to restructure our data to fully leverage Cosmos DB's capabilities, such as change feed and other features. While the immediate benefit was eliminating infrastructure maintenance and reducing DevOps/SRE overhead, achieving the total value we sought required optimizing our data structure for this new environment.

We primarily use Cosmos DB because it's a managed platform service, eliminating concerns about hosting and reliability. Its geo-redundancy feature allows us to share data globally across three data centers in US Central, East US, and West US, with US Central as the primary write region and the others for reading. Additionally, we leverage Cosmos DB's auto-scaling features, including burst capacity, database-level, and collection-based auto-scaling, and dynamic scaling per region/partition, to accommodate our fluctuating workloads throughout the day.

Cosmos DB has a couple of areas for improvement. Firstly, the lack of multi-collection joins is a significant limitation. Secondly, Azure Synapse Link, their data warehousing and synchronization feature, is unreliable and still feels like a preview feature. Improved reliability in this area would be greatly appreciated. Additionally, while Microsoft provides helpful internal monitoring tools, the managed nature of Cosmos DB can sometimes hinder visibility and make it difficult to troubleshoot issues, leaving us unsure whether the problem lies with our implementation or the service itself. Overall, we are satisfied with most aspects of Cosmos DB, but addressing these issues would significantly enhance its usability.

One of the primary challenges with Cosmos DB as a non-relational data store is the careful data modeling required due to the lack of collection-level joins when using the SQL API. While joins are possible within a single document, joining across documents or collections is not supported with this API. Although the Mongo API and Gremlin API on Cosmos DB allows for cross-collection joins this limitation in the SQL API remains a significant drawback.

I have been using Microsoft Azure Cosmos DB for ten years.

While Cosmos DB has experienced occasional stability issues in previous years, its performance has been consistently reliable over the past 12 months.

The scalability of Cosmos DB is very good. It is one of the best capable offerings for scaling workloads.

We pay for unified response support, and generally, the support for Cosmos DB is good. However, without top-tier support, it can take a while and might not always be the most helpful.

Neutral

We extensively use Google Bigtable and, to a lesser extent, MongoDB. Additionally, we are increasingly utilizing Redis for various NoSQL use cases.

Cosmos DB and MongoDB differ in several key areas. While Cosmos DB excels in scalability, reliability, especially on Azure, and change feed capabilities, MongoDB offers a superior developer experience with local development options and more complex NoSQL use cases like multi-collection joins and advanced store procedures. However, MongoDB's query workloads are generally more capable, and it offers a wider range of indexing options and document size limits. Ultimately, the choice depends on specific needs and priorities, with Cosmos DB favouring cloud-based applications and MongoDB providing greater flexibility for complex database operations.

The initial setup was straightforward; one person completed it within one week.

We handled the deployment all in-house without any external integrator or consultant.

Cosmos DB is a managed offering, so its cost is understandably higher. However, the value it provides aligns with its price, especially considering the discounts we receive. By purchasing reserved units for three years, we secure a significant discount, making the cost justifiable for our needs. Without this discount, the list price might be prohibitive for certain use cases.

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

It took us three months to be fully onboarded with Cosmos DB.

The learning curve for Cosmos DB is certainly different from SQL databases. While most developers become proficient with basic functionality within a week or two, achieving true expertise in Cosmos DB requires a considerably longer time investment due to its unique architecture and features.

The maintenance is handled by Microsoft.

Be very careful with your partition keys when using Cosmos DB.

We use it primarily to log all events for a particular user and product. A particular users are logged in to see if a product has been modified. If someone modifies the data, we log that information along with the email. This helps when we need to compare modifications to a product.

Our admin section benefits greatly as Cosmos DB makes it easier to track down the history of product modifications, including the initial price, the current price, who modified it, and how much it was modified.

The search is slower than SQL but faster than MongoDB and other document databases.

Cosmos DB is a document database that stores data in JSON format for faster retrieval of unstructured data. I personally appreciate the speed, which is significantly better for unstructured data, especially since Cosmos DB had JSON as a data type early on.

It's pretty easy to use and optimize since it's unstructured data. It sometimes takes time since it's in JSON format, but it's useful in the admin section. The learning curve isn't long if you have some SQL knowledge because the queries are similar. It's straightforward for anyone with database exposure. 

We don't use the vector database, but we're aware of it and we know that it will allow faster retrieval with Azure AI integrated.

The UI needs enhancement. Unlike SQL, Cosmos DB's UI is not as straightforward, making it a bit challenging to use efficiently.

I have been using Cosmos DB for the last seven years.

We have not experienced any downtime. The retrieval is significantly faster compared to using SQL for storing JSON data.

We have had no issues with scalability. It works well for us, fitting seamlessly into our workflows.

We evaluated DocumentDB and other document databases, but since Cosmos DB is a Microsoft product and integrates well with Azure, it was the preferred choice. 

Like any technology, it took a little time to learn Cosmos DB. It was relatively straightforward. We had to watch a few videos on how to set up particular databases, indexes, and keys. 

Cosmos DB has definitely improved our organization's cost structure, but I would need to check the specifics to provide exact numbers.

The Cosmos DB pricing model is reasonable, especially since we use it for backup operations rather than front-end processes. We have been using it for several years and continue to do so.

We compared Cosmos DB with DocumentDB and other document databases.

I would rate Azure Cosmos DB an eight out of 10. There is potential for improvement, especially in the UI, which can be cumbersome to navigate.

We use Azure Cosmos DB as our data storage or database technology platform, and we use it as the backing storage of our metering and billing back office system.

We have an energy metering and billing solution, a SaaS billing solution, which is responsible for the whole back office for district heating and cooling suppliers. Our platform is responsible for the ingestion of time series data, and at the end of the processes, we generate invoices, which are sent out to customers. On top of that, we provide a consumer portal where consumers can view their energy usage and consult their bills. 

They are two separate products, and both are using Azure Cosmos DB. The B2C or the consumer portal is using Azure Cosmos DB serverless because of its very spiky nature. It is very unpredictable how many users will be using the B2C portal, and the back office application is using Azure Cosmos DB with provisioned throughput with auto-scale configured, which makes it very scalable and still cost-effective.

The uptime is very good. Over the six years that we have been working with Azure Cosmos DB, it has not let us down even once. We never had any downtime with the service. There is a very high SLA. We do not use the multi-region scale and multi-region deploys, but what we do use is the availability zone setup on Azure Cosmos DB, so we have West Europe and North Europe paired, which makes it very cost-effective to have a failover to a different data center in the same availability zone on Azure. That is the most important part.

Its performance is outstanding. It is very fast. Its evolution and the approachability of the product team have also been good. I have been working with their product team for a while. They have sent over a lot of questions and we have had a lot of interviews, calls, conversations, and discussions on how to best approach certain architectural decisions. We can also discuss and understand how to adapt new features to our infrastructure or architecture to use those features to the fullest. I appreciate it. They are very reachable.

With regards to optimization, it might sometimes be a black box. It is not like SQL where you have indexes, for example, and you have a query plan with indexes, so you can set up and tune to improve your query performance. In Azure Cosmos DB, by default, everything is indexed, which can be good, but it can also be bad because it can impact performance. It is difficult to understand which indexes you really need. You have the basic indexes, all fields being indexed, but then you have composite indexes, which are not created automatically. You need to create them manually. It is difficult to get insight into what type of composite indexes you need, so there is some work there. On the other hand, you can easily follow the resource usage. You can monitor whether your databases are nearing their full resource availability. You either need to scale up or adapt auto-scaling. That is useful with regard to usage. If you are used to NoSQL, you should be able to get up to speed with that pretty fast. We use Azure Cosmos DB for NoSQL. That is a specific provider. We do not use MongoDB, Cassandra, and so on. That means that the syntax to query is SQL. You use a sort of SQL syntax, so the step is really small to go from a different NoSQL provider to Azure Cosmos DB. Of course, if you go from a relational database to a NoSQL database, that is a different story.

We could see its benefits immediately after we deployed it. Immediately after we started, it became very clear that it is very accessible and very user-friendly. It is a managed service. It is not like you set up a SQL and you need to do everything yourself. It is a managed service, and you have global distribution automatically. You set a checkbox, and you have a globally distributed database with high availability and continuous backups set up. It takes away a lot of the pains that you encounter as a startup company that needs to interact with enterprise customers. Our target audience is enterprise B2D customers who have specific requirements around data residency, backup and restore, high availability, and so on. Azure Cosmos DB makes it very easy to comply with those requests.

The flexibility and scalability are valuable. You have multiple models. You have serverless, and then you have provisioned throughput, auto-scale throughputs, and so on on top of reserved capacity possibilities where you prepay for capacity. I like that. It gives us a lot of flexibility. The scaling is instantaneous as well. You immediately have all the resources available. The fact it is NoSQL makes it powerful. 

Resource governance across tenants is something that requires some work. There is some room for improvement there. We are a multitenant solution. We decided to follow a certain approach in our architecture, which had an impact on the Azure Cosmos DB. There are multiple approaches to implementing multitenant architecture on Azure Cosmos DB, but there is still no single or best-recommended approach when you have a big variance in the size of your tenants. That is something that still needs to be worked on.

The monitoring aspect can also be better. There should be better monitoring of the costs versus the performance. That is sometimes difficult. It is easy to see or track performance monitoring and separately track your bill, but it is difficult to view the overall picture in terms of the relationship between the cost and the performance. That is something they still have to work on.

We have been using Azure Cosmos DB since August 2018. It has been a bit more than six years.

I would rate it a ten out of ten for stability. We did not encounter any downtime. We never encountered any drops in latency. It is a very stable product.

It depends on how deep your pockets are, but it is very flexible. If you have a good architectural setup, you can easily scale with it. Scaling is almost instantaneous. It is pretty flexible.

I have interacted with their support. If I have issues, I log a support request with Azure, and then it goes via Azure. If I have architectural questions and so on, I already have a lot of contacts within the Azure Cosmos DB product team. I can contact them to get a better understanding. They are very reachable. Most of the time, I get an answer within a few days. I would rate their support an eight out of ten.

Positive

It is a cloud deployment. Its initial deployment is easy. You set up the Azure Cosmos DB instance. It takes a few minutes. One person can definitely set it up.

The time taken by a team to be onboarded with Azure Cosmos DB varies. It depends a bit on whether the user has any experience with NoSQL or not. If he has experience with NoSQL, it would take a few days or months to get up to speed and understand how to use the platform in a day-to-day fashion. There are also advanced features and concepts. For example, if you are using SQL Server, not everybody understands to the fullest how a cluster index works behind the screens, but they do know how to use a query or how to write a query, so there is a difference. Writing a query and so on takes a few days, and that is it. Understanding the concepts of partitioning, such as logical partitions, physical partitions, scaling on those partitions, the quota requirements, high availability and so on might take a few weeks, which still is not that much.

Once you are used to the concepts of throughputs, scaling, or request units, it is easy. In terms of the learning curve as a whole, it is not the easiest, but it is right above it.

Its maintenance is all being taken care of by the Azure Cosmos DB team.

It is hard to say if Azure Cosmos DB helped decrease our organization’s total cost of ownership because we started with a greenfield application. We built something from scratch and immediately started using Azure Cosmos DB. However, there have been two features that have created an impact on TCO. These two features that were released helped to not increase our TCO in one-to-one correlation with the number of customers we have. We have the auto-scale functionality, which is two or three years old now. It made a big difference in the cost. The second one is the dynamic per partition and per region auto-scale functionality. We enrolled in it during a private preview, but it went GA just recently. That decreased the bill as well.

It is expensive. The moment you have high availability options and they are mixed with the type of multitenant architecture you use, the pricing is on the higher end.

We had a look at MongoDB but decided not to use it because the managed service of MongoDB was not so powerful compared to Azure Cosmos DB. You still have a DIY approach with MongoDB and you set up everything yourself, but as a startup, your resources are limited, so you do not want to spend time on setting up the infrastructure.

We also had a look at Postgres. I have a few options in Postgres to do NoSQL, but the actual NoSQL power of Azure Cosmos DB really makes a big difference. We could not find a better solution for that.

We do not use the built-in vector database capability. At the moment, we do not use anything for that. We do use all change feeds, all versions, and deletes to link with Microsoft Fabric to populate the data warehouse. We do not use mirroring yet because mirroring has a few limitations. That blocks us from using it.

Azure Cosmos DB has not helped us to improve the search result quality in our company. That is not something of importance in our application. It is an ERP application.

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