Managed Postgres, and What It Takes Away

Everything in the operations half of this book can be bought. Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL Flexible Server, Supabase and Crunchy Bridge all run Postgres and do the backups, the standby, the patching and the dashboards on your behalf, and Neon does the same on a storage layer it wrote itself. For most teams it is plainly a good deal, so the interesting question is the other one: which parts of the preceding thirteen chapters it actually covers.

The line is clean enough to write down. A provider takes over the work of Chapters 12 and 13: scheduled base backups, point-in-time recovery, a standby promoted without anyone being woken, minor-version patching, storage that grows, and metrics you did not instrument. It does not take over row versions and dead tuples, autovacuum thresholds on a 40-million-row table, the planner's estimates and the first-Saturday slowdown, index design, the lock queue behind an ALTER TABLE, or the fact that 400 connections still need a pooler. Everything on the second list stays yours, with less visibility into it than Nadia has today.

What You Actually Buy

Concretely: automated base backups with a retention window and a point-in-time restore that is a console form rather than a procedure somebody has to remember; a standby in another availability zone with automatic promotion and a DNS name that follows it; minor releases applied inside a maintenance window; storage that expands without a resize outage; slow-query and wait-event dashboards; and a support contract with an on-call rotation whose actual job is to answer. For a team without a database specialist that is two chapters delivered on the first afternoon.

It is worth being honest about how good that trade usually is. The work a provider assumes is the kind that is only noticed when it was not done, and it is the work under-resourced teams skip first. An unrestored backup and an unpractised failover are both hypotheses. Buying them as a product moves the problems to people who run them at scale and get paged about them professionally, several times a week, on other people's clusters.

What Is Taken Away

There is no superuser. On RDS the master account is a member of rds_superuser, an elevated but bounded role, and the other providers have their own equivalent; anything that genuinely requires superuser is not available to you. There is no host access either, which removes a whole category of the diagnostics this book has been teaching: no listing the data directory, no tail on the log file, no strace, no offline utilities. Chapter 5's tour of base/16384 is a tour you can no longer take.

Configuration goes through the provider's own parameter store. Many settings are exposed, some are fixed, some are computed from the instance size, and a few of the ones this book treated as decisions are simply not yours to make. That is a real constraint on Chapter 10's baseline rather than an inconvenience. Extensions are a supported list per provider and per major version. New majors arrive months after the community release, which turns the previous topic's upgrade planning into a waiting exercise. And the provider's own limits, meaning connection ceilings and IOPS quotas and a maintenance window they choose, become numbers your design fits rather than numbers you pick.

SELECT name FROM pg_available_extensions ORDER BY 1;

SELECT name, setting, context FROM pg_settings
 WHERE context = 'postmaster';      -- needs a restart; who schedules it?

SHOW is_superuser;                    -- expect: off

Those three queries take a minute and answer most of what a comparison table leaves out. The first is the definitive extension list for that provider on that version, which is not the marketing page and not last year's. The second finds the parameters that need a restart to change, because on a managed instance a restart is a request rather than a command, and the latency of that request is worth knowing before an incident needs one. The third tells you which of your existing scripts stop working on day one.

Aurora, AlloyDB, and the Forks

Aurora PostgreSQL and AlloyDB are not stock Postgres, and treating them as if they were is the most expensive misunderstanding in this topic. Both replace the storage layer with a distributed service that the compute nodes share; AlloyDB's own documentation describes a disaggregated architecture where compute and storage scale independently, and Aurora is built on the same idea. The SQL surface is compatible; the operational surface is not.

In practice that splits this book cleanly in two. The developer-facing half, meaning the type system, schema design, constraints, the SQL and how a query gets planned, transfers to a fork without a footnote. The internals half transfers as concepts and not as numbers: a row is still a version and dead tuples still accumulate, but checkpoint behaviour, what a replica costs, how far one lags and how long a promotion takes are the fork's own engineering. Anything you were about to predict from Chapters 12 and 13 has to be read from their documentation instead. Pricing diverges as sharply, since these bill consumed storage and I/O rather than a disk you provisioned.

What Does Not Change

The list is long. Postgres still never overwrites a row, so every update leaves debris and every table needs that debris cleaned up. Autovacuum still starts at a fraction of the table's size, which on orders still means millions of dead tuples before the first worker moves. The planner still prices plans from estimates, so the first Saturday of the month still skews the statistics on orders and still flips a hash join into a nested loop that reads three hundred thousand rows to return twenty-one. No provider's monitoring has an opinion about that plan. Which indexes exist is your decision, and so is which ones cost writes without earning a read. A migration still takes a lock and still forms a queue. And a connection still costs a process, which is the reason every provider sells a proxy.

The sharper version is that all of it now happens with fewer instruments. No filesystem to inspect, log retention set by somebody else, some of the previous topic's extensions unavailable, and a diagnosis that arrives as a graph in a console rather than a query you wrote and can modify. A bloat problem on a managed instance is the same bloat problem with less light on it, and that half of the trade appears in no comparison table.

Choosing, With Numbers

The honest comparison is total cost of ownership, and both sides have to be filled in. On one side: the instance, the storage, the proxy, the cross-zone traffic, the support tier, and the higher unit price at scale that everyone eventually notices. On the other: engineer-hours, a pager rotation that needs three people to be humane, both rehearsals, and the risk carried by a failover nobody has practised. A two-person startup should be managed and should stop debating it. A team with a database specialist, a hard cost ceiling at volume, or a dependency on an extension no provider carries has a real case for running it themselves, and that case is tested by whether the restore rehearsal is on a calendar with a date on it.

Before committing, verify five things in writing: the supported extension list for the exact major version, which parameters are settable and which need a provider-scheduled restart, the connection ceiling and whether the proxy is priced separately, how long after a community release a new major arrives, and whether point-in-time recovery restores in place or into a new instance, the last of which changes the shape of the incident and not only its length. All five are answerable in an afternoon on a trial instance.

Cartwheel's Verdict

Cartwheel would be well served by a managed instance: a primary, a read replica for the dashboard, an external pooler, and the four roles this chapter finally separated. The backup and failover work of the last two chapters is worth handing over at Cartwheel's size, the minor upgrades stop being a scheduling argument, and the trust line in pg_hba.conf would never have existed to find. It is the right answer, and it is available today.

None of it would have found why checkout went from 40 ms to 6 seconds on the first Saturday of the month, or how inventory came to occupy 900 MB holding 12,000 rows, or which of two customers got the last box of strawberries. A provider will run the server. It will not read the plan, choose the index, size the vacuum, decide what a transaction is entitled to see, or notice that a sequence has consumed 63% of its ceiling. That is the half of the job that stayed with Nadia through every chapter of this book, and it is the half that is still yours after everything else has been handed to somebody else's on-call rotation. None of it has to be guesswork any more, which is the only thing fourteen chapters can honestly buy you.