We use the solution to emulate MongoDB for the document database.
The easiest route - we'll conduct a 15 minute phone interview and write up the review for you.
Use our online form to submit your review. It's quick and you can post anonymously.
We use the solution to emulate MongoDB for the document database.
The solution is useful for storing JSON documents. DynamoDB is a platform as a service. We don't have to administer the tool. We did not face any challenges while integrating the product with other services.
We use the document database. The primary key is quite slow. The free tier is quite hard to use.
I have worked with the tool for three years.
The tool is stable.
We are satisfied with the scalability of the tool.
The deployment is quite easy. The deployment takes a minute. We need only one engineer to install the solution.
The ROI is very good at the beginning. However, it gets expensive if we use it a lot.
I rate the pricing a six out of ten.
DynamoDB and Cosmos DB are more or less the same. My preference depends on the cloud I am working on. However, I prefer Cosmos DB because I have used it more.
Overall, I rate the product 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.
