Senior Principal at a hospitality company with 10,001+ employees
Real User
Top 20
Aug 11, 2025
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.
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.'
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.
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.
Amazon DocumentDB (with MongoDB compatibility) is a fast, scalable, highly available, and fully managed document database service that supports MongoDB workloads.
Amazon DocumentDB is designed from the ground-up to give you the performance, scalability, and availability you need when operating mission-critical MongoDB workloads at scale. In Amazon DocumentDB, the storage and compute are decoupled, allowing each to scale independently, and you can increase the read capacity to millions of...
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.
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.'
The technical support could be improved.
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.
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.