Amazon RDS Reviews

We use RDS to run all the databases to run our platform for both OLTP and analytics/reporting purposes. This includes traditional PostgresSQL Aurora PostgeSQL. and Aurora MySQL implementations.

Amazon RDS is one of the primary data stores for all applications in our organisation. We also use AWS DynamoDB, Elastic Search, Redis etc apart from RDS. We preferred RDS over other DBaaS because it's a part of AWS which is highly reliable and scalable, and it is a completely managed solution which is simple, easy to use and also offers advanced features required by DevOps team.

Our company has a cloud-first and AWS first strategy that includes creating and moving databases to the public cloud. We started this journey seriously about 2 years ago and have decided to use RDS services as often as possible, instead of using EC2 instances for our database environments. While our footprint in the public cloud is still a small part of our overall compute, we are finding that RDS is meeting our database needs are we are migrating and creating new ones. RDS is not only solving issues for the operations of our business, we are also using RDS as part of our overall data lake strategy.

We use amazon RDS to offload database systems from the primary server stack. This is particularly useful for us in 2 scenarios:

1. You are running server clusters and the database needs to be external to those clusters for consistency.
2. You are operating some shared services and need to sandbox a particular set of data or application.

We use Amazon RDS as the backing data store for our various microservices as well as the utilities that manage service scheduling and system availability. Our primary databases are configured with Postgres, but our management utilities use MySQL under the hood. In production, we also use a high-availability configuration with automated failover to a backup system. This is all to say we use RDS extensively in our organization and the reliability of the platform provides both us and our customers with piece of mind.

RDS manages replication if databases are in multiple-avaliable zones.

Amazon RDS holds and manages data for our core operations. We accept somewhat sensitive data: PII, but nothing PCI-protected. The well-vetted security of the service, along with its outstanding configurability, make it a perfect option for maintaining trust with our clients. RDS easily upgrades when we need to scale and was seemingly built with the expectation that it would fit neatly into an event-driven architecture. Automatic backups, read replication, everything is exceptional. I'm trying to think of a complaint or drawback, but I can't.

As a part of the shift in the organization from moving away from Oracle to open-source systems, we started developing micro services. The micro service architecture emphasizes on small sized databases and APIs that control access to the data. So in the pre-micro service era where we have one monolith DB that's managed by Infrastructure teams, the new architecture demands new DBs. Traditionally speaking, spawning new robust and production ready databases used to be difficult. For developers, it involves procurement of hardware, connecting it to the network, installing new DB software, setting up robust backup scripts for the data; which is a lot of work. Amazon RDS offers SaaS to replace the above work, making it super easy for a developer to spawn a new instance by filling up a short form and clicking a button.

We use Amazon RDS very heavily in our company. It's being used by the database management team most of the times, however, to interact with the service we often try to write APIs to access the database. Currently, the main business problem it overcomes is the problem of scaling and adding new hardware, if we are running out of space. We don't really need to worry about buying new hardware, we just increase the size without any issues.

Amazon Relational Database Service (RDS) hosts a Postgres instance that we send our production MongoDB data into. We then use metabase (http://www.metabase.com/) on top of RDS for analytics. MongoDB hosts all our production data and is the source of truth, but we copy that data into RDS because most of our non-technical staff are not proficient with MongoDB's aggregation framework and because we don't want to risk an errant query hurting our production database's performance.

We use RDS (MySQL and Postgres) for important production systems in our backend data systems. It solves the problem of not having to maintain (patch, upgrade, clean) an installation of our databases, freeing up our DBA resources to work on more important things. Further, it is fast, easily scalable, and very reliable.

I support a lot of clients that have AWS, and a large amount of them rely upon the free-tier of services. I think the free tier is an awesome offer by AWS, but the services included, especially EC-2, are fairly under-powered, and are really designed for educational use. The average WordPress user trying to gt free hosting by using the free tier of EC2 is going to run into huge problems very fast. These sites bog down quite a bit very quickly after going live, especially on AWS, since unlike BlueMix and Softlayer, an EC2 processor is not even an entire physical core (based on my readings and test). I am an AWS consulting partner, and I get these exact types of clients reaching out to me a lot. They see people running nice sites on the free tier, but they just can't get it to work. RDS is the biggest secret weapon, and the first one I use each time. When you deploy a LAMP on EC2, forget the M. RDS is a specialized AWS database system, but to keep it simple, it is a ready-to-go, point-and-click MySQL server. Yes, you can run your web database on RDS, and offload resources, freeing up some of that 512 MB of ram, and single partial core processor to focus on serving websites and PHP requests. Honestly, RDS should be an essential service for every LAMP deployment you do on AWS. It not only removes the load from a low-powered server, but offers incredibly simple administration, has automatic back-up and restoration services, offers additional availability, and is a great way of being CMS ready for migrating your site to AWS CloudFront.

We used Amazon Relational Database Service to administer an SQL Server versus hosting it on site. This was a project aimed at testing functionality for a highly available failover HL7 system. It met our expectations for managing the database for this application. When we were finished with this Proof of Concept project we decided the latency was too great at the moment and would wait for improved infrastructure improvements to the AWS Cloud. The best part of the whole exercise is that we were able to terminate the instance and only run it while we were testing. No major infrastructure investment was required other than the time we used the instance.

We use it as a backend for web applications running in AWS. Using RDS over traditional database servers eliminates much of the administration overhead while providing easy and reliable backups and replication.

We use Amazon ealational Database Service as a backend for a handful of internal applications. The advantages of using a PaaS RDBMS are many. Amazon handles backups, patching and upgrades. And since we use multi availability zone deployments, uptime is not a concern either. Are there downsides? Sure. We would like to see the option to keep backups longer than 30 days. There are workarounds, but we would rather it be built into the product. Another potential downside is the lack of control over upgrades. While this is almost always a good thing, there are cases where a legacy schema may depend on an older version.

All in all Amazon Relational Database Service is a great service. No complaints!