Microsoft Azure Cosmos DB Reviews

I work for a retail company that uses Cosmos DB internally for access management. You have a graph with a hierarchal model that goes from owner to manager to assistant manager to employee, etc., and you provide access based on this hierarchy. Our workshop manager uses Cosmos DB to track requests for access and who needs to approve them. 

Employees who want to access specific resources will submit a request, and the application owners will approve it. Within the applications, there are often multiple levels of access. So the owner of those processes or files must authorize access. We have nearly 500 users. The security and access management teams mostly use Cosmos DB. 

The company is considering a switch, but that might take many years. Many others have switched and will continue to switch to other solutions. However, after you've invested a couple of years into it, it becomes more challenging because you need to rewrite many things. 

I don't think Cosmos DB has improved our organization. People are using it, but I'm not sure it's the best solution. For one, it's costly. Also, there are other issues with it. You cannot get all the records simultaneously. You can only get it in chunks of 1,500 maximum.

Cosmos DB is a graph database. I could see the advantages when we implemented it because it didn't have much competition. MongoDB was doing it, but it wasn't a popular solution for graphs, structures, and hierarchy. The only competitor was Neo4j.

I have been using Cosmos DB for nearly a year.

I rate Azure Cosmos DB eight out of 10 for stability if you allocate the necessary resource units. It is based on the concept of a resource unit. There are three settings: auto, manual, and another one I can't remember. You can manually set a limit on what goes to the resource unit during a specified time. or it will automatically send and continuously increase. 

This can create some instability. For example, if I limit my resources to 30,000 RUs, I expect to consume, but if the load is higher, it will fail and continue to fail. I will get an error that says, "Too many requests."

If you set it to "auto," you'll have to pay for it. You can adjust the limit, but it will not automatically do it. It requires someone who can think in terms of RUs, not the other databases we usually use. The person should always think in terms of resource units because you're paying for each resource unit. It isn't simply writing queries and pulling the details from the database. That is a steep learning curve. Many assume Cosmos DB is like any other NoSQL or graph DB. 

Cosmos DB is scalable, but there are some limitations on the amount of data you can hold in this partition. I think the maximum is 50 GB. That is a lot of data, so it is scalable, but there is a limit. It isn't infinite. Only 99 partitions are allowed with 50 GB each, then the maximum amount of data is under 5,000 GB.

However, it isn't simple because you need to define each record. You have to decide which partition the records should go to. Suppose I have 100 GB of similar records and want to put them in one partition. That isn't possible. 

I rate Azure support nine out of 10. They respond quickly and will help you manage costs. However, they mainly give you an overview of the issue, so they'll never have an in-depth idea of what you're doing. They aren't the owners of our product, so they don't know much about it, but they can ask you generally: What are you doing? Are you doing too many updates? How can we reduce the cost? 

They usually make common suggestions, but so few technical people understand Cosmos DB, and they will be costly. 

Positive

I have used multiple NoSQL databases. The most common is Neo4j, but people also use MongoDB, which is a little easier. You have optimization and all those features there.

I rate Cosmos DB nine out of 10 for ease of setup. The setup is easy, but backing Cosmos DB takes a little more work. It isn't difficult, but you have to raise a request to Azure support. It isn't in your control. The documentation is good enough that most application developers can handle it by following the steps in the documents.

We did it in-house. Two developers should be more than enough. One person could do it alone, but it's always good to have an extra person to verify that your actions are correct. After deployment, it doesn't require any maintenance. When you want to make a copy, you submit a request to the support team and within 24 hours. 

We haven't seen a return. You could benefit from this, but few engineers know how to use it correctly, so that's a problem. It depends on the company. I believe only large organizations can afford it. 

You also should be ready to invest in developers because it has a considerable learning curve. In other databases, you have something called "data cutover." You can change the whole concept of your data to make it more efficient. That is not possible in Cosmos DB. It's too big and will take years to change, whereas that might take you only two or three days in other databases.

For example, let's say you are paying a hypothetical amount for a mistake you made. We'll say it's $1,000. After a couple of years, you realize that you will only need to pay $200 after fixing that mistake, but it will require too many changes in multiple places to fix that error. You might need to discard your old solutions entirely, and it takes years to rewrite everything. Cosmos DB isn't going to reduce the number of people. Conversely, it's going to increase problems and create more confusion.

I rate Cosmos DB one out of 10 for affordability. It was expensive. We pay almost $1,000 daily to use it. It doesn't work traditionally — it works on resource units — so it's costly. It's a graph DB, which has advantages and disadvantages. Neo4j and MongoDB do the same thing, so it depends on your environment and costs.

There are also issues with how you design it. You cannot create the traditional way like you would in other databases or graph databases. Typically, you would pay a fixed subscription yearly. With Cosmos DB, you pay monthly based on the source unit. That's what is expensive. 

It's harder to find designers and developers based on that. Many solution architects will set something up using the traditional way of thinking. Once you start using it expensively, it's challenging to change that. You end up with millions of records, so it's impossible to change all of them. 

We are considering changing from Cosmos DB to MongoDB.

I rate Azure Cosmos DB six out of 10. I wouldn't recommend it. I suggest using other products like Neo4j and MongoDB. If you must use it, you should hire an expert who understands how to design the tables, indexing, and partition keys. The setup is effortless, but how will you write the code? It should be predetermined.

This is an event-driven solution. Most oil and gas companies have folder source systems, where they cannot scale, but they still want to provide real-time data to their end consumers for various analytical use cases and AI/ML processing; this is where we input raw data into the Azure environment of this solution. Then, eventually, we built the API on top of Microsoft Azure Cosmos DB because it's highly scalable. The solution is a little bit expensive, but the businesses are ready to accept it. 

In terms of performance versus scalability of this solution, you don't need to worry as long as you have your initial numbers in place. This product works by using performance currency, which is the number of request units per second. Once the data is ingested, based on that, we can know how many users are going to access across the world in every day, hour, or minute. Once you have the ingestion versus consumer pattern identified, you can use this product to input all those numbers, like the volume of data for migration. 

The built-in integration of the solution is tight. It can be used in conjunction with Synapse, Microsoft has also created a Synapse link. In this solution, the OLTP workload will never affect the OLAP workload. Therefore, the solution does data replication asynchronously without affecting the OLTP source system. No specific pipeline is thus required, which is not easily found in other services. 

In the server, there are two ways in which you can provision a call, one is serverless, which has a pay-as-you-go model, and another is a dedicated provision throughout. So, irrespective of what you allocate and whether you use it or not, in this solution, the charges are accounted for the request unit per second. This is a big drawback of the solution.

This is an expensive solution and if you get the initial calculation wrong involving how much you are going to ingest, how many people are going to query and more, then you are going to receive a very large bill at the end of every month.

Additionally, on the serverless option, there is a limitation regarding the amount of data you can ingest; this doesn't allow you to upgrade beyond a point, and the limit cannot be utilized for many use cases. On the execution side, whatever you create as a container, that container cannot be used as a destination when using serverless mode. This is another key limitation of the solution. 

I have been using the solution for one and a half years. 

I had minor issues while using the solution, but they were actively solved, and eventually, a justification was also given. Ninety-five percent of the time I used this solution, there were no issues. Microsoft's service in the cloud market is still growing and so there are some feature limitations. 

The solution is highly scalable. We use the solution in our enterprise both internally and externally, including integration for clients. We created our solution end-to-end by considering different audiences, people who can directly onboard Azure but might not need Cosmos DB.

There are vendors and individuals who cannot directly consume data on the Azure environment and will have a dependency on data. However, we cannot expose the source data for its performance issues and limited scalability, so we deliver this data by using Microsoft Azure Cosmos DB. The parent company Reliance has multiple subsidiaries like Ajio, manufacturing supply chain, Oil and Gas, and more; we used to use the same API for all subsidiaries, which was built on Cosmos. 

Technical support was good. I would rate the customer support an eight out of ten. They were fast and responsive, but the support team runs from different locations within or outside India, so whoever is working during the particular shift will take care of the case initially and then some other individual will take over.

So, my team had to re-explain the same thing over a call or meeting. But it was only a few times, they were able to get all the information based on the previous conversations most of the time. 

Positive

Deployment of the solution was very easy. Once the initial numbers are in place based on request units, only the instance creation was a time-consuming process. The time was consumed due to the dependency on other teams like DevOps, who are responsible for provisioning. So, it was a one-time process, but migrating and running the same workload between different environments was not much of a hassle. 

It took less than a week to configure and install this solution. To complete the setup, it took five to six professionals from our team. One key solution architect, two people from the DevOps team, and two solution architects from Microsoft were needed for the deployment of this product.

Maintenance of the solution is very easy because the solution follows a Platform-as-a-Service type of model. There is actually no need for any downtime or a patch upgrade because it is taken care of by Microsoft. I never have to worry about downtime for this solution. They perfectly deliver on the key characteristics of the product. 

Our business need was to deliver or provide the source data without any latency issues, in less than five or ten minutes latency, to be precise. We had to provide the data to the end consumer without overwhelming our source. We got the business confidence in the initial three months of using Microsoft Azure Cosmos DB. 

The solution is a bit on the expensive side. 

We tried to compare this solution with MongoDB, which is open-source. But we choose this solution because Microsoft is the first implementation partner for us. 

I would rate the solution an eight out of ten. My advice to other people will be first to identify the purpose of availing the solution. There is also a product called Azure Data Explorer, which is a more extensive service used for similar use cases.

Also, in terms of Cosmos, the user should be clear about whether they will be able to use the serverless deployment model or whether they need the dedicated provisioned throughput Model. They should also first use the price calculator by inputting the numbers to decide if they need it. I would also advise you to get in touch with a Microsoft Specialist and walk through all the doubts. 

The solution has a very good service, but the user should be clear about how to start using the product. For the initial three months, we did a lot of trials to get the components and RUs right and check how the calculation is happening. However, after the trials, we were very clear about how we wanted to move forward with the solution to get the maximum ROI. 

In our setup, we rely on Azure Cosmos DB primarily for cloud-native applications that demand global scalability. We use it for connecting web apps and implementing search functionalities.

Cosmos DB's low-latency data access has greatly improved our application performance. It is a game-changer, allowing us to move workloads from on-premises to the cloud, thanks to the reduced latency, and freeing us from the constraints of on-premises environments.

The most valuable features for our organization with Azure Cosmos DB are multi-master capability for applications, automatic failover ensuring high availability, scalability, support for multiple data models, and low-latency access. Additionally, the seamless integration with microservices running in containers adds another layer of efficiency to our operations.

In terms of improvement, slight enhancements in integration interfaces, expanded dashboard functionalities, and broader use-case support would be beneficial.

I would rate the scalability of Cosmos DB as a nine out of ten.

The technical support is quite good.

It is a relatively affordable solution.

For those considering Cosmos DB, my advice is to embrace its versatility. Cosmos DB can handle various data models like documents, wide columns, and graphs seamlessly. You can consolidate your needs into one database, Cosmos, eliminating the need for multiple databases. It simplifies management and offers a comprehensive solution for a wide range of use cases.

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

I worked on an entity data client project that handled multiple users from digital products, like a Stream player similar to Netflix. It is called Play Plus, with a user base of seven million and a website that attracts eighty-two million unique users per month. We store the data from these users in Cosmos DB to ensure a fast connection between the user profile and the advertising system.

I believe the best features of Cosmos DB are its global distribution capabilities. It supports multi-region replication with low latency in read and write operations and automatically adjusts throughput dynamically based on workloads. It ensures low latencies, offers consistency levels, and provides a serverless mode. Also, for this scenario, the solution was fast due to its serverless nature, allowing it to handle eighty-two million user profiles with low latency and swift connectivity with the advertising system.

I think Cosmos DB enhanced the benefits of NoSQL databases, offering query flexibility, partition management, and backup and restore options. These aspects are crucial, and perhaps improving the complexity of partition management would be a beneficial area for Microsoft to focus on.

I have been using Cosmos DB since 2023 when I executed a project for clients.

I do not experience problems with Cosmos DB, nor does the team have any issues with it.

I have used both Cosmos and AWS DynamoDB. Compared to Cassandra and Cosmos DB, I think Cosmos is a superior solution because it is serverless. There is no need to worry about installation, updates, or security, as Microsoft handles all this. Our focus is solely on development.

The setup was easy, very easy.

By using Cosmos DB, I estimate at least a twenty percent saving because it allows us to develop rapidly.

I truly recommend Cosmos DB because it is a serverless product. Our responsibility is just to develop and adhere to Microsoft's instructions to achieve optimal performance from Cosmos DB. It is an excellent tool. The product rating is nine out of ten.

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.

Our company uses the solution to develop a certain sort of products for our internal companies. We have some child or franchise companies and are developing software for them. 

We use the solution where transactions display to provide views or reports for the console. We also use the solution for an online learning application or portal. 

We have 20,000 to 30,000 users across multiple products, franchise companies, and customers at the backend. Centralized data is global and accessed from all over the world including India, the US, South America, and Asia. 

We have several new projects with the same backend, so our user volume will definitely increase day by day. 

The solution's read capacity and write access functions are very fast so users don't have to wait when fetching or displaying data on a screen. The main feature of an application is how it behaves toward the user. Users get uncomfortable when having to wait a long time. The solution's high-value data processing helps application performance data. 

The solution easily integrates with the Microsoft cloud and other Microsoft products like Azure Active Directory. We use cloud storage for databases so this integration is very beneficial. 

The solution cannot join two databases like Oracle or SQL Server. Joins have to be done programmatically through our sysHUB. We use .NET code so need the middleware to join databases. 

There are certain restrictions for inner classes or employee roles. 

Data retrieval is slightly more difficult than in SQL Server or other SQL databases. 

Documentation needs some improvement to help end users. Documentation for joining includes some generic or peculiar cases but needs to be more comprehensive. It should lay out how to join databases and what procedures to use. 

I have been using the solution for more than three years. 

The solution is stable. We haven't received news of any issues with platforms.

Stability is rated a nine out of ten. 

There are a lot of things we still have to fight out such as joining databases. Most probably for the high-transactional use cases, the solution cannot be used at all. 

Currently, scalability is a seven out of ten. 

Our infrastructure team handles all communication with support and reports that they are good. We have a premium account with Microsoft so support always helps us. 

From 2009 to 2018, we used Oracle at our company. We switched to the solution for various projects due to the needs of users. We needed a product that met our business and users' requirements with the lowest cost possible.

The setup is very easy so I rate it a nine out of ten. 

In the initial days in 2018, setup was uncertain and coding was needed from our side. Now, we use the library to access the database or read and write. Things become so much easier over time. 

Two members of our core infrastructure team handle all implementations. 

On average, deployments take three to five hours. We have to deploy the DevOps side and the data backup. If we consider all things, deployments hardly take a full day. 

The solution doesn't require any ongoing maintenance. 

Obviously, we want to be on the profit side as a business or we can't grow. Money and usability are the most important things for us. 

The solution has already realized some ROI. The pay-as-you-go usage methodology helps us because it saves money. 

At this point, I rate ROI a six out of ten. 

Pricing is one of the solution's main features because it is based on usage, scales automatically, and is not too costly. As usage scales up or down, the price moves accordingly. 

For example, we might have 30,000 users and the requirement is high so the solution automatically scales up. If the requirement lowers because the application isn't being used all the time, then the usage automatically grades down and so do our costs. 

Technical support is included as a free service.

I rate pricing a seven out of ten.

We still use Oracle for some projects but it is costly to acquire. 

We are using SQL Server for an ongoing project. 

The solution is less expensive than Oracle, especially with all of our DLLs. It is easier to work on from a developer's perspective and we realize a good cost savings. 

We choose the best database based on a customer's budget and need. 

Everyone can use the solution where the database hits or the transactional data is placed. 

The solution is not a good fit for companies in the banking industry who have a high volume of transactions every second. The solution always needs a proper SQL database like Oracle.

Companies with non-transactional applications must use the solution because it helps users and achieves a lot of success in terms database costs.

I rate the solution an eight out of ten. 

At the end of the day, Cosmos DB is a database. It is a wrapper over different APIs.

We use Cosmos DB both internally and with our customers. Our internal use is quite extensive. The usage with our customers depends on whether it is an approved technology within their ecosystem.

Because Cosmos DB uses multiple APIs, it is the go-to database for us internally.

Cosmos DB makes life easier because if we want to use Mongo-type data, or Cassandra-type data, or maybe even just a simple cable storage-type data, then graph, there are multiple ways to do this. With Cosmos DB, we can put together a holistic solution when it comes to Azure security policies, Azure Monitor, and access control.

By design, Microsoft Azure Cosmos DB provides multiple APIs. You have to decide where to write to. Will you write to Excel, Word, PPT, or OneNote? You have to do the homework properly. If there is no tool, then there will be no provision, then there is no database.

I would like to see Cosmos DB introduce a feature that would convert machine language to human-readable queries. For example, if we want to generate a simple diagram that shows the relationship between devices and how frequently have they failed at various locations, we have to consider that the IoT data that is put into Cosmos DB, called byte codes, is not readable to humans. This is a machine language type of data. So when we push that type of data it looks like gibberish, because it is not meant for us, meaning we can't write a normal query. We have been asking for years for them to work with the IoT partner to provide a feature to convert the machine language to readable human queries.

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

The solution is stable. I would give it a five out of five for reliability.

The architectural decisions will tell you how the scaling will happen. 

Scalability is based on the requirements that are set. Configuration decisions can be implemented pretty fast, so the solution scales well. We are predominantly in the US and India, so it is easy to decide which geographies we need to have and which data we need to synchronize. 

For some of our customers, there are data residency rules like the UAE for example, where patient data must stay within the UAE, making it only one geography. When this is the case, we go for multiple replicas. 

Internally, we have more than 150 developers who use Cosmos DB. Overall, the scalability of the solution is a five out of five.

Product support is pretty good. They have a very good roadmap and the team provides regular patches and regular service updates, and they have a very good release plan.

Microsoft's technical support is good, I rate it a five out of five.

Positive

The initial setup depends on the type of setup you require. You have to design it properly. The architects need to do some homework to ensure the purpose and the requirements are clear. There are many design decisions that must be made first. Once those decisions are made, the initial setup is quite easy. 

Deployment of the solution was completed within a week.

Overall, I would give the solution a four out of five for ease of setup.

The deployment of Cosmos DB was completed internally, we managed it ourselves.

The cost is intricate, the calculator is complex because the cloud is all about counting every penny. It may look like small numbers, $0.001 per GB per day, but when we are talking of terabytes of data per day and the numbers will stack up. One month, we had over 500 terabytes. That's why you need a database expert to design it carefully and spend ample time number crunching. If done properly, the ROI will be good.

I would rate Cosmos DB a four out of five in terms of ROI.

Cosmos DB is expensive compared to any virtual machine based on conventional RDBMS like MySQL or PostgreSQL. The reason it is expensive is that it is scalable, reliable and there is no latency. So while Cosmos DB is considered expensive, what a lot of people miss is that the cost includes reliability, scalability, and responsiveness.

Cost also depends on the number of databases, number of replica locations, synchronization, number of queries per minute, and storage. Every client will have a different usage pattern. 

Overall, I would rate Cosmos DB a three out of five in terms of affordability. It is easy to over-provision, and it is easy to under-provision the solution.

Prior to choosing Microsoft Azure Cosmos DB, we did try other tools extensively. Because we have servers, we tried MongoDB, SQL Server, MySQL, and PostgreSQL. We settled on Cosmos DB internally because we didn't want to go for machines and trojaning. We wanted to adopt a platform as a service.  

Cost also ended up being a driving factor.

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

Cosmos DB has multiple use cases. For instance, we recently developed a custom application for a customer in India. We used Cosmos DB to store data fetched from the initial front end to reduce access times to the application, which is significant for improving user experience. 

For example, when creating a virtual machine through our custom portal, it is essential to check whether a VM with the same name exists in the same or a different subscription. 

Additionally, we needed to enforce naming conventions and limitations on the number of VMs that can be created within the same network. These conditional parameters were managed using Cosmos DB, allowing the initial provisioning process to validate data and configurations instantly. 

This enables us to inform the user right away if there is a duplication or if the creation adheres to predefined rules, offering suggestions based on the UI. This demonstrates the real-time application and benefits of Cosmos DB.

We use Cosmos DB for its key-value storage capabilities. For structured data, we always use SQL Database.

The low-latency data access provided by Cosmos DB improved application performance.

Application performance improvement depends on what kind of optimization you're looking for. Do you want to improve latency or efficiency? Performance tuning depends on that specific goal.

Here's an example: A customer with an application running in an internal system noticed their outbound data flow and charges increasing every month. They were exporting a lot of data for users in Excel format, which was heavy.

I suggested they export the data in CSV format instead. It's lightweight and users can still open it in Excel. This optimizes data usage and costs without compromising user experience.

Cosmos DB now supports unstructured data. It's a key-value store, so we can send data without worrying about strict structure, data types, and so on. Since it's unstructured, it's lighter than a structured database.

We use Cosmos DB for its key-value storage capabilities, while SQL Database is used for structured data.

There is room for improvement in terms of stability. 

I have been using it for a year. 

In my experience, Cosmos DB is definitely stable. But, for any service or application, I wouldn't give it a perfect score. There's always room for improvement. A perfect score would mean no room for improvement. So, I always consider some buffer for improvement.

I would rate the stability a seven out of ten.

Since it's a managed service, Azure backend handles scalability. From a user's perspective, we don't need to worry about scalability.

Right now I'm dedicated to customers of one of India's largest certificate authorities, Reliance Jio. They have a lot of customers and two dedicated Azure data centers in India. I focus on those two data centers, and I see at least 10 to 15 customers heavily using Cosmos DB there.

From the user's perspective, it's a managed database service, so all scalability is managed in the backend. Users shouldn't worry about scalability itself, but they might need to consider if paid region support is needed or if other regions are available. Otherwise, scalability shouldn't be a concern for them.

But if you're configuring Cosmos DB in a non-Azure solution, you'd have to manage scalability yourself. In that case, you'd have to be more conscious about it.

We have dedicated technical support in India for each Azure service, including Cosmos DB. Since I provide the framework, design, and initial implementation, I'm involved in most calls to ensure everything is deployed as designed. 

But for any issues or troubleshooting, there's dedicated support that gets involved and fixes them. I also stay engaged with the product team.

The product team is very proactive.

Positive

I predominantly work on Microsoft SQL Database, among others. Sometimes, we use Cosmos DB for specific adaptations or APIs within Azure.

We've also assisted some customers in migrating from MongoDB to Cosmos DB.

If you're familiar with it, it's not complex at all. But for someone new, it can be a little tricky.

Cosmos DB itself is a cloud-based solution. However, I'm currently working primarily with a hybrid solution: Azure Stack HCI with software-defined networking for the environment.

We don't directly deploy Cosmos DB itself; it's a service within Azure. We use our DevOps pipeline to deploy the entire environment, which includes the application, database, environment (including the virtual network), and any connected service endpoints. 

Everything gets incorporated into the provisioning source or the DevOps pipeline and then deployed from there. It's a pretty streamlined process for us.

If the cost is affordable and you're looking for a managed service for unstructured data, I would definitely recommend using Cosmos DB from Azure. It also has seamless migration options from MongoDB, MySQL, and others. 

So, a managed service is the best way to go if the cost is affordable.

Overall, I would rate the solution a seven out of ten.