Oracle DBA to PostgreSQL
The Oracle DBA’s Guide to Surviving (and Thriving) in AWS RDS PostgreSQL
A practical field guide for experienced Oracle professionals moving from RAC, RMAN, and operating-system control to managed PostgreSQL in the AWS cloud.
1. Introduction: The Language of the Cloud
For those of us who have spent decades in the trenches of Oracle E-Business Suite, managing RAC nodes, reviewing AWR reports, and wrestling with RMAN scripts, moving to PostgreSQL on Amazon RDS can feel like learning a new dialect of a language we already speak fluently.
The grammar remains familiar. We still think about memory, storage, transactions, execution plans, availability, recovery, security, and performance. But the daily rituals have changed.
The most fundamental shift is the AWS Shared Responsibility Model. AWS manages the physical infrastructure and many routine platform tasks, while the customer remains responsible for data, access, schema design, configuration choices, SQL performance, monitoring, and recovery readiness.
In simple terms, your job moves from managing the entire server stack to managing the database service boundary.
2. Takeaway 1: You No Longer Own the “Metal” — and That Is a Good Thing
In the on-premises Oracle world, root access and SSH access often felt like a DBA birthright. In Amazon RDS, that boundary is intentionally fixed. AWS manages the underlying host, operating system, database software installation, infrastructure replacement, and many patching and backup activities.
You manage the database-facing layer: schemas, roles, privileges, extensions, parameter groups, option choices, maintenance windows, queries, indexes, statistics, monitoring, and application connectivity.
As a senior architect, I see this as a strategic trade-off. You lose the ability to tune the kernel or inspect every operating-system process, but you gain time to focus on architecture, security, automation, cost, SQL efficiency, and business continuity.
Amazon RDS removes much of the undifferentiated infrastructure work so the DBA can spend more time improving the reliability and value of the data platform.
Success in RDS depends on knowing which controls AWS exposes, which settings require a parameter group, which changes require a reboot, and which parts of the platform are intentionally managed for you.
3. Takeaway 2: The Storage Trap — It Only Goes One Way
Oracle DBAs are accustomed to adding data files, resizing tablespaces, moving segments, reclaiming space, and reorganizing storage. Amazon RDS storage behaves differently: allocated storage can be increased, but it cannot be reduced on the existing DB instance.
If you allocate far more capacity than required, you continue paying for that allocation unless you migrate or restore the database into a differently sized replacement environment.
FreeStorageSpace, and alert well before the
database reaches a critical storage condition.
Storage autoscaling is valuable, but it should not replace capacity planning. Unexpected growth can result from table bloat, retained WAL, large temporary operations, failed maintenance, excessive logging, or an application defect.
The experienced DBA’s storage principle is straightforward: start with justified capacity, monitor aggressively, and grow deliberately.
4. Takeaway 3: Rethinking the Architecture — Undo vs. MVCC
This is one of the largest conceptual changes for an Oracle veteran. Oracle maintains older versions of changed data using Undo. PostgreSQL implements Multi-Version Concurrency Control by retaining row versions within the table structure.
When rows are updated or deleted, older row versions can remain as
dead tuples until PostgreSQL reclaims or marks that space reusable.
This makes VACUUM and autovacuum central to PostgreSQL health.
Poorly tuned autovacuum can lead to table and index bloat, inaccurate optimizer statistics, degraded query performance, and increased storage consumption. In an extreme case, failure to control transaction ID age can create a transaction ID wraparound risk.
Memory starting points — not universal rules
-
shared_buffers: Around 25% of RAM is a common initial guideline for a dedicated PostgreSQL host, but the final value must be tested. -
effective_cache_size: Often estimated near 50–75% of RAM as a planner hint; it does not reserve that memory. -
work_mem: Treat with caution because it can be allocated multiple times per query and across many concurrent sessions. -
maintenance_work_mem: Size for maintenance operations while considering concurrent autovacuum workers.
The important lesson is not to copy a memory formula blindly. Build a total memory budget based on instance RAM, connection count, query concurrency, parallelism, maintenance activity, and operating overhead.
In PostgreSQL, autovacuum is not housekeeping. It is part of the core availability and performance architecture.
5. Takeaway 4: Multi-AZ Is Primarily for Availability — Not Automatically for Read Scaling
Oracle DBAs may associate standby databases with both disaster recovery and reporting, especially when Active Data Guard is part of the architecture. In Amazon RDS, high availability and read scaling depend on the deployment type.
| RDS Option | Primary Purpose | Readable? | Replication Model |
|---|---|---|---|
| Multi-AZ DB instance deployment | High availability and automatic failover | No — the standby does not serve read traffic | Synchronous |
| Multi-AZ DB cluster | High availability with two readable standby instances | Yes | Synchronous replication to standbys |
| Read replica | Read scaling, reporting, and selected recovery patterns | Yes | Asynchronous |
A traditional Multi-AZ DB instance deployment usually fails over in approximately 60–120 seconds, depending on database activity and recovery conditions. A Multi-AZ DB cluster is designed for faster failover, which AWS describes as typically under 35 seconds.
Choose the architecture based on recovery objectives, workload characteristics, read requirements, cost, regional strategy, and application retry behavior—not simply because “Multi-AZ” appears in the name.
6. Takeaway 5: The PITR Catch — Recovery Creates a New Instance
Point-in-Time Recovery in Amazon RDS is operationally simple, but it includes an important design reality: the restore creates a new DB instance. It does not rewind the existing production instance in place.
That new instance requires validation and may require the reapplication or verification of infrastructure settings and integrations surrounding the database.
Your recovery runbook should verify:
- DB subnet group and network placement
- VPC security groups and routing
- DB parameter group and required static parameters
- KMS encryption configuration
- IAM database authentication and application roles
- Secrets Manager entries and connection strings
- CloudWatch alarms, log exports, and monitoring settings
- DNS, application endpoints, and failback steps
- Post-restore validation of data, users, extensions, and jobs
A recovery procedure you have never executed is only a document. Test PITR and application reconnection regularly.
A quarterly recovery exercise is a practical starting point for critical systems, but the frequency should be driven by compliance requirements and the business recovery-time and recovery-point objectives.
7. Takeaway 6: The Connection Crisis and the RDS Proxy Option
PostgreSQL uses a process-based connection model, and a large number of active or rapidly created sessions can consume significant memory and CPU. This becomes especially important with microservices, containers, bursty workloads, and AWS Lambda functions.
The first defense is good application-side connection management. Use persistent pools,
define sensible timeouts, close abandoned sessions, and avoid setting
max_connections to an unnecessarily high value.
Amazon RDS Proxy is strongly worth evaluating for workloads with frequent connection churn or unpredictable spikes. It pools and reuses database connections, helps protect the database from connection storms, and can preserve many application connections during failover events.
8. Takeaway 7: Graviton — A High-Value Cost and Performance Opportunity
AWS Graviton-powered RDS instance families use Arm-based processors and are available
in several general-purpose and memory-optimized classes, including instance names with
a g suffix such as db.m7g and db.r7g.
For many standard PostgreSQL workloads, Graviton can provide attractive price-performance. It should be included in the default evaluation for new deployments, but it should not be selected only from a marketing percentage.
Benchmark your actual workload, verify extension compatibility, compare CPU utilization, query latency, I/O behavior, throughput, and licensing or tooling dependencies, and then make the decision using measured cost per transaction.
Graviton is not a magic switch. It is a strong architectural option that deserves workload-based testing.
9. Conclusion: The Platform Changes, the Craft Remains
The tools change. SIDs become managed instances. RAC architecture becomes an RDS availability design. RMAN scripts become automated backups and snapshots. SSH access disappears. Parameter files become parameter groups. Operating-system troubleshooting becomes service-level observability.
Yet the core discipline of the DBA remains essential. SQL tuning, indexing, statistics, capacity planning, security, monitoring, recovery validation, and calm incident management still determine whether a system is reliable.
The best Oracle DBAs do not become less valuable in a managed database service. They become more focused. Their attention moves away from repetitive infrastructure work and toward engineering decisions that directly affect performance, resilience, security, and cost.
The platform changes; the craft does not.
Are you ready to stop managing servers and start optimizing the data platform that drives your business?
Official References
- Amazon RDS User Guide — Overview
- Managing capacity with RDS storage autoscaling
- Configuring and managing RDS Multi-AZ deployments
- Restoring an RDS DB instance to a specified time
- Amazon RDS Proxy
- Amazon RDS DB instance classes
- PostgreSQL documentation — Routine vacuuming
- PostgreSQL documentation — Resource consumption