Microsoft Azure Cosmos DB Reviews

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

Overall, Microsoft Azure Cosmos DB is easy to use.

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

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

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

The autoscale feature is the most useful for us.

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

I used to work for a bank in Turkey and used Microsoft Azure Cosmos DB in the bank for reporting. We used the solution for customer relationship management (CRM) and cost management.

Microsoft Azure Cosmos DB is easy to use and implement for application programmers.

The integration of the on-premise solution with the cloud can be difficult sometimes.

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

Microsoft Azure Cosmos DB is a stable solution if you use it on the Azure cloud.

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

Microsoft Azure Cosmos DB is a scalable solution. Currently, 10,000 users are using the solution. They use the dashboard application, but the dashboard application calls the data from Microsoft Azure Cosmos DB.

The solution's initial setup is straightforward if you use it on the Azure cloud.

We use a Microsoft subject matter expert (SME) to integrate Microsoft Azure Cosmos DB with the cloud or banking application. Microsoft Azure Cosmos DB can be deployed in one day. The solution's implementation is very easy in the Azure portal, but the most time-consuming step is to define the old data model in Cosmos DB. The security and the integration between Azure and on-prem are also time-consuming.

Microsoft Azure Cosmos DB is moderately priced, where it is neither expensive nor cheap.

The solution's licensing is usage-based. You will have an enterprise agreement if you use the solution in a cloud environment. The enterprise agreement is complex, where it is usage-based in addition to a base price. They decrease the solution's cost for an enterprise agreement, calculate the usage, and charge monthly bills.

Microsoft Azure Cosmos DB was deployed on the cloud in our organization. Only two or three people are enough to deploy and maintain the solution. Microsoft Azure Cosmos DB is the best solution for customers needing high-quality technical support.

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It has been five years. 

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

Its latency is good. The availability is also good.

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

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

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

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

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

Negative

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

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

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

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

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

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

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

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

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

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

We use Microsoft Azure Cosmos DB as a NoSQL database to store JSON documents for our clients in the Banking, Financial Services, and Insurance sectors, primarily insurance. They require storage for numerous documents, including policy, claims, and costing documents, making Cosmos DB the ideal solution.

Because the company is spread across multiple regions, maintaining consistency with traditional relational databases was a challenge. Cosmos DB solved this by offering various consistency options and geo-replication capabilities. Logical partitioning within Cosmos DB improved routing efficiency, and composite indexes, combined with the partition key, optimized query execution by directing requests to specific documents, minimizing resource consumption.

Cosmos DB can offer faster data retrieval than SQL for certain queries and workloads, particularly those involving large volumes of unstructured or semi-structured data.

Cosmos DB is highly capable of handling large workloads and offers exceptional reliability for document storage and similar needs. Its particular strength lies in-stream analytics, a functionality currently not supported by MongoDB. This makes Cosmos DB the ideal solution for customers requiring real-time data processing, and it is our consistent recommendation for those working with stream analytics.

I appreciate Microsoft Azure Cosmos DB's robust document management and consistent availability. The databases are always operational, ensuring continuous accessibility and simplifying disaster recovery procedures. The geo-redundancy feature is particularly valuable, especially for European operations.

Cosmos DB needs improvement in a few areas, primarily the ability to join data across containers. Currently, it doesn't support cross-container joins, forcing developers to retrieve data from each container separately and combine it using methods like LINQ queries. This workaround is inefficient and cumbersome. A built-in join functionality would be a significant improvement. Additionally, Cosmos DB's SQL queries are susceptible to injection attacks due to limited parameter support. Currently, only one parameter can be used, compelling developers to use string interpolation, which introduces security risks. The ability to pass multiple parameters would enhance both security and code quality.

Sometimes, clients may lack technical expertise and run queries without utilizing partition keys, leading to significantly increased request units and higher costs. While Microsoft Azure Cosmos DB currently leads the market, enhancements are needed, particularly regarding data statistics across different containers. Dealing with clients who have multiple containers often requires custom code to stitch data together, highlighting the need for functionality supporting joins across containers. Additionally, a more stable and predictable pricing plan would benefit both developers and clients.

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

Microsoft Azure Cosmos DB offers exceptional stability, boasting a reliability rating of 99.95 percent. This ensures continuous availability without downtime.

I rate the scalability of Cosmos DB highly, with a score of nine point five out of ten.

Microsoft's support services are inadequate, especially during critical incidents. The faster response times found in community-driven resources, such as Stack Overflow, underscore the shortcomings of Microsoft's customer support.

Negative

While Amazon DynamoDB offers extensive configurability, this can be time-consuming. For projects with tight deadlines requiring a NoSQL database, Cosmos DB is a preferable choice due to its ease of setup and minimal configuration. Additionally, Cosmos DB provides superior support for the Jira application and offers better uptime than DynamoDB.

The provided templates help us deploy Cosmos DB quickly.

Cosmos DB's billing is based on request units, which isn't ideal for all clients. Pricing plans offering set benefits, similar to Azure's platform resources, could be beneficial. The current method lacks clarity for clients new to cloud-native architectures, hindering migration from on-premises systems.

Billing is based on request units, so it's crucial to optimize queries to minimize consumption. A standard estimate is one to one point five request units for read requests and four to five for insert, update, or delete operations.

I would rate Cosmos DB's cost at seven out of ten, with ten being the highest.

Cosmos DB can provide improved search result quality, but we must understand the partition key of our container. Using the correct partition key in our queries ensures precise results. Without it, queries may consume excessive Request Units of over 5,000 and ultimately fail.

Microsoft Azure Cosmos DB is a strong product with the potential for improvement in supporting joins from different containers and providing more stable pricing plans. Despite these areas for growth, Cosmos effectively competes with services like AWS DynamoDB and currently leads the market. Overall, I rate the solution an eight out of ten.

Our Cosmos DB deployment spans across Europe, with the primary data center located in Italy to serve our European users. Additionally, we have another customer based in the eastern US, where their data is replicated across three data centers in the eastern US and three more in the western US for redundancy and high availability. We currently have 40 projects using Cosmos DB for clients in different industries ranging from oil and natural gas to sports and media.

We use Azure WebJobs to maintain our databases by removing expired policies and contracts. However, Microsoft should implement a similar system in Cosmos DB, utilizing its Hot and Cold Tier functionality for archival storage. This would allow us to efficiently move outdated data to archival storage, mirroring the functionality we have with Azure WebJobs.

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

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

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

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

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

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

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

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

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

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

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

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

I was using Microsoft Azure Cosmos DB to store unstructured data.

It is easy to learn how to use Azure Cosmos DB.

Azure Cosmos DB enhances search result quality by enabling rapid data retrieval within its collections. It can handle large amounts of data efficiently.

Azure Cosmos DB offers numerous advantages, including flexibility, cost-effectiveness relative to performance, and a pre-existing infrastructure on Azure. Its support for multiple data models, extensive document database capabilities, and fully managed maintenance provided by Azure make it a compelling choice with immediately apparent benefits.

Microsoft Azure Cosmos DB simplifies the process of saving and retrieving data. The only requirement is to create the collection and streamline data management.

There should be a simpler way for data migration. Currently, we need to write scripts to update data in bulk and ensure proper connectivity for migration with .NET, which seems hectic and risky.

I have used Cosmos DB in my previous project for around one year.

Azure Cosmos DB offers high availability, at approximately 99.9 percent, with good latency.

Azure Cosmos DB handles scalability well. It is easy to scale up the workloads.

Dynamic scaling enhances cost-efficiency and usability by automatically adjusting resources to meet demand. This means the system scales up capacity when needed and scales down when not in use, preventing unnecessary expenses.

I have used MongoDB, but not extensively. If working with Node, I would recommend Mongo, but in a Microsoft environment, I recommend Cosmos.

The initial deployment was manageable. It took around five to seven hours to deploy Cosmos to a working condition fully.

At that time, we had a team of four people managing the infrastructure and deployments.

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

New users should be familiar with DocumentDB since most people are only aware of relational databases, but Cosmos is different.