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.

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.'

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.

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. 

The technical support could be improved.