Managed versus self-managed: what stays your responsibility · PostgreSQL

The question is not whether a managed service is better. It is which responsibilities move and which do not, because the ones that do not are most of this course.

What moves

Responsibility	Covered in	Managed service
Installation, packaging	Part II	Theirs
Minor version patching	Lesson XVII-05	Theirs, on their schedule
Hardware and storage failure	Part XVIII	Theirs
Replication mechanics	Part XIV	Theirs
Failover automation	Part XV	Theirs
Taking backups	Part XIII	Theirs
OS-level configuration	Parts II, XI	Theirs

That is a genuinely large amount of work, and for most teams it is worth paying for.

What does not move

Responsibility	Covered in	Still yours
Schema design and indexing	Part X	Yours
Query performance	Parts X, XVI	Yours
Lock contention and DDL	Parts IX, XVII	Yours
Vacuum behaviour and bloat	Parts VII, VIII	Yours
Connection management	Part IV	Yours
Knowing your RPO and RTO	Lesson XV-08	Yours
Testing that restores work	Lesson XIII-08	Yours
Deciding what to monitor	Part XVI	Yours
Security model and roles	Part V	Yours
Capacity planning	Lesson XVII-01	Yours

The provider takes backups. Only you can know they restore.

Every managed service takes backups and reports them successful. Lesson XIII-01 established, and lesson XIII-08 elaborated, that a successful backup job is not recovery capability.

The provider cannot know:

Whether your RPO is met, because they do not know what you need.
Whether the restore completes in your RTO, because that depends on your data volume and has to be measured.
Whether roles, extensions and configuration come back — lesson XIII-01 measured zero role definitions in a pg_dump.
Whether the restored database is one your application works against.

Restore into a scratch instance, on a schedule, and time it. On a managed service this is easier than anywhere else — restoring to a new instance is usually one API call — which removes the last excuse for not doing it.

What you lose

Not disadvantages exactly; things this course used that you will not have.

No superuser. You get a role with a subset of privileges. Some extensions cannot be installed, some settings cannot be changed, and some diagnostic functions are unavailable.

No shell. Everything in lesson XVI-06 — ps, /proc, vmstat, iostat — is gone. You lose the ability to distinguish “the database is slow” from “the host is swapping”, and lesson XI-06’s OOM investigation is not available to you.

No direct file access. No pg_checksums against a stopped cluster, no examining pg_wal, no du on a data directory.

Restricted configuration. Restart parameters are frequently fixed, and shared_preload_libraries may be a supported list rather than a setting.

Their upgrade schedule. Minor upgrades happen in their window. Major upgrades are available when they choose.

Logs through their interface, with their retention, and often without log_line_prefix under your control.

The questions that actually distinguish providers

Not “do you do backups” — everyone says yes.

What is the measured restore time for a database of my size? Not the backup window. The restore.

Can I perform a point-in-time recovery myself, to an arbitrary second, without opening a ticket? And how long does it take?

What is the failover time, measured, and what triggers it? Lesson XV-05’s arithmetic applies to their stack too.

Which extensions are available, at which versions? This decides whether pg_stat_statements from lesson XVI-05 is even an option.

What monitoring do I get, and can I query the statistics views directly? Everything in Part XVI depends on the answer.

How much notice before a forced minor upgrade?

What happens when my disk fills? Lesson XVII-02 is a very different incident when you cannot log in.

Ask these before choosing, and note that a provider who cannot answer the first two has not measured them either.

Applying this course to a managed cluster

Most of it still applies, because most of it is about PostgreSQL rather than about the host.

Parts VI to XII — storage, MVCC, vacuum, locks, planner, memory, WAL — are unchanged. Every measurement in them was about PostgreSQL’s behaviour.
Part XIII’s concepts apply; the mechanics are the provider’s.
Part XVI’s statistics views are available; the OS correlation in lesson XVI-06 is not.
Part XVII’s DDL and capacity lessons apply exactly.

What changes is the toolbox, not the subject.

Why a managed service cannot fix the things that actually break

Look back at what caused the failures measured in this course, and ask which a provider could have prevented.

A held snapshot bloating a table from 1.7 MB to 19 MB — lesson VII-05. That is an application holding a transaction open. No provider prevents it, and their monitoring is less likely to surface it than yours.

A waiting ALTER TABLE blocking every query behind it — lesson XVII-04. Application and migration behaviour.

A read replica serving stale data to a read-your-writes pattern — lesson XIV-08. Application design.

Eleven of sixteen backends queued on one row’s lock — lesson XVI-04. Data model.

work_mem set so that concurrent sorts exhausted memory — lesson XI-03. Configuration you still own, on a host you cannot see.

A DROP TABLE replicated to every standby in milliseconds — lesson XIV-01. Recoverable only from a backup, restored to a point in time you have to choose.

Every one of those is above the line a managed service draws. The service removes the failures that come from operating the software — which are real, and which are the minority of incidents on a mature system.

There is a second-order effect worth naming. Because the provider handles the visible operational work, teams on managed services frequently have less database expertise, not more, and meet these failures with fewer people who can diagnose them. The service raises the floor and does nothing for the ceiling, and the incidents that remain are the ones that most need someone who understands what is happening.

That is the argument for this course being just as relevant on a managed service as on a host you own — and for the parts you cannot practise there being the ones worth practising somewhere else.

What to take from this

Managed services take installation, patching, hardware, replication mechanics, failover and backup execution.
They do not take schema, queries, locks, vacuum, connections, RPO/RTO, restore testing, monitoring choices, security or capacity.
They take backups. Only you can know they restore. Restore to a scratch instance on a schedule.
You lose superuser, shell access, file access, some configuration and control of the upgrade schedule.
Parts VI to XII apply unchanged; the OS correlation does not.
The failures measured in this course are almost all above the line a provider draws.

Cross-course references

Kubernetes for Production Sysadmins — Part CII (Managed versus self-managed Kubernetes) covers the identical decision one layer up, including the responsibilities that never transfer.
Linux for Production Sysadmins — Part LXXVII (Linux in the cloud) covers what the provider operates and what remains yours.
Observability for Production Sysadmins — Part LIX (Database observability) covers the instruments a managed service exposes, which is usually a subset and is the constraint that matters most.