1. Decision Definition Surface decision The stated decision is whether the SaaS application should continue running PostgreSQL on a self-managed virtual machine or migrate the database to Amazon RDS for PostgreSQL. Real engineering decision The real decision is whether the team should continue owning the database infrastructure and operational failure modes themselves, or transfer a meaningful portion of that operational responsibility to a managed PostgreSQL service while preserving required availability, recovery, performance, deployment, compatibility, and operational control. The database itself is not currently described as the primary performance problem. The evidence instead points to increasing operational ownership cost: maintenance, patching, backups, and failover are consuming engineering capacity. The objective is therefore not simply "move PostgreSQL to AWS." It is to achieve reliable database operations with a four-developer team, while preserving predictable application behavior and avoiding an unjustified architectural commitment. The decision horizon should be treated as multi-year rather than merely the migration event. At 900 GB and approximately 120 GB/month growth, the database will add roughly 1.44 TB over the next 12 months if that growth rate remains constant. That makes operational scalability and storage-management practices relevant to the decision. The critical requirements are: Requirement Decision significance High availability Must be demonstrated rather than assumed Automated backups Explicit requirement Point-in-time recovery Explicit requirement Low-downtime deployments Explicit requirement Predictable performance Explicit requirement Limited DBA capacity Strongly affects operational model Existing AWS footprint Reduces infrastructure-boundary complexity Acceptable current performance Migration is not justified by performance alone 900 GB database Makes migration planning materially significant ~120 GB/month growth Makes capacity and storage planning important The secondary decisions include PostgreSQL version selection, instance/storage configuration, Multi-AZ architecture, backup retention, monitoring, maintenance windows, migration mechanism, rollback strategy, connection management, security controls, extension compatibility, and future read-scaling requirements. 2. Constraints and Evidence Evidence classification Classification Finding -Confirmed Database is approximately 900 GB -Confirmed Database growth is approximately 120 GB/month -Confirmed Application requires high availability -Confirmed Automated backups are required -Confirmed Point-in-time recovery is required -Confirmed Low-downtime deployments are required -Confirmed Predictable database performance is required -Confirmed Team consists of four developers -Confirmed There is no dedicated DBA -Confirmed Application already primarily runs on AWS -Confirmed Current production performance is acceptable -Confirmed Database maintenance, patching, backups, and failover consume increasing engineering time -Strong inference Operational ownership rather than database performance is the principal driver of the decision -Strong inference A managed service could reduce the amount of infrastructure-specific database administration owned by the engineering team -Strong inference Continuing self-management will require the team to retain responsibility for HA, backup correctness, patching, failover procedures, monitoring, and recovery testing -Possible RDS could reduce operational workload materially -Possible RDS configuration or service limitations could introduce new operational constraints -Unknown Current PostgreSQL major/minor version -Unknown Installed extensions and whether all are supported by the target RDS version -Unknown Current VM topology and storage architecture -Unknown Actual RPO and RTO targets -Unknown Current backup and restore performance -Unknown Current HA/failover architecture -Unknown Peak CPU, memory, I/O, connection, transaction, and latency characteristics -Unknown Application dependency on superuser-level PostgreSQL capabilities -Unknown Custom PostgreSQL configuration or operating-system-level integrations -Unknown Required maintenance-window constraints -Unknown Current database encryption, networking, IAM, secrets, and compliance requirements -Unknown Migration downtime tolerance -Unknown Application behavior during connection endpoint changes -Unknown Total cost of the current VM-based architecture versus the proposed RDS configuration Amazon RDS for PostgreSQL provides DB snapshots, backups, point-in-time restores, Multi-AZ deployments, read replicas, and VPC deployment options. Those capabilities directly correspond to several stated requirements, although their suitability still depends on the application's actual RPO/RTO and workload. RDS also supports PostgreSQL extensions, but extension availability and supported versions must be checked against the application's actual inventory rather than assumed. The most important evidence gap is therefore database compatibility and operational-target validation, not whether RDS generally provides database-management capabilities. 3. Option Architecture Option A — Continue self-managed PostgreSQL on the VM The existing architecture remains largely intact. The engineering team continues to own PostgreSQL installation, configuration, operating-system maintenance, storage, backups, replication or HA mechanisms, failover procedures, monitoring, patching, recovery testing, and capacity planning. This preserves maximum PostgreSQL and operating-system control and minimizes migration risk because there is no immediate database migration. The disadvantage is that the existing operational problem remains structurally present. The team has no dedicated DBA, while the database is growing substantially and the operational burden is already increasing. This option therefore solves migration risk by accepting continued operational ownership. Option B — Migrate to Amazon RDS for PostgreSQL The application continues using PostgreSQL, but the database infrastructure becomes an RDS-managed resource. A production architecture could use a Multi-AZ RDS deployment, automated backups and PITR, AWS-native monitoring, controlled maintenance windows, appropriate storage configuration, and application connectivity through the RDS endpoint. RDS supports Multi-AZ deployments, backups, point-in-time restores and read replicas for PostgreSQL. This directly addresses the operational areas currently consuming engineering time, but it does not eliminate database engineering. Query tuning, schema design, indexes, connection management, capacity planning, migrations, observability, and application/database compatibility remain engineering responsibilities. RDS also introduces provider-specific constraints. PostgreSQL extensions must be checked for support, and some database administration capabilities differ from a self-managed PostgreSQL installation. Option C — Incrementally improve the existing self-managed architecture before deciding This is the materially different lower-risk alternative. Instead of immediately migrating, the team could first quantify the existing operational burden and strengthen the current environment: validate backups through actual restores, automate patching where appropriate, test failover, improve monitoring, document recovery procedures, and establish measurable RPO/RTO targets. This does not remove the underlying ownership burden, but it can determine whether the problem is primarily poor automation or whether the organization genuinely needs a managed database service. This option is especially valuable as a decision-validation phase, rather than necessarily being the final architecture. 4. Feasibility and Technical Analysis Dimension Self-managed VM Amazon RDS Incremental hardening Existing compatibility High Requires validation High PostgreSQL control Highest Reduced Highest Operational burden Remains high Potentially reduced Reduced only partially HA responsibility Team-owned Managed infrastructure capability, configuration remains important Team-owned Backup responsibility Team-owned Service-supported, configuration and restore validation remain required Team-owned PITR Must be engineered and tested Supported Must be engineered and tested Patching Team-owned Service-managed mechanisms Mostly team-owned Performance tuning Team-owned Team-owned Team-owned OS-level control Highest Reduced Highest Extension flexibility Highest Must verify support Highest Migration risk None immediately Material Minimal AWS integration Already present Natural fit Existing Reversibility High from current state Requires migration back if needed High DBA dependence Remains a concern Potentially reduced Remains Long-term operational scaling Requires continued investment Better aligned with managed operations Requires continued investment Self-managed VM Classification: Viable with conditions. It is technically feasible and avoids migration risk. However, the stated operational problem remains. Continuing with this architecture is most defensible if the organization values infrastructure control enough to justify retaining database operations, or if technical requirements prevent RDS adoption. The critical weakness is organizational rather than purely technical: four developers without a dedicated DBA are currently absorbing increasing operational database responsibilities. Amazon RDS Classification: Appropriate with conditions; requires validation before production commitment. RDS maps directly to several explicit requirements. AWS documents support for automated database backups, point-in-time restores, Multi-AZ deployments and other PostgreSQL capabilities. It also provides mechanisms that can support lower-disruption database maintenance. RDS Blue/Green Deployments allow a production environment to be replicated into a separate environment for testing and subsequent switchover; AWS documents typical switchover times of under a minute, although actual application behavior must be validated rather than inferred from that service-level capability. However, Blue/Green is not a universal solution. AWS documents PostgreSQL-specific replication and configuration limitations, including restrictions involving logical replication, unlogged tables, foreign data wrappers and replication slots under certain configurations. Therefore, RDS appears architecturally aligned with the stated problem, but compatibility evidence must precede migration. Incremental hardening Classification: Appropriate as a validation stage; not demonstrated as a complete solution. It can establish whether the operational burden can be reduced enough without changing the database platform. If it cannot, the evidence for RDS becomes stronger. 5. Risk and Failure Analysis Failure mode Cause/trigger Impact Detection Primary mitigation Migration incompatibility Unsupported extension/configuration Migration failure or application defects Compatibility inventory and staging migration Validate before commitment Insufficient RDS capacity Incorrect sizing or workload assumptions Latency or throughput degradation Performance monitoring/load tests Baseline and load-test Failed recovery Backup exists but restore process is untested Extended outage/data loss Restore drills Regular restore testing Failover incompatibility Application mishandles database reconnection Application outage during failover Controlled failover test Connection/retry validation Migration downtime exceeds target Large database and insufficient replication strategy Production outage Full-scale rehearsal Measure actual cutover Extension limitation Application depends on unsupported capability Feature failure Extension inventory Replace, redesign, or reject RDS Configuration drift Production configuration differs from tested configuration Unpredictable behavior Configuration comparison Infrastructure-as-code Connection exhaustion Application creates excessive connections Database unavailable to application Connection metrics Pooling and limits Storage growth 120 GB/month continues or accelerates Capacity pressure Storage monitoring Capacity thresholds and autoscaling where appropriate Provider dependency RDS-specific configuration becomes embedded More difficult future migration Architecture review Keep application/database contracts portable where practical Maintenance event Engine or infrastructure maintenance Temporary disruption AWS events/monitoring Maintenance planning and failover testing Rollback failure New environment diverges or data changes after cutover Extended incident Migration rehearsal Defined rollback window and procedure Security misconfiguration Network/IAM/security-group error Unauthorized access or outage Security review and monitoring Least privilege and private networking Cost growth Larger instance/storage/IO requirements Budget pressure Cost monitoring Budget thresholds and capacity reviews The most important risk is not "RDS might be slower." Current evidence does not indicate that performance is the primary problem. The more material risks are compatibility, migration correctness, failover behavior, recovery validation, and loss of operational control over capabilities currently available on the VM. 6. Trade-Offs and Hidden Costs The self-managed option has a deceptively low migration cost because there is no migration. Its hidden cost is continuing ownership. Every additional PostgreSQL version update, storage expansion, backup-system change, failover exercise, security patch, recovery test, and infrastructure incident consumes engineering attention. RDS reverses that trade-off. The migration becomes the major near-term engineering project, while some ongoing infrastructure responsibilities move into the managed-service boundary. The RDS trade-off is therefore not "less work everywhere." It is: less infrastructure ownership in exchange for service constraints, AWS dependency, configuration discipline, and migration effort. RDS storage autoscaling can help accommodate growth, but storage can be increased automatically rather than automatically reduced, so capacity decisions still need to be managed. Read replicas can provide read scaling, but they are not automatically added or removed based on demand. The team should therefore avoid treating "managed" as synonymous with "maintenance-free." 7. Reversibility and Lock-In Self-managed VM Reversibility is comparatively high because the organization controls the PostgreSQL installation, filesystem, operating system, replication configuration and database environment. The downside is that preserving maximum reversibility also preserves maximum operational responsibility. RDS RDS introduces AWS-specific operational coupling. The application still communicates with PostgreSQL using standard PostgreSQL interfaces, which helps preserve portability at the application/database protocol level, but infrastructure configuration becomes AWS-specific. The most important commitment points are: First: adopting RDS-specific extensions, parameter behavior, operational workflows, or infrastructure integrations. Second: designing deployment and recovery processes around RDS-specific features. Third: allowing the database architecture to depend heavily on AWS-only capabilities. Fourth: accumulating migration complexity around replicas, integrations, extensions, or other provider-specific components. A safeguard is to keep the application dependent primarily on standard PostgreSQL behavior and treat RDS-specific capabilities as infrastructure enhancements rather than application assumptions wherever practical. 8. Decision Conditions Self-managed becomes appropriate when The application requires PostgreSQL capabilities that RDS cannot provide, the team requires operating-system-level database control, existing HA/backup automation can be demonstrated to meet the required RPO/RTO, or the organization deliberately accepts the ongoing operational burden. Self-managed becomes inappropriate when Operational database work continues consuming material engineering capacity without a strategic reason to retain it, recovery and failover cannot be regularly demonstrated, or the team cannot sustainably operate the required HA and backup architecture. RDS becomes appropriate when The complete PostgreSQL extension/configuration inventory is compatible, measured performance meets requirements, application failover behavior is correct, migration testing demonstrates acceptable downtime, recovery testing meets RPO/RTO, and the resulting operational model materially reduces infrastructure ownership. RDS becomes inappropriate when Required PostgreSQL capabilities are unsupported, critical workloads cannot meet performance requirements, migration risk cannot be controlled, or RDS-specific constraints conflict with non-negotiable architectural requirements. The incremental approach remains appropriate when The team lacks sufficient evidence to make the migration safely, particularly if current backup, restore, failover, workload, extension, or RPO/RTO behavior has not been measured. 9. Validation Plan The highest-information, lowest-risk validation sequence is: Validation Measure/Test Expected signal Failure signal Decision consequence PostgreSQL inventory Version, extensions, parameters, roles, jobs, FDWs, custom integrations Everything has an RDS-compatible path Unsupported or materially constrained dependency Resolve dependency or reconsider RDS Workload baseline CPU, memory, I/O, latency, connections, throughput, query patterns Stable measurable baseline Unknown or highly variable workload Improve observability before migration Backup/recovery test Restore current VM backup into isolated environment Recovery succeeds within target Restore failure or excessive recovery time Fix recovery architecture first RDS compatibility test Restore representative database into RDS Application functions correctly Extension/configuration/application failure Remediate or reject RDS Performance test Run representative workload against RDS Meets existing performance baseline and target Material regression Resize/reconfigure or reconsider Failover test Controlled RDS failover Application reconnects within required target Persistent application errors Fix connection handling Migration rehearsal Full-scale migration using production-like data Cutover fits downtime target Excessive downtime or replication lag Change migration method Recovery test RDS PITR and restore Required recovery objective achieved Recovery target missed Change backup/recovery configuration Operational test Simulate alarms, maintenance, failure and recovery Team can operate system confidently Team lacks operational understanding Improve runbooks/training Cost validation Compare actual/estimated RDS resource configuration against current infrastructure and engineering overhead Economics are understood Material unanticipated cost Reassess architecture None of these validations should be represented as completed. They are proposed validation gates because the supplied evidence does not contain their results. 10. Implementation and Risk Mitigation If the validation gates succeed, the evidence-supported implementation path is a controlled migration to RDS for PostgreSQL rather than an immediate production cutover. Prerequisites Establish explicit RPO and RTO targets. Inventory PostgreSQL version, extensions, schemas, roles, parameters, scheduled jobs, foreign-data dependencies, logical replication, custom libraries, and application connection behavior. Establish a production performance baseline before changing infrastructure. Document the current backup, restore and failover process. Target architecture Use RDS for PostgreSQL within the application's existing AWS environment. Configure the database for the required availability model rather than assuming the default configuration satisfies the requirement. Configure automated backups and PITR according to the defined recovery objectives. Use encryption, private network placement, restrictive security groups, least-privilege database credentials, secrets management, logging, monitoring and alerting according to the application's security requirements. Use infrastructure-as-code where practical so that the database configuration is reproducible and reviewable. Migration Do not make the 900 GB database a one-shot migration experiment. First perform a production-like rehearsal. The migration process should establish a synchronized target, validate application behavior, measure replication/catch-up behavior, execute a controlled cutover, monitor the application, and retain a defined rollback strategy. The exact migration technology should be selected only after PostgreSQL version, workload, downtime target, and replication compatibility are known. Deployment and maintenance RDS Blue/Green Deployments can potentially support lower-disruption database changes, and AWS documents PostgreSQL support for the feature. However, the application's actual deployment workflow should be tested rather than assuming that the database service's documented switchover capability automatically satisfies the application's low-downtime requirement. Operational controls Create explicit alerts for storage, CPU, memory, connection saturation, I/O pressure, replication lag where applicable, backup failures, failed maintenance events, and application database errors. Create runbooks for failover, restore, PITR, credential rotation, capacity expansion, incident response, and rollback. Conduct periodic recovery exercises rather than treating backup configuration as proof of recoverability. 11. Revisit Triggers Trigger Assumption challenged RDS cannot support a required extension Compatibility assumption RDS workload materially underperforms baseline Performance assumption RDS cost becomes materially inconsistent with business constraints Economic assumption Required RPO/RTO cannot be achieved Recovery architecture assumption Failover causes unacceptable application disruption Application compatibility assumption Database growth materially accelerates Capacity assumption Read workload becomes substantially larger Scaling assumption PostgreSQL requires capabilities unavailable in RDS Platform-control assumption Operational burden remains high after migration Managed-service benefit assumption AWS dependency becomes strategically undesirable Lock-in assumption Regulatory/security requirements change Compliance assumption New architecture requires database-level infrastructure control Managed-service suitability assumption 12. Final Decision Analysis Decision Status READY WITH CONDITIONS The evidence is sufficiently strong to justify serious RDS evaluation and a migration-validation program, but not sufficient to authorize an irreversible production migration immediately. The reason is not uncertainty about whether RDS provides relevant managed PostgreSQL capabilities. AWS documents the required classes of capabilities, including backups, point-in-time restoration and Multi-AZ deployment. The unresolved question is whether this particular PostgreSQL installation and workload can use those capabilities without violating compatibility, performance, recovery, deployment, or operational requirements. Decision Summary The real decision is whether the four-person engineering team should continue owning increasingly burdensome database infrastructure or move that infrastructure responsibility into a managed PostgreSQL service. The strongest evidence supporting a change is the growing operational burden combined with the absence of a dedicated DBA. The strongest evidence against an immediate migration is the lack of information about PostgreSQL extensions, configuration, workload characteristics, RPO/RTO, migration behavior and application failover handling. Option Comparison Dimension Self-managed VM RDS for PostgreSQL Incremental hardening Operational ownership High Lower infrastructure ownership High Migration risk None Material Minimal HA capability Must be engineered Supported through RDS architecture Must be engineered Backup/PITR Team responsibility RDS-supported Team responsibility PostgreSQL control Maximum Reduced Maximum Team fit Increasingly challenging Better aligned with limited DBA capacity, subject to validation Still challenging AWS alignment Existing Strong Existing Compatibility risk Low Must be validated Low Long-term operational burden Likely remains significant Potentially reduced Reduced only through automation Reversibility High Moderate High Risk and Trade-Off Summary The central trade-off is operational ownership versus platform control. Self-managed PostgreSQL preserves control and avoids migration risk, but leaves the organization responsible for the operational burden that is already increasing. RDS can address several of those operational responsibilities, but introduces migration work, AWS-specific dependencies, service constraints, and the need to validate PostgreSQL compatibility. The highest-impact unresolved risks are extension/configuration compatibility, migration correctness, failover behavior, recovery performance, workload performance, and actual long-term operating cost. Validation Gates The migration should proceed only after five critical gates are satisfied: Gate 1 — Compatibility: all required PostgreSQL extensions, configuration, roles and integrations have a supported implementation. Gate 2 — Performance: representative RDS testing meets the application's measured performance requirements. Gate 3 — Recovery: backup restoration and PITR meet the defined RPO/RTO. Gate 4 — Availability: controlled failover produces acceptable application behavior. Gate 5 — Migration: a production-scale rehearsal demonstrates that the migration and cutover fit the permitted downtime and rollback requirements. Failure of any critical gate should trigger remediation or reconsideration rather than being waived merely to complete the migration. Execution Sequence 1. Establish explicit RPO, RTO, downtime and performance targets. 2. Inventory PostgreSQL version, extensions, parameters, integrations and application connection behavior. 3. Establish the current production performance and recovery baseline. 4. Test current backup restoration so that the existing system has a known recovery baseline. 5. Build a representative RDS environment. 6. Restore or replicate representative production data into RDS. 7. Execute compatibility, performance, failover and recovery tests. 8. Conduct a production-scale migration rehearsal. 9. Resolve failures before production commitment. 10. Execute a controlled production migration with monitoring and an explicit rollback window. 11. After migration, measure whether the original engineering-time problem actually decreased. Decision Conditions Continuing with self-managed PostgreSQL is justified if validation demonstrates that RDS cannot satisfy a non-negotiable technical requirement or if the organization deliberately values infrastructure control enough to retain the operational burden. Migrating to RDS is justified if compatibility, performance, recovery, failover and migration gates succeed and the resulting operating model materially reduces database infrastructure responsibility. The incremental hardening path should continue if evidence remains insufficient or if the team needs more operational data before making the platform commitment. Final Assessment The supplied evidence indicates that this is fundamentally an operational ownership decision rather than a database-performance decision. The current self-managed architecture is technically viable, but its operational cost is increasing while the organization has only four developers and no dedicated DBA. That makes continued infrastructure ownership a meaningful architectural consideration rather than merely a maintenance preference. RDS for PostgreSQL is technically aligned with several explicit requirements, including managed backups, point-in-time restoration and Multi-AZ capabilities. RDS also provides mechanisms for controlled database changes such as Blue/Green Deployments, although those mechanisms have PostgreSQL-specific limitations that must be checked against the actual system. The decisive evidence still missing is the actual PostgreSQL compatibility inventory, RPO/RTO requirements, workload baseline, failover behavior, migration characteristics and cost model. Therefore, the sound engineering action is not to migrate blindly and not to preserve the VM merely because it works today. The appropriate next step is a controlled validation program designed to determine whether RDS can satisfy the application's measured requirements while materially reducing the operational burden that motivated the decision in the first place.