Share your experience using Amazon Timestream

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 have enabled a state-locking mechanism in Terraform, so we store our keys in DynamoDB. 

If the database is kept running continuously, extra costs will be incurred. This particular area needs enhancement.

I rate the platform's stability a nine out of ten.

I rate the platform's scalability a nine out of ten.

The technical support team is always available to help us.

Positive

I worked with MongoDB and Firebase earlier. I switched to DynamoDB because of the company and client requirements. Atlassian and Google already own the other two services. I used MongoDB for a machine learning project and Firebase for an Android-level project.

The initial setup process is easy.

I have yet to use DynamoDB for real-time data processing in my applications. However, in Terraform, we utilized it to create multiple infrastructures. Terraform has a state-locking feature, which prevents simultaneous data updates from multiple users. For example, triggering a data update one minute before you do will lock your access until my update is completed. We implemented this feature for telco data monitoring purposes.

Data modeling in DynamoDB is simple and easy to use in our cases. You have primary and secondary tables, and then you can easily model the data. Whatever you use to access the non-structural data is how you get the storage, i.e., API gateways, workflows, and microservices that need to communicate with each other. This is where the database comes into the picture.

I advise others to be thoughtful and careful when using the platform because if you keep the database running continuously, it might cost you a lot of money. 

I recommend Amazon DynamoDB to others and rate it a nine out of ten.