For small to medium volume apps it's quite good. The security configuration out of the box is quite good. All standard options like changing pgsql port, opening it up to only your main dB instance is supported.
If needs once a week downtime for half an hour for patches. But if you use multi AZ deployment with 2 instances it does this without any actual downtime. Automatically manages the failover for you.
Provisioned IOPS are very expensive. For small loads use bigger general purposes SSD say 100 to 200gb and it works OK. The IOPS are burstable so it works out OK.
I don't know about RDS psql, but RDS mysql multi-AZ does have up to 2 mins downtime when switching masters. We see that when scaling up our staging for loadtesting.
I agree on the IOPS - just get a larger disk (min 100G) even if you'll never use it. Storage is cheap. It's supposed to give you 3k IOPS but doesn't actually give you anywhere near that (but it is still fast). If you do need guaranteed IOPS, then it's wallet-opening time.
I haven't tried for a while - my method for outage detection was simply trying to make a connection. It wasn't always 2 min, but usually somewhere between 1-2 min (never more, though).
> The Amazon RDS maintenance window is your opportunity to control when DB Instance modifications (such as scaling DB Instance class) and software patching occur, in the event they are requested or required. If a maintenance event is scheduled for a given week, it will be initiated and completed at some point during the maintenance window you identify. Maintenance windows are 30 minutes in duration.
The only maintenance events that require Amazon RDS to take your DB Instance offline are scale compute operations (which generally take only a few minutes from start-to-finish) or required software patching. Required patching is automatically scheduled only for patches that are security and durability related. Such patching occurs infrequently (typically once every few months) and should seldom require more than a fraction of your maintenance window. If you do not specify a preferred weekly maintenance window when creating your DB Instance, a 30 minute default value is assigned. If you wish to modify when maintenance is performed on your behalf, you can do so by modifying your DB Instance in the AWS Management Console, the ModifyDBInstance API or the modify-db-instance command. Each of your DB Instances can have different preferred maintenance windows, if you so choose.
Running your DB Instance as a Multi-AZ deployment can further reduce the impact of a maintenance event. Please refer to the Amazon RDS User Guide for more information on maintenance operations.
It's frustrating that AWS doesn't offer something ideal for databases. Databases should be run with fast local storage, on reliable dedicated hardware. VM instances on shared hardware that may be retired at short notice aren't ideal.
We (databaselabs.io) did some customer dev tests for that exact product (databases with fast local hardware storage.) We found that almost all customers didn't care about getting that level of performance (enough to pay for it, anyway.) For ~99%, cloud-level shared storage is all they'll pay for. Finding the other 1% is a very expensive long-cycle sales and marketing proposition, so we decided to market cloud solutions to the 99%.
That said, we are equipped to run the 'fast dedicated hardware' solution (we come from a managed services background) -- just write me, pjlegato at databaselabs.io, and I'll get you set up.
If needs once a week downtime for half an hour for patches. But if you use multi AZ deployment with 2 instances it does this without any actual downtime. Automatically manages the failover for you.
Provisioned IOPS are very expensive. For small loads use bigger general purposes SSD say 100 to 200gb and it works OK. The IOPS are burstable so it works out OK.