PostgreSQL on AWS RDS vs Self-Managed: The Trade-offs

The Real Question Isn’t Cost

When you land your Oracle database on PostgreSQL, the next decision is where it runs: a managed service like Amazon RDS, or PostgreSQL you install and run yourself on EC2 (or on-prem). People frame this as a cost debate, but the honest framing is control vs. operational burden. RDS trades some control for a lot less work. Whether that trade is right depends on your team and your workload, not on a spreadsheet alone.

What RDS Actually Does for You

• Automated backups & PITR — snapshots and WAL archiving configured for you.
• Multi-AZ failover — a standby in another availability zone with automatic promotion.
• Minor-version patching — in a maintenance window you choose.
• Read replicas — provisioned with a few clicks.
• Metrics & monitoring — CloudWatch, Performance Insights, Enhanced Monitoring.

For a small team, that is a full-time DBA’s worth of undifferentiated work handled by the platform. That is the actual value — not the instance price.

What You Give Up

RDS is PostgreSQL with the sharp edges filed off — and a few doors locked. You do not get a superuser or OS shell. You cannot install arbitrary extensions, only the ones AWS allows (a long list, but not every extension). You cannot touch postgresql.conf directly — you set parameters through parameter groups, and a handful are simply not exposed. Custom C extensions, non-approved shared_preload_libraries, and certain low-level tuning are off the table.

For most Oracle-to-PostgreSQL workloads none of that matters. It starts to matter if you rely on an exotic extension, need OS-level access for a specialised agent, or want a filesystem-level backup tool of your own choosing.

When Self-Managed Wins

• You need extensions RDS doesn’t allow — or a specific PostgreSQL fork/version.
• You have real DBA depth in-house — and the control pays off.
• Regulatory / data-residency constraints that a managed service can’t satisfy.
• Cost at very large scale — a big fleet self-managed on reserved instances can undercut RDS, if you can staff it.
• You want tools like pgBackRest and Patroni under your own control.

The Honest Default

For the vast majority of teams migrating off Oracle, start on RDS. The operational features you would otherwise build by hand — HA, backups, PITR, patching — are exactly the things that are easy to get wrong and painful to get wrong in production. Move to self-managed only when you hit a concrete wall RDS can’t clear, and you have the people to own the result. “We might need control someday” is not that wall.

One caveat worth knowing: RDS runs community PostgreSQL, so your data and SQL stay 100% portable. If you later outgrow it — in either direction — you can move without a rewrite. That is not true of every managed option, which is exactly the Aurora question we take up next.