Amazon RDS

What running a database actually involves

Choosing a database is a small part of using one. Operating it is the larger part, and it is continuous.

A server has to be provisioned and sized. The operating system and the database need patching, including for security issues that arrive on their own schedule. Backups must be configured, run and, critically, tested for restoration. Failover has to be arranged and verified. Storage fills and must be extended. Monitoring must exist and someone must respond to it.

None of this is about the application. It is the cost of having a database at all, and it recurs indefinitely.

Amazon RDS takes on this work while leaving the database itself standard.

Standard engines

The distinguishing characteristic is that the engines are the ordinary ones.

PostgreSQL on RDS is PostgreSQL. MySQL is MySQL. The same applies to MariaDB, Oracle and SQL Server.

This matters for two practical reasons.

Applications generally connect without modification. Drivers, SQL and tooling work as they do anywhere, because it is the same engine.

And knowledge transfers. Someone who knows how to tune PostgreSQL knows how to tune this. The techniques, the documentation and the community experience apply.

The trade is that some host level access and configuration is not available, since the service operates the database and that requires it to control certain things. The documentation sets out which parameters can be changed and which operations are restricted.

Backups that exist by default

Automated backups run on a schedule with a retention period, supporting restoration to a point within that period. Snapshots can also be taken deliberately and kept.

The significance is that this is on rather than being something to build.

A great many self managed databases have backups that were configured once, have been failing quietly for months, and have never been restored from. The failure is discovered at the worst possible moment.

Backups performed by the service are not exempt from needing verification, and the practice of actually testing a restore remains worthwhile. But the default position, backups existing and being retained, is considerably better than a process that depends on someone having built it and kept it working.

Two different copies for two different purposes

RDS offers standby instances and read replicas, and confusing them is common.

A standby is a synchronised copy in another availability zone. Its purpose is availability. If the primary becomes unavailable, the standby takes over. It does not serve queries, so it adds no capacity.

A read replica serves read queries. Its purpose is spreading load, so that reporting or read heavy traffic does not compete with the primary. Replication to it is asynchronous, so it may be slightly behind.

The distinction is availability against capacity. Many deployments want both, for different reasons, and adding one does not provide what the other does.

Changing size

Instance size and storage are adjusted through the service.

This changes what capacity planning means. Rather than procuring hardware months in advance, an instance is resized when the evidence says it should be.

Two qualifications are worth noting. Resizing generally involves an interruption or a failover, so it is not free of impact. And a larger instance costs more continuously, which makes ongoing size an ongoing cost decision rather than a one time purchase.

Who uses it

Amazon RDS is used by application teams and platform teams running on AWS. It is a common destination when moving databases off self managed servers, because the engine stays the same and the operational work moves to the provider.

Points to consider

RDS is an AWS service. The official documentation is the reference for supported engines, versions, instance types and features, all of which change over time.

Managed does not mean unattended. Query performance, index design, schema decisions and capacity all remain the responsibility of whoever owns the application. The service operates the database; it does not make it fast.

Version support has a lifecycle. Engine versions reach end of support and upgrades become necessary, which is planned work rather than something the service absorbs entirely.

Cost is continuous and depends on instance size, storage, backup retention and data transfer. An oversized instance costs every hour it runs, which makes right sizing an ongoing exercise rather than a decision made once.

Getting started

The official documentation covers engines, instance classes, backups, standbys and replicas. Creating a small instance of a familiar engine and connecting an existing application to it shows how little usually has to change, which is the most useful thing to establish early.