Amazon DocumentDB Reviews

Our primary use case for Amazon DocumentDB is to leverage its NoSQL flexibility and high availability for managing large-scale, mission-critical applications. Compared to Amazon RDS, which I previously used, DocumentDB provides a more seamless migration path with minimal downtime through AWS DMS or one-time migrations using mongodump and mongorestore.

The environment supports MongoDB compatibility (versions 4.0, 5.0, 6.0) and integrates easily with multiple drivers, including Node.js, Python, and Java. It also enables advanced features such as capped collections, secure cluster-level end-to-end encryption, and fine-grained index management for optimized query performance.

From an availability and disaster recovery standpoint, DocumentDB supports multi-AZ deployments, cross-region replication, and configurable continuous backup retention, ensuring resilience in production environments. With auto-scaling up to 128 TB storage, it is well-suited for data-intensive industries such as banking, where workloads involve inserting and retrieving millions of documents with millisecond-level query response times—a significant improvement over traditional RDS performance.

While relational databases (SQL Server, Oracle, PostgreSQL, MySQL, Aurora MySQL) rely on structured schemas with tables, procedures, and keys, DocumentDB, as with other NoSQL databases like MongoDB, CouchDB, and Cassandra, operates with databases, collections, documents, and fields, offering greater schema flexibility. Indexing strategies are crucial, as high index memory usage can impact performance; therefore, careful index design and tuning are applied.

In my previous role at UBS, I implemented and migrated over 30 MongoDB clusters to Amazon DocumentDB, addressing SSL/TLS vulnerabilities, setting up secure connections, designing and optimizing indexes, and automating projects using tools such as Alteryx and DataIQ. This demonstrated DocumentDB’s suitability for highly regulated sectors (e.g., US, Canadian, and Swiss banking) that demand security, scalability, and compliance.

Amazon DocumentDB has significantly improved our organization by reducing operational overhead and enhancing scalability. Previously, we relied on relational database services (RDS) that required more effort for schema changes, maintenance, and performance optimization. With DocumentDB’s MongoDB compatibility and flexible schema design, development teams can iterate faster and adapt to changing business requirements without major database redesigns.

The platform’s multi-AZ deployment, cross-region replication, and automated backups have strengthened our disaster recovery strategy, minimizing downtime and ensuring data durability. Its ability to auto-scale up to 128 TB of storage has allowed us to handle high-volume workloads—such as ingesting and querying millions of documents daily—while maintaining millisecond-level response times, something we struggled to achieve with traditional RDS instances.

Security and compliance have also improved through end-to-end encryption, SSL/TLS enforcement, and integration with IAM, which are essential in regulated industries like banking. Migrating over 30 MongoDB clusters to DocumentDB streamlined our environment, reduced licensing and infrastructure complexity, and enabled automation with tools like Alteryx and DataIQ, driving both cost savings and operational efficiency.

Overall, Amazon DocumentDB has given our teams the ability to focus more on innovation and analytics rather than database management, while meeting performance, scalability, and compliance requirements.

Over the past few months, I’ve been working closely with a managed database service, and a few features stood out as game changers for me and my team:

MongoDB Compatibility – The seamless migration experience was a huge win. No need to rewrite code or change drivers, which meant less friction and faster adoption for our developers.

Fully Managed Service – Patching, backups, and monitoring are all automated. This freed up our team to focus on building applications instead of managing infrastructure.

Separation of Compute & Storage – The flexibility to scale compute and storage independently gave us both cost savings and better performance optimization.

Multi-AZ High Availability – Automatic failover and cross-AZ replication gave us peace of mind with improved uptime and disaster recovery.

Performance at Scale – Even with large datasets, performance has remained consistent. Read replicas and efficient indexing have been especially valuable for read-heavy workloads.

Security – End-to-end encryption, VPC isolation, and IAM integration made enterprise-level security feel straightforward and reliable.

Backup & Recovery – Point-in-time recovery with automated backups made data protection effortless.

Improvements for Amazon DocumentDB could focus on enhancing high availability, sharding methods, replication techniques, and automatic failover in case the primary goes down, as continuous backup is an excellent option for disaster recovery. Overall, it offers good performance for all processes, with faster operations, high scalability, flexibility, and minimal schema requirements.

I have been using Amazon DocumentDB for almost three years now, and I am a MongoDB expert.

The support team from Amazon provides 24/7 service, making it a strong cloud platform compared to others. If there are any issues, Amazon arranges calls, and customers can send emails or raise query tickets directly for guidance.

They provide comprehensive information on all services, and before getting in touch with Amazon, we analyze our requirements to estimate costs based on our needs, including infrastructure decisions. Amazon has numerous services available such as RDS, Amazon DocumentDB, CloudWatch, EC2, Lambda, and Athena, and we can analyze and estimate costs tied to our desired CPU and memory utilization. Following this, we can consult with Amazon specialists who guide us through the entire process.

Positive

I used to be a customer with Amazon, and my last company, Trianz, which I resigned from last month, partnered with Amazon for various projects including migration and architectural redesigns, which we delivered on time through Amazon.

I would recommend Amazon DocumentDB to others, as I am the only MongoDB and Amazon DocumentDB expert in my circle, with eight years of experience working in the field.

On a scale of 1-10, I rate Amazon DocumentDB an 8.

I support my customers with Amazon DocumentDB.

Amazon DocumentDB is a nice product when using it for smaller registers about websites or when tabular information is needed.

Yesterday, I attended to a customer at the end of my workday. This customer has a concentrated database where invoices, orders, bills, and all registers are concentrated on Amazon DocumentDB.

There are many benefits to using Amazon DocumentDB. For example, regarding the price, you can start with a small database and when you need more performance, you can grow the database. The administration is more straightforward because there aren't many administrative tasks. The administration requirements are very minimal. You can create it and when you need performance to grow, you can adjust accordingly. Additionally, developers using Amazon DocumentDB or MongoDB can specialize or gain expertise in creating queries for performance.

Amazon DocumentDB is a nice product when used for smaller registers about websites or when tabular information is needed. However, when you need more volume or more registers, it becomes complicated because the performance adjustments and tuning are challenging. It's very complicated because there aren't many parameters to adjust, and query optimization is difficult due to limited options. You only have methods and index creation available.

Many customers tell me, 'I don't have another way. I need to change the instance type or add another node.'

I believe this has been in use for one year, not more. Today, many customers use relational databases, and some customers use NoSQL databases for smaller database needs.

This client used a cluster with two nodes and implemented a scale-up solution. However, today this customer has realized that the financial needs or FinOps costs are very high. At this moment, they need to lower all instances to save money.

I work with Amazon support personnel and specific product owners, depending on the call. When I have a significant or complicated problem, I contact the engineers about specific products. In many cases, the first contact is satisfactory. I would rate the service as eight or nine points.

Positive

MongoDB is not used in this case, as the integration is using SQL Server and PostgreSQL, and the database integration is Amazon DocumentDB.

I work at an AWS partner company. When I have a specific problem, a major problem, or an unsolved problem, I access specialists who help me with application design, architecture design, or in some cases, help with improving FinOps for specific clients.

I am aware of Neptune but am not currently working with it. We have other customers who use Lake Formation, but I don't personally use this service.

Based on my experience, I rate Amazon DocumentDB an 8 out of 10.

We use Amazon DocumentDB; there are quite a few use cases we have solved with AWS components. The primary use case is that of a data lake, and we use S3 primarily for lake purposes, along with other services such as Lambda, SQS, and SNS. There is use of Amazon DocumentDB, but for a different use case, not the primary data lake use case.

Regarding Amazon DocumentDB, I have been working with it for approximately three to three and a half years.

One primary reason we chose Amazon DocumentDB on AWS is its ability to handle unstructured data, such as PDFs. There's a significant amount of user manuals and documentation related to operational handbooks that we upload into Amazon DocumentDB, and the primary purpose is to make those easily searchable.

Amazon DocumentDB has its strengths, and with the current implementation, the primary use case was to make search available.

We do not utilize Amazon DocumentDB's compatibility with MongoDB APIs because we do not have MongoDB in this client environment. There are current discussions about phasing out from AWS's Amazon DocumentDB offering and moving into Snowflake.

The primary driver for our planned switch to Snowflake is that this client has to work with large JSON objects, each between four to six GB, and the schema is very wide with substantial free text. The overall data set we're dealing with is close to 2.1 petabytes and is still growing. The current use case involves data pipelines that parse that JSON, attempting to bring some structure for analysts to query on top of it, but this process takes a lot of time and effort. The goal is to leverage Document AI for better handling of free text keywords and to summarize information for our analysts.

I have been working with Amazon DocumentDB for approximately three to three and a half years.

The deployment team for Amazon DocumentDB is separate from the infrastructure team. The infrastructure team handles provisioning and sets up environments once licensing is negotiated. On the deployment side, it involves individual data owners doing their development and going through a release process as part of the CRQ process, which includes multiple teams, not a single dedicated deployment team.

We have not had to test the data durability or recovery capabilities of Amazon DocumentDB with a disaster recovery scenario, so our experience has been theoretical. We have chosen AWS for its market promise of cross-zone replication and disaster recovery, but we have not had an urgent scenario to put that to the test.

While there are possible solutions, the main roadblock is the number of components involved. Amazon DocumentDB is good at what it is marketed for; it excels at indexing and storing JSONs natively. However, utilizing that data requires custom pipelines, making it less intuitive for business analysts who would need to know Python or Spark to analyze the data. The idea is to have a simpler interface that anyone can use to search effectively.

We have discussions and calls with AWS support three to four times a week, leading to mixed experiences based on the representatives. Some are knowledgeable and provide prompt responses, while others may take longer to address the issues, requiring deeper analysis or escalation.

Positive

Amazon DocumentDB has its strengths, and with the current implementation, the primary use case was to make search available.

I am not directly involved in the infrastructure setup of Amazon DocumentDB; there is a dedicated infrastructure team that handles all those aspects.

Analytics was not directly happening on top of Amazon DocumentDB; AWS serves primarily as our data lake. All our raw data gets structured and then pushed into Snowflake for analytics.

The pricing and licensing of Amazon DocumentDB is managed directly by the client team with the vendor, so I am not involved in that aspect.

We did not use encryption at rest because the data we write has already gone through pipelines and been tokenized, ensuring no PII or PCI data is in clear text when we persist it into Amazon DocumentDB. On a scale of one to ten, I would rate Amazon DocumentDB a seven out of ten.

We use it in a few ways. Sometimes it functions as a cache for quick lookups using scans. Other times, DocumentDB serves as a complete backend. For example, we built the entire backend of one of our healthcare applications for Sweden using DocumentDB. We store patient records, medical information... everything runs on DocumentDB.

Its speed has had the most significant impact on our projects. For starters, we used it for its flexibility. With DocumentDB, you're not tied to a rigid structure like you are with Aurora or other relational databases. This makes it great for startups. 

When we work with established systems where the structure is well-defined, the speed of DocumentDB becomes the most important factor.

Compared to a relational database, scaling DocumentDB is easier because of its ability to replicate data across different instances. If you use a network-based storage service with your cluster, the primary instance doesn't even need a full local copy of the data, since it's accessible on the shared storage. That definitely contributes to scalability. 

AWS-managed services already handle a lot of the scaling complexity. We don't have to do anything. 

One possible improvement could be a hybrid database solution, where parts of the application leverage a relational database alongside DocumentDB. If a system were heavily relational in nature, a database like PostgreSQL might be a good fit. 

However, it depends on the client's specific needs. We might use the document capabilities of DocumentDB for lookups. But, if the application is likely to evolve over time and benefits from full document database functionality, that would influence the choice. 

I have been using it for four to five years now. 

It's been quite stable. We've encountered a couple of issues with Aurora, but not with DocumentDB.

The customer service and support team's response time is the most important factor. Ideally, we shouldn't need to contact them frequently for major issues. However, when we do need support, having a responsive team that can quickly analyze and work to resolve the issue is definitely valuable. 

As an engineer, I understand that technical issues may not always have predefined SLAs. Keeping communication open is important, but resolution timelines can depend on the specific nature of the problem.

We've had a couple of billing-related issues that were eventually resolved, but our experience with their technical support has been positive.

Positive

We use Aurora and sometimes DocumentDB along with DynamoDB

The initial setup is pretty straightforward. For the database itself, it's usually just the structure we need to deploy, which is handled on the software side. 

Our most complex deployments take around 20 to 30 minutes. Simpler ones can be done in just a few minutes.

The specific DocumentDB implementation we use is on the expensive side. We tend to use it strategically in complex systems, primarily for lookup capabilities. For simpler use cases, we often choose MongoDB as a more cost-effective solution.

I would definitely recommend using this solution. The people I usually discuss this with have some technical background. We start by analyzing their requirements, which helps determine whether DocumentDB is a good fit compared to a relational database, graph database, or other options. 

The type of data their application will handle is the primary factor in selecting a database. Once we've decided on the type of database, then we discuss specific brands. 

For instance, we might choose MongoDB or another DocumentDB engine. Other factors, like the existing platform or the potential need for data migration, also play a role.

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

We use the tool for the middleware product we are developing.

Amazon DocumentDB is a simple solution. It is easy to implement. We did not face many issues because we implemented it during the initial stages of the project. The integration is fine.

The technical support could be improved.

I have been using the solution for two to three years.

The scalability is okay. We do not face any problems. I rate the scalability an eight out of ten.

The support is good. Whenever we approach Amazon for any support, we get good responses. Our issues get resolved.

Positive

We used MongoDB before. We switched to Amazon DocumentDB because of its ease of operation.

The implementation was straightforward. We did the deployment within a single maintenance window. We kept a standby, made a replica, and deployed it to the existing database. It is easy to configure the solution.

I do not have any complaints about the product. We faced some difficulties while setting up some network connections. Multiple parties were involved, so it took some time to get resolved. I will recommend the product to others. It is straightforward and easy to implement. My recommendation depends on the organization and its needs. Overall, I rate the tool an eight out of ten.

When you're checking documents, for example, from ID cards or a driver's license, for example, it's personalized, yet there aren't different schemas. The solution helps with having a dynamic and perfect read in order to do document review.

The solution is reasonably priced.

It's a pretty scalable option. Even if there are many requests, you can just scale up very well.

The product is fast and easy to use. I've been really happy with it so far.

There are great tools on offer for monitoring and in order to optimize a query.

Troubleshooting and maintenance are very easy to do with this solution.

Migrations are easy using this product.

It offers very good documentation in general.

There's a bit of a learning curve at the beginning. However, once you learn the product, you understand it much better and it becomes easier to work with.

If you have many instances, many technical components in different regions, for example, one in France, one somewhere else, you don't need to build a YPO VPC. We call pre-work and you can connect with Amazon Document DB in the same instance. If you need to create in other ones, you need to build in the same thing or you need to build a replication of Document DB on it.

I'd like them to develop a graphical user interface where I can see how much of the solution I'm using. For example, so I can gauge which queries I need to optimize. 

The solution is extremely stable. That's not a problem at all. You don't have bugs or glitches. It doesn't freeze or crash. It's reliable.

The product is fully scalable. You just manage, for example, how many instances you need at a maximum, and what type of instances you need. If you need megabyte trends, you manage that. It's more or less just a process of configuration. It's straightforward and simple.

We've never directly reached out to technical support. If you need to find answers to questions, they do have a forum. Typically, we just use Google and find out answers with a web search.

We didn't use a different solution previously. We knew we wanted to use Amazon, and therefore we chose this product immediately.

We found migration to be very straightforward. There's lots of great documentation to help us through the process.

The deployment is very easy to accomplish. It's pretty seamless and dynamic.

We handled the entire process in-house with our own team. We didn't need the assistance of resellers or integrators.

The pricing of the solution is pretty good. We don't find it to be too expensive.

We're not a partner or a reseller of the product. We're just a customer.

We're using the latest version of the solution.

I recommend the product. It's worked quite well for us.

Overall, I would rate the solution eight out of ten.