3.3 Managed relational databases

What this is and why it exists

A managed database service takes the parts of running a database that are tedious and unforgiving — installation, patching, backups, failover — and does them for you. What it does not take is the part that actually causes outages: your schema, your queries, your connections and your restore plan. This lesson draws that line clearly, because assuming the provider owns something they do not is how a Tuesday becomes a very long night.

The vocabulary

• Managed database — the provider runs the engine; you use it. Amazon offers RDS and Aurora, Azure offers Azure Database for PostgreSQL and MySQL and SQL Database, Google offers Cloud SQL and AlloyDB.
• Engine version — which release of PostgreSQL, MySQL or SQL Server you are on; the provider offers versions and eventually retires them.
• Maintenance window — a stated period in which the provider may apply updates that need a restart.
• Backup — an automatic copy taken on a schedule and retained for a stated number of days.
• Point-in-time recovery — restoring to any moment inside the retention period, not only to a backup's timestamp.
• Read replica — a copy that receives changes from the primary and serves read queries.
• Failover — promoting a standby to primary when the primary fails.
• Connection pooler — a component that keeps a small set of database connections and lends them to many clients.

The mental model

Draw the line first. Theirs: the machine, the operating system, the engine binaries, patching, taking backups, and, if you configured it, the failover. Yours: the schema, the indexes, the queries, the number of connections your application opens, whether the backups can actually be restored, and whether the failover has ever been tested. Nearly every managed-database incident lands on the second list.

Versions and maintenance are the routine part with a sharp edge. The provider updates minor versions inside your maintenance window, which usually means a short restart — so the window should sit where a restart is survivable, and your application should reconnect rather than fall over when its connection drops. Major versions are your decision until they are not: engines reach end of support, and the provider will eventually upgrade you or stop supporting the version. The habit worth building is to know your engine's version and its support horizon, and to have upgraded once in a non-production copy before it becomes urgent.

Backups deserve the same sentence as snapshots did: they are not a backup until you have restored one. Automatic backups plus point-in-time recovery is a strong combination, because it means the question "can we go back to 14:35, the minute before the bad migration ran" has a yes. But two things are worth checking rather than assuming — how long the retention period actually is, and how long a restore of your data size actually takes. Both are numbers, both are knowable in an afternoon, and neither is the number people guess.

Replicas and failover solve different problems and are constantly confused. A read replica exists to take read load off the primary; it lags behind by some amount, which means a read straight after a write can return the old value, and application code that does not expect this produces bugs nobody can reproduce. A multi-zone deployment with a standby exists for availability: the standby takes over when the primary fails, and the switch is a short interruption during which connections break and must be re-established. If you take one thing: a replica is not a backup and a backup is not a replica. The replica faithfully copies your accidental deletion within seconds.

Then the classic outage, which is worth knowing before it happens to you. Every database has a hard limit on concurrent connections, and each connection costs real memory. Modern application platforms scale out — more containers, more serverless invocations — and each new copy opens its own connections, so an application that scales in response to traffic can exhaust the database's connection limit at exactly the moment it is busiest. The failure looks like the database rejecting everyone. The fix is a connection pooler between the application and the database, so hundreds of clients share a small number of real connections, plus a look at whether each application copy really needs the number it opens by default.

What you should now be able to explain or do

State which responsibilities the provider takes and which stay yours. Explain what happens in a maintenance window and what your application must do to survive it. Describe point-in-time recovery and name the two numbers to verify rather than assume. Give the difference between a read replica and a standby, and one bug that replica lag causes. Explain the too-many-connections outage end to end, and name the fix.

Check yourself