Database connections, replicas, retention, engines, and migration economics

Connection count, read work, cached reads, resilience, and retention are separate problems. RDS Proxy pools supported database connections and can protect a database from client churn; it does not cache query results or add writer CPU. A read replica supplies separate read compute for queries that tolerate replication lag; it does not scale writes and should not be confused with a traditional Multi-AZ standby used for availability. A data cache stores selected results or objects and needs a correctness policy. Backups and snapshots satisfy recovery and retention rather than serving traffic. Diagnose CPU, I/O, connections, query latency, replica lag, hit ratio, and recovery objectives before buying one of these mechanisms. A Lambda connection storm with idle database CPU points toward pooling, while a reporting workload saturating read CPU may justify replicas. Repeated catalog lookups may justify caching later, but one service should not be stretched across all three symptoms. Price each recurring resource and the transfer or operational side effects it creates.

A homogeneous migration may preserve engine compatibility and use native tools or AWS DMS for movement. A heterogeneous migration changes engine semantics and therefore requires schema and code assessment, conversion, and remediation in addition to data transfer. AWS DMS task modes support full load and ongoing change processing for low-downtime patterns, while DMS Schema Conversion is the direct AWS capability for assessing and converting schema objects. Unsupported or imperfectly converted procedures, functions, data types, and application SQL require manual work and testing. DMS data movement alone cannot make incompatible code correct. Size the migration from source read capacity, target write capacity, network, total bytes, change rate, large objects, and CDC lag. Validate row counts and business invariants, not only task completion. Keep a rollback point and define the final write-freeze or reconciliation process. The direct task-mode and schema-conversion sources belong in the claim-bearing section because this boundary determines the answer.

Migration payback includes assessment, conversion labor, application changes, licenses, test environments, DMS resources, transfer, dual-run, performance tuning, cutover support, rollback capacity, and the target run rate. A lower target hourly rate can lose if six months of dual operation and remediation exceed the expected savings horizon. Retention is another cost stream: set automated backup frequency from RPO, manual snapshot retention from policy, copies from failure scope, and restore testing from RTO. Do not retain an unowned replica as a substitute for a recovery plan, and do not delete old snapshots before legal ownership is confirmed. During cutover, monitor source and target transaction rates, CDC latency, validation exceptions, connection errors, and application correctness. After stabilization, retire migration resources and old licenses only after rollback expiry. If schemas become fully compatible and downtime becomes acceptable, a simpler native or homogeneous path may reverse the decision. If connection churn disappears, RDS Proxy may no longer justify its recurring cost. These explicit exit conditions prevent temporary migration controls from becoming permanent waste.