Truly fully-managed: Database made easyhttps://www.trustradius.com/relational-databasesAmazon Relational Database ServiceUnspecified8.8941012019-09-27T21:00:44.356Z
September 27, 2019
Truly fully-managed: Database made easy
Score 10 out of 101
Overall Satisfaction with Amazon Relational Database Service
We use AWS RDS to manage our MySQL and PostgreSQL databases without having to worry about issues like replication error, hardware failure or logs(general, slow, error) analysis. It is being used primarily by the database team but indirectly a lot of teams use RDS. Since RDS manages a lot of tasks for us, it frees us to focus on the business side of things.
- Create snapshots on schedule or whenever required: RDS gives you the freedom to take manual snapshots at will or configure a backup policy wherein you can specify the time when the backup would be taken and the number of such automated backups to retain. You can restore a backup very easily whenever required with a few clicks.
- Monitoring: RDS comes with a lot of metrics like CPU utilization, free storage, freeable memory and read/write latency that you can create alarms on to make sure you can quickly resolve an issue.
- Failover: If you have a multi-AZ RDS set-up, failover is done automatically when the primary instance fails. This minimizes downtime
- Point-in-time-restore: With RDS, you can sort of time travel, creating a new instance and restoring the database state to a point in time in the past.
- Logs: The general, slow, error and audit logs can be published to CloudWatch for better analysis with a few clicks.
- There should be a proper listing of all parameter groups alongside the instances that they are attached to. This would help to see which instances would be affected if a parameter group is changed.
- RDS should allow SUPER privilege to the master user. A few advanced tasks(like getting a physical backup using MySQL Enterprise Backup) fail because SUPER privilege is not available for the master user.
- A few parameters are not modifiable in the parameter groups and the access to the server filesystem is not given. This should not be the case because as an advanced user, you might want to understand things a little deeper.
- RDS has made sure that we don't spend a lot of time resolving issues that are not even remotely relevant to our business use-cases. It has thus made the life of DB administrators easy which allows them to explore other avenues as well.
- Using RDS for around 10 years now, we have never had an issue BECAUSE of RDS. It is a very reliable service.
As a POC, we had worked with Azure and GCP's databases as well. One problem with Azure is that it seems slow in supporting new versions of MySQL. With GCP Cloud SQL, the security configuration for the database was not as intuitive as in AWS. The UI in both Azure and GCP was better than RDS as it avoids page reloads when you are navigating through different components, and instead opens the linked component in the same page and makes the page horizontally scrollable as well. Still, we went with RDS because a lot of our services were already in AWS and we did not have a solid reason to go against it.
AWS has always been very prompt in responding to support tickets and follow-up questions. With RDS too, we never felt that the support that AWS provided was not good enough.
Do you think Amazon Relational Database Service delivers good value for the price?
Are you happy with Amazon Relational Database Service's feature set?
Did Amazon Relational Database Service live up to sales and marketing promises?
Did implementation of Amazon Relational Database Service go as expected?
Would you buy Amazon Relational Database Service again?
For a general-purpose workload, RDS is a perfect fit and works really well and takes care of a lot of stuff for you (replication, security, monitoring, scaling, storage, publishing logs to CloudWatch). If you have a read-intensive load though, you should probably think of switching to a NoSQL database service like DocumentDB or DynamoDB.