Through the use of the API, the log files can be downloaded for analysis with tools such as pgBadger. This does mean a secondary system is required still for log analysis, but a very small, inexpensive EC2 instance can easily provide this capability.
Benchmarking
The biggest concern most DBAs have for write-intensive applications is IOPS (Input/Output Operations Per Second). Just like EC2 instances, provisioned IOPS is available for RDS and highly recommended for reliable database performance. A minimum size of m1.large is highly recommended if this is used, and scaling this feature is as easy as choosing the option from a menu. Benchmarking even the minimal IOPS setting of 1000 has shown impressive results for a cloud-backed RDMS. Adding the Multi-AZ option seems only to have about a 5% detrimental impact on the benchmarking numbers, so unless you’re really strapped for performance and can’t upgrade your instance type or IOPS, it is highly recommended that you have Multi-AZ enabled.
$ pgbench -h testingrds.cqrcyb3h2bq2.us-east-1.rds.amazonaws.com -c 10 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 100
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 100/100
tps = 12.851974 (including connections establishing)
tps = 24.087639 (excluding connections establishing)
$ pgbench -h testingrds.cqrcyb3h2bq2.us-east-1.rds.amazonaws.com -c 20 -T 600 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 100
query mode: simple
number of clients: 20
number of threads: 1
duration: 600 s
number of transactions actually processed: 28543
tps = 47.544892 (including connections establishing)
tps = 48.227472 (excluding connections establishing)
pgbench -h testingrds.cqrcyb3h2bq2.us-east-1.rds.amazonaws.com -c 100 -T 600 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 100
query mode: simple
number of clients: 100
number of threads: 1
duration: 600 s
number of transactions actually processed: 112009
tps = 186.482602 (including connections establishing)
tps = 199.764921 (excluding connections establishing
Challenges
As with any SaaS system, when you allow a third-party to have control of the core of your software, it erodes your ability to control exactly how everything works.
One item that stands out is the length of time it took even a minor upgrade to be available within RDS. PostgreSQL RDS debuted with version 9.3.1 and it took more than a month for 9.3.2 to be available. If you look at the release notes for this minor version, there were some very important internal bug fixes. Of even more concern would be something like the security bug that was fixed in 9.2.4--without immediate patching this leaves the system vulnerable to malicious data loss. And even with 9.3.2 out, it’s not the default choice when making a new instance. It is hoped that these are just growing pains, and future minor releases will be available sooner after release and are made the default choice.