Amazon RDS Reviews

Our organization runs lean, and as a small business that means that each employee wears multiple hats. With Amazon Relational Database Service we are able to deploy, backup, migrate, and manage a vast array of database servers without the need for a full-time Database Administrator. Amazon makes things like failover and backups so easy, my 89-year-old grandmother could do it.

My organization uses Amazon Relational Database Service (RDS) to manage all of its Databases. The nice thing about RDS is you don't need to have a traditional Database Administrator on staff. Creating an instance of any of the many Database offerings (MySQL, Postgres, etc.) is as easy as a push of a button, and all the complexities around managing your data become very simple.

Amazon RDS is a great service for managing all of your relational database services in a simple manner. In our shift to data analytics and a cloud infrastructure for our applications, RDS was invaluable in providing consistent backend support for all of our applications, both small and large. Its ability to quickly hook up to any existing AWS infrastructure and replicate itself across multiple AZs meant that we could quickly adjust the availability and cost efficiency of an application's database as it scaled.

Currently, Amazon RDS is used as a data store for all the micro-services in my organization. It is particularly suitable because, in a very loosely coupled micro-services landscape, none of the services need a complex table structure and limited data redundancy is tolerated. Hence, a medium instance of RDS is more than capable of servicing our production-grade micro-services without the maintenance cost of an on-premise RDBMS.

Amazon Relational Database Service is used by our Development team to centrally host data that our customers create using our application. Our customers are all within North America. Our application can use either MySQL or Amazon's Aurora, interchangeably. Amazon's RDS tools allowed us to quickly move from a distributed application with local databases on each customer's PC, to a SaaS model with multi-tenancy.

Amazon RDS is our core database platform. It is used for both development and production loads, throughout the company. RDS provides us with a full-featured database without the cost of managing the server or installation.

We started recently using Amazon Relational Database service in our company. We are exploring the usage and trying to utilize it at the maximum level. Still we are in the learning phase. Presently we are using Amazon Relational Database service in building reports, Analyzing the data in different ways. As I said earlier still we are in the learning phase as of now we are in good shape.

My organization has, since the beginning, utilized RDS as our transactional, day-to-day database, at first staging all incoming data in a PostgreSQL. Although it has performed so well that it now handles all of our data warehousing and has handled our heaviest queries with enviable aplomb. We had initially staged data in RDS for migration into Redshift, but have determined that running well-optimized queries on our particular volume of data--certainly not the petabytes that would justify Redshift--our PostrgreSQL database on RDS is actually more performant.

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.

We are using Amazon Relational Database Service to provide various managed database clusters, enabling us to have our data replicated to multiple availability zones, in addition to nightly backups, and managed updates without downtime. Since Amazon Relational Database Service supports MySQL and MariaDB, we are able to use RDS without changes to our platform, removing vendor lock-in.

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

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.

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!