Migrating from AWS RDS to Self-Hosted PostgreSQL: A Complete Plan, Cutover Method and Checklist

How to move a small SaaS stack (Fargate containers, RDS, ElastiCache, NAT gateways) to a hardened Docker host with PostgreSQL you operate yourself, with minutes of downtime and a real way back.

By Subeesh Sivanandan, Founder & CEO, Stonetusker Systems · Last reviewed October 2026 · Est. reading time: 39 minutes

Why teams leave managed databases, and who shouldn't

For about a decade the standard advice has been to let someone else run your database, and early on it's the right call. Nobody on a five-person team wants to be the DBA. RDS hands you backups, Multi-AZ failover and patching in a few clicks, and the premium is small next to the cost of an outage that nobody knows how to debug.

The math changes as a product settles down. Managed pricing charges a markup on RAM, provisioned IOPS and storage compared with raw hardware, and the plumbing around it adds its own line items: NAT gateways, load balancers, cross-AZ traffic, egress. When the workload is steady and the database is the biggest number on the invoice, you're paying a flexibility premium for flexibility you aren't using.

Tooling has moved too. pgBackRest, native logical replication and cheap NVMe servers mean a small team can run PostgreSQL properly without a dedicated DBA. "Properly" is doing real work in that sentence: tested restores, monitoring that pages someone, and a patching routine. Skip those and you've traded a bill for a risk.

Should you migrate at all?

This article is a reference plan with a worked example, not a client story. The example is a generic, hypothetical stack: application containers on ECS Fargate, one large single-AZ RDS instance running PostgreSQL 16 with a few hundred GB of data, a managed cache, a pair of load balancers and NAT gateways, and a scheduled batch job, all managed with Terraform. The containers are small, yet most of the monthly bill is the database instance. Every figure below is an assumption you should replace with your own.

That ratio is the whole story. The compute is tiny and the database is oversized, and everything else is the usual AWS tax: NAT gateway hourly and per-GB charges, ALB fixed fees, and a serverless cache priced for spiky workloads this example team doesn't have.

Before anyone touches a server, run the comparison honestly. There are three realistic options.

These saving ranges are illustrative. Your own numbers come from Cost Explorer, CloudWatch metrics for the last 30 to 90 days, and the actual query workload. If the data says the instance is 15 percent utilized at peak, option A alone is a quick win and option B is the bigger, riskier step. If it says the instance is genuinely busy during search-heavy periods, sizing the replacement correctly matters more than the savings headline.

The right-size-first answer is a legitimate outcome of the assessment. A consultant who only ever recommends migrating is selling you a project, not a plan.

Target architecture and sizing

For this workload, two servers in the same provider region but separate data centers (or at minimum separate racks) beat one big server. The first runs the application stack and the primary database. The second is a streaming replica that doubles as the restore-test target and the failover candidate.

A cleaner split is database on its own host, application containers on another. It costs a little more and removes the noisy-neighbor problem when the ETL job hammers the disks at 3 a.m. For a team this size, start with the split if the budget allows, and fall back to a single combined primary plus a standby if it doesn't.

How the pieces connect

Both replication directions run over the private tunnel described under "The network path for replication" below. The solid arrow from RDS carries the migration. After cutover the dashed path takes over as your rollback safety net, and the primary, standby and backup repository are the permanent design.

Specification, with reasoning

One design decision worth stating plainly: run PostgreSQL directly on the host from the PGDG packages, not inside the same Compose file as the app. Containerized Postgres works, and plenty of people run it that way. But a docker compose down typed on the wrong terminal shouldn't be able to stop your database, and host-level packages make upgrades and pgBackRest integration more predictable.

Failover: keep it manual and rehearsed

With two database nodes, resist the urge to add Patroni, repmgr or another automatic failover layer unless you have someone who will own it. Automatic tools need a proper consensus setup (a third node or witness) to avoid split-brain, and a badly tuned one will promote the standby over a network blip and leave you with two primaries. A written, timed, manual runbook is safer at this scale. Drill it and record the real time, because that number is your failover time:

1. Confirm the primary is really down, then fence it: power it off or cut its network so it can't come back and accept writes.
2. Promote the standby with SELECT pg_promote(); or pg_ctl promote.
3. Repoint the application: move the floating IP, update the DNS record, or change the PgBouncer target.
4. Confirm WAL archiving and backups continue from the new primary (pgBackRest follows the new timeline).
5. Rebuild the old primary as a standby with pg_rewind or a pgBackRest delta restore.

Revisit automation when the team grows or the downtime tolerance shrinks. Until then, a drilled human beats an untested cluster manager.

Things to inspect before you size anything

Look at pg_stat_statements output on RDS (enable it if it isn't already) and rank queries by total time. Check the largest tables and indexes, write rate (WAL generated per hour), and whether any tables lack a primary key, because that matters for logical replication later. List installed extensions and compare against what you can install on the new host. Read the application's connection handling: pool size, idle timeouts, and whether anything uses long-lived transactions.

Provider and region

Pick the region by user and data location first, price second. If most of your traffic and your data subjects are in Europe, a European region keeps latency low and simplifies data protection. If your users are North American, say so and choose accordingly. API calls out to video and streaming platforms don't care much where you sit.

The criteria that matter more than raw price:

• Two data centers or availability zones in the same region, with a private network between them
• Dedicated NVMe storage (not network-attached volumes with burst credits) for the database
• Out-of-band access (rescue mode, KVM or console) for when SSH is the thing that's broken
• Hardware replacement SLAs you've actually read
• Honest egress pricing, since backups and replication move real data
• An S3-compatible object store from a different company for backups

Dedicated servers from a European bare-metal provider are the cheapest option per unit of performance and the one to price first for a database this size. Large VPS and mid-tier cloud providers cost more but give you faster provisioning and snapshots. Either is fine. Single-vendor lock-in for everything including backups isn't.

Server hardening and Docker setup

Hardening is boring and non-negotiable. Do it on day one, not after the first scary log line.

• SSH keys only: PasswordAuthentication no, PermitRootLogin no, a named admin user with sudo, ideally a non-default port plus a bastion or VPN
• Host firewall (nftables or ufw) with default deny inbound, allowing only 80, 443 and SSH from known ranges
• fail2ban watching sshd and the proxy logs
• unattended-upgrades for security patches, with automatic reboot windows for kernel updates on the standby first
• Time sync (chrony), a swap policy, and vm.swappiness set low on the DB host
• Auditd or at least centralized auth logs shipped off the box

The Docker trap: published container ports bypass ufw rules by default because Docker writes its own iptables entries. Bind internal services to 127.0.0.1 or the private interface explicitly, and publish only the reverse proxy to the world. Check with an external port scan, not by trusting the firewall config.

services:
  proxy:
    image: caddy:2
    ports: ["80:80", "443:443"]
    volumes: ["./Caddyfile:/etc/caddy/Caddyfile:ro", "caddy_data:/data"]
    restart: unless-stopped
  api:
    image: registry.example.com/app-api:${API_TAG}
    env_file: [.env.api]
    expose: ["3000"]
    restart: unless-stopped
  web:
    image: registry.example.com/app-web:${WEB_TAG}
    expose: ["80"]
    restart: unless-stopped
  redis:
    image: redis:7
    command: ["redis-server","--maxmemory","1gb","--maxmemory-policy","allkeys-lru"]
    restart: unless-stopped
  etl:
    image: registry.example.com/app-etl:${ETL_TAG}
    profiles: ["jobs"]
    env_file: [.env.etl]
volumes:
  caddy_data:

Run the ETL job from a systemd timer using docker compose run --rm etl rather than a container that sleeps forever. You get logs in journald and a clear failure signal. Images move out of ECR into a registry you control (a self-hosted registry or a hosted one), pinned by tag or digest, and the old ECR repositories stay until decommission.

PostgreSQL tuning and the search workload

RDS parameter groups hide a lot of defaults. On your own server you set them deliberately. These starting values suit a 64 GB, NVMe-backed host and are a baseline to measure against, not a destination.

shared_buffers = 16GB
effective_cache_size = 44GB
work_mem = 32MB
maintenance_work_mem = 2GB
random_page_cost = 1.1
effective_io_concurrency = 200
wal_compression = on
max_wal_size = 16GB
checkpoint_timeout = 15min
checkpoint_completion_target = 0.9
max_connections = 200
shared_preload_libraries = 'pg_stat_statements'
wal_level = logical          # needed during migration
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'

If the API opens many connections, put PgBouncer in transaction mode in front of it and keep max_connections modest. Raising it to 1,000 to hide a pooling problem is how a server with plenty of RAM ends up swapping.

Filesystem and disk layout

Use XFS or ext4 on the NVMe volume and mount the data directory with noatime, so reads stop generating metadata writes. Keep the data and WAL on volumes that can't starve each other: with a two-drive RAID 1 pair you get most of the benefit from separate logical volumes or partitions, so a runaway WAL backlog can't fill the data volume. A physically separate pg_wal device only pays off if you have a third NVMe drive and heavy bulk-write bursts from the ETL job. Set the I/O scheduler to none or mq-deadline for NVMe, and check SMART health in monitoring.

The heavy search queries

A search-heavy product lives or dies on filtered, sorted, text-heavy queries across a huge table. Those are exactly the queries that behave differently on a new host, because planner statistics, cache warmth and storage latency all change. Capture the top 20 to 50 by total time from pg_stat_statements, replay them against the restored staging copy, and compare plans with EXPLAIN (ANALYZE, BUFFERS). Look at trigram (pg_trgm) GIN indexes for fuzzy name search, partial indexes on active rows, and whether the ETL's bulk writes are bloating things badly enough to need a more aggressive autovacuum setting on the biggest tables.

Run ANALYZE on the whole database after the initial copy. Logical replication does not carry planner statistics across, and a freshly loaded database with no stats picks bad plans.

Choosing the migration method

RDS doesn't give you physical replication access, so pg_basebackup and streaming replication from RDS to your server aren't options. That leaves three methods.

For PostgreSQL 16 to PostgreSQL 16, native logical replication is the usual default. The initial table copy of a database this size can take hours depending on bandwidth and index builds (measure it in staging), and then the new server tracks live changes until you're ready to switch. Documentation: PostgreSQL logical replication.

The network path for replication

Replication needs a route in both directions. The new server connects out to RDS to pull the initial copy and the live changes, and after cutover RDS connects out to the new primary for reverse replication. RDS usually sits in private subnets and the new server should never expose PostgreSQL publicly, so decide this path early.

• Preferred: a private tunnel. A site-to-site VPN or a WireGuard tunnel between the VPC and the new hosts keeps PostgreSQL on private addresses. Test it with psql from each side before touching replication.
• Fallback: a time-boxed, allow-listed TLS path. Make the RDS endpoint reachable only from the new server's fixed IP addresses through its security group. On the new primary, allow only the RDS egress addresses through the host firewall and pg_hba.conf (hostssl, a dedicated replication role, scram-sha-256). Remove the openings when the rollback window closes.
• Check the egress route. If RDS reaches the internet through a NAT gateway, reverse replication depends on that route, so keep the NAT gateway until the rollback window is over. Confirm the actual route in your own VPC.
• Use a dedicated role. Give the replication user only what it needs. On RDS that means membership in the rds_replication role plus read access to the tables. Check the current RDS and PostgreSQL documentation for the exact grants.

Setup outline

On RDS, set rds.logical_replication = 1 in the parameter group. That change needs a reboot, and on a single-AZ instance the reboot is an outage, so schedule it in a quiet window and tell people. Then create the schema on the target, publish, and subscribe.

# 1. Schema only, from RDS to the new server
pg_dump --schema-only --no-owner --no-privileges -h RDS_HOST -U admin appdb | psql -h NEW_HOST -U postgres appdb

# 2. On RDS: publish
CREATE PUBLICATION st_migrate FOR ALL TABLES;

# 3. On the new server: subscribe and copy
CREATE SUBSCRIPTION st_sub
  CONNECTION 'host=RDS_HOST dbname=appdb user=repl_user sslmode=require'
  PUBLICATION st_migrate;

Two cautions. A long initial copy holds a snapshot on the source, which delays vacuum there and lets the replication slot retain WAL, so watch RDS free storage the entire time. And any table without a primary key or replica identity will fail on updates and deletes. Find those first with a catalog query and fix them on the source before you start.

Budget for the transfer too. AWS charges standard internet data transfer out of a region, around 0.09 USD per GB at common published rates (check current pricing for your region). A few-hundred-GB initial copy plus a few days of WAL streaming lands in the tens of dollars at that rate, which is trivial, but it's worth writing down so nobody is surprised by the line item.

Proving nothing was lost

Row counts alone aren't verification. Compare counts per table, then compare content hashes by key range for the large tables (for example, an MD5 over ordered rows in 100,000-id chunks, run on both sides). Spot-check recent writes by timestamp. Compare sequence values and set the target ahead of the source at cutover. Run pg_amcheck on the target for index integrity. Finally, run the application's own smoke tests and a read-only copy of real user flows against the new database.

Backups and tested restores

This is the section that decides whether self-hosting is responsible or reckless. Managed databases give you automated backups and point-in-time recovery whether you thought about them or not. On your own hardware, you build that, and you prove it works.

Use pgBackRest (official documentation) with a repository in an S3-compatible bucket at a different provider than your servers. A sensible schedule for this size:

• Full backup weekly, differential daily, with continuous WAL archiving so recovery to any second is possible
• Client-side encryption on the repository (repo1-cipher-type=aes-256-cbc) with the key stored separately from the servers
• Retention: two weeks of fulls, with WAL kept to match. Add a monthly full kept longer if your business needs it
• Backups taken from the standby when possible, to spare the primary
• Bucket versioning or object lock, so a compromised server can't delete its own backups

[global]
repo1-type=s3
repo1-s3-endpoint=objects.backup-provider.example
repo1-s3-bucket=app-pgbackrest
repo1-s3-region=eu-1
repo1-path=/main
repo1-retention-full=2
repo1-cipher-type=aes-256-cbc
process-max=4
start-fast=y

[main]
pg1-path=/var/lib/postgresql/16/main

The restore test is the backup

An untested backup is a hope. Automate a restore into a scratch environment (a container or a small VM, or the standby host's spare disk) on a schedule: weekly is reasonable. The job restores the latest backup, replays WAL to a target time, starts Postgres, runs pg_amcheck, compares table counts against production, and reports how long it took. That duration is your real recovery time objective, and you need to know it before you need it.

Do one full manual restore drill before production data arrives, with someone who didn't set it up following the runbook. If they get stuck, the runbook is wrong.

Monitoring and alerting

CloudWatch told you things without being asked. Off AWS, you have to build the equivalent, and the failure mode to avoid is a pretty dashboard nobody looks at.

A compact stack that fits on the app host: Prometheus, Grafana, Alertmanager, node_exporter on every server, postgres_exporter, cAdvisor for containers, and blackbox probes for HTTPS endpoints and certificate expiry. Add one external uptime check from a different network, plus a dead-man's-switch alert so you find out if the monitoring itself dies.

Alerts should go to a channel somebody owns and a paging path for the serious ones. Every alert needs a runbook link. If an alert has no obvious action, delete it.

The migration playbook

Plan on roughly six weeks for the example stack, with one person doing most of the work and the owning team reviewing. That is a planning assumption, so adjust it after the assessment and the staging rehearsal. Here's the order that avoids the usual surprises.

1. Assess and decide

   Pull 90 days of cost and utilization data, review the Terraform and application code, inventory extensions and cron jobs, and price right-sizing against self-hosting. Deliver a written plan and let the decision-maker approve it before anything is bought.

2. Provision and harden

   Order the servers, apply the hardening baseline, set up the private network and the tunnel to AWS, install Docker and PostgreSQL, and put everything in configuration management or at least a versioned repository.

3. Build backups and monitoring first

   Configure pgBackRest, run the first backup and a full restore drill, then stand up Prometheus, Grafana and alerts. No production data lands before this step passes.

4. Stand up the application stack

   Move images out of ECR, write the Compose files and reverse proxy configuration, wire secrets in through an encrypted store such as SOPS, and bring the stack up against an empty database.

5. Run a parallel staging copy on real data

   Start logical replication, let the initial copy finish, run ANALYZE, then replay the heavy search queries and a traffic sample. Fix indexes and settings now, while nothing depends on it.

6. Rehearse the cutover

   Do a full dry run on a throwaway subscription: freeze writes, drain lag, sync sequences, switch a test hostname. Time every step. Write the real run sheet from the rehearsal.

7. Cut over

   Lower DNS TTLs a week ahead. In a low-traffic window, execute the run sheet, start reverse replication back to RDS, and watch error rates, latency, replication and backups for the first hours.

8. Run in parallel, then decommission

   Keep AWS idle but intact for two to four weeks as the rollback target. When the window closes, take final snapshots, export what you need to keep, and tear down in the right order.

Cutover and rollback

The cutover sequence, once the subscription is caught up and rehearsed:

1. Announce the window and put the app in maintenance mode, or stop the API and ETL containers on AWS so nothing writes.
2. Confirm replication lag is zero on the subscription.
3. Copy sequence values from RDS to the new server, adding a safety margin to each.
4. Run the verification queries: counts, hashes on the hot tables, latest timestamps.
5. Drop the subscription on the target. Promote the new database as the sole writer.
6. Create a publication on the new primary and a subscription on RDS with copy_data = false (the data is already identical), so AWS stays current.
7. Point DNS at the new proxy. Bring the application up on the new host.
8. Smoke test, watch dashboards, announce completion.

The write freeze is the downtime. Its length is the sum of the lag drain, the sequence sync, the verification queries and the DNS switch, so the only honest number is the one you time in your own rehearsal. Set the maintenance window from that rehearsal, with margin. DNS propagation matters less than people fear if TTLs were lowered to 60 or 300 seconds earlier and you keep the old endpoint serving a maintenance page rather than live traffic.

A registrar's default DNS is often a poor place to run DNS for a cutover. Consider moving the zone to a provider with an API and fast propagation a couple of weeks before the migration, copying every record exactly, including the sending-domain verification and DKIM records so email keeps flowing. Leave the email-sending service where it is; it usually costs little and moving it adds risk for no gain.

Syncing sequences at cutover

Logical replication copies row data but not sequence positions, so every serial or identity column on the target would start from its old value. Run this after the write freeze, from RDS into the new server. The margin of 1,000 is arbitrary but safe. The WHERE clause skips sequences whose last_value is null. That value is null for a sequence that has never been used, and it can also be null when your role lacks privileges on the sequence (check the pg_sequences documentation for your version). Resetting a sequence like that to a low number would cause duplicate-key errors, so those are listed for a manual check instead.

# 1. Generate and apply the setval statements
psql -h RDS_HOST -U admin -d appdb -At -c "
  SELECT format('SELECT setval(%L, %s);',
         quote_ident(schemaname) || '.' || quote_ident(sequencename),
         last_value + 1000)
  FROM pg_sequences
  WHERE last_value IS NOT NULL;" | psql -h NEW_HOST -U postgres -d appdb

# 2. List the sequences that were skipped
psql -h RDS_HOST -U admin -d appdb -At -c "
  SELECT schemaname || '.' || sequencename
  FROM pg_sequences
  WHERE last_value IS NULL;"

Review every skipped sequence by hand, and compare each sequence on the target with the highest id in its table before you accept the cutover. A rollback needs the same two steps run the other way, from the new primary into RDS.

Rollback

Define the rollback trigger before cutover, in writing: for example, error rate above a set percentage for 15 minutes, or data integrity doubts of any kind. Because reverse replication has kept RDS current, rollback means freezing writes on the new server, confirming RDS has caught up, switching DNS back, and starting the AWS containers. Test that path in the rehearsal, not just the forward path.

Reverse replication costs a small amount of complexity and removes the worst scenario: discovering a problem on day three and having to choose between losing three days of data and living with the problem.

Reverse replication gotchas

The reverse path is created at cutover, after the forward subscription has been dropped. On RDS, subscribe with copy_data = false, because the tables already hold identical data and a second copy would collide with the existing rows:

# On the new primary
CREATE PUBLICATION st_rollback FOR ALL TABLES;

# On RDS
CREATE SUBSCRIPTION st_rollback_sub
  CONNECTION 'host=NEW_HOST dbname=appdb user=repl_user sslmode=require'
  PUBLICATION st_rollback
  WITH (copy_data = false);

# If you roll back: sync sequences the other way, from the new primary into RDS
psql -h NEW_HOST -U postgres -d appdb -At -c "
  SELECT format('SELECT setval(%L, %s);',
         quote_ident(schemaname) || '.' || quote_ident(sequencename),
         last_value + 1000)
  FROM pg_sequences
  WHERE last_value IS NOT NULL;" | psql -h RDS_HOST -U admin -d appdb

Have someone who has run logical replication in production review the cutover and rollback run sheet before the rehearsal. Reverse replication is easy to get subtly wrong, and a second pair of eyes is cheap insurance.

Know the sharp edges before you rely on it.

• No schema changes. DDL isn't replicated in either direction. Freeze migrations and deploys that alter tables from the cutover until AWS is gone, or the subscription will stall on the first mismatch.
• One writer at a time. RDS must receive nothing except the subscription. Stop the AWS containers and set default_transaction_read_only for the application role on RDS, so a stray cron job can't write there. Never run both directions at once; you'll get conflicts and a dead subscription.
• Sequences go backwards too. A rollback needs the same sequence script run in the opposite direction, from the new primary into RDS.
• WAL retention. If RDS stops consuming, the replication slot on the new primary holds WAL and can fill the disk. Alert on slot lag and disk, and drop the slot as soon as the rollback window closes.
• Drop the forward subscription first. Remove the RDS to new-server subscription before creating the reverse one, so there is never a loop.
• Keep the network path open. Reverse replication and rollback both depend on the tunnel (or the allow-listed path) and, where it applies, the NAT gateway route. Don't remove them until the rollback window closes.

Decommissioning AWS cleanly

After the parallel period, take a final RDS snapshot and export it somewhere cheap. Then work down the list: ECS services and task definitions, ALBs and target groups, NAT gateways and their Elastic IPs (these keep billing if they're orphaned), ElastiCache, RDS, legacy VMs and static IPs, ECR repositories, unused CloudWatch log groups and S3 buckets. Remove the replication tunnel and the temporary firewall and security group rules last, once the rollback window has closed. Use Terraform for what it manages, but check Cost Explorer a week later for anything that kept charging. A forgotten NAT gateway can quietly undo a chunk of your savings.

Expected cost after the move

Treat these as planning assumptions, not quotes or benchmarks. Provider prices move, and you should get current quotes during assessment.

Count the last row honestly. If operating the platform costs a senior engineer a day a month and an occasional bad night, that belongs in the comparison. If the example bill drops from several thousand dollars a month to a few hundred, self-hosting can still win by a wide margin, but it isn't free.

Cost savings, ROI and business impact

Every stakeholder asks the same three questions: how much will we save, when does it pay back, and what does it do to the business. The figures below are a worked example with assumed inputs, not results from a specific client. Replace them with your own numbers from Cost Explorer and your engineering rate card.

Worked example: the assumptions

Worked example: the results

Read the last column carefully. At a 5,000 USD monthly bill, both options beat doing nothing by a wide margin, but self-hosting beats a right-sized AWS by a modest amount over three years and carries more risk. That's a legitimate "stay and right-size" outcome, and it's why the assessment has to come before the build.

The case for migrating strengthens quickly as the bill grows or when right-sizing can't shrink the database much (because the instance is genuinely busy). Take the same pattern at a 15,000 USD monthly bill, with 1,500 USD of self-hosted infrastructure, the same operations cost, and a 51,000 USD one-time cost that includes a larger parallel run: the net saving is about 12,300 USD per month and payback comes in around four months.

The formula to use with your own numbers

net monthly saving = current monthly bill
                   - new infrastructure per month
                   - extra operations cost per month

one-time cost      = project effort
                   + parallel-run AWS billing
                   + staging, egress and tooling

payback (months)   = one-time cost / net monthly saving
3-year net benefit = (net monthly saving x 36) - one-time cost
3-year ROI         = 3-year net benefit / one-time cost

Run it for both right-sizing and migration, then look at the incremental difference between them. That comparison is the real decision.

Impact on the business

• Freed budget. In the example, about 38,000 USD a year of net savings. That's real runway, or a meaningful fraction of an engineering hire, redirected from infrastructure to product.
• More headroom for the same money. Dedicated hardware gives far more RAM and NVMe per dollar than managed instances. For a search-heavy product, that can mean faster queries and room to grow the index without a price jump, though you should verify it with your own benchmarks rather than assume it.
• Predictable billing. Fixed monthly server costs replace usage-based charges (NAT processing, data transfer, IOPS), which makes forecasting simpler.
• Less vendor lock-in. Standard PostgreSQL, Docker and S3-compatible storage can move again later without a rewrite.
• Different risk profile. Multi-AZ automatic failover is replaced by a rehearsed manual one, so recovery time moves from roughly a minute or two to a few minutes up to tens of minutes. Price that honestly: expected extra outage hours per year multiplied by revenue (or support and churn cost) per hour of downtime should be a line in the business case.
• Team focus. Operations hours come out of the roadmap. If the team is small, this is the biggest non-financial cost.

Metrics to track after the move

Agree these before cutover, so the savings are measured and not assumed:

• Monthly infrastructure cost, and cost per active customer or per 1,000 sessions
• p50 and p95 latency for the top search queries and API endpoints versus the pre-migration baseline
• Availability and unplanned downtime minutes
• Measured restore time and backup success rate
• Engineer-hours spent on infrastructure each month

Risks, hidden costs and performance pitfalls

The savings are real, but so are the costs that don't show up on a provider's price page. Put these in front of whoever signs off on the move.

Hidden costs and operational overhead

Will self-hosting cause performance problems?

It can, mostly in the first hours and days, and almost always for reasons you can see coming. In steady state, a dedicated server with local NVMe often beats a network-attached cloud volume on latency, since RDS storage sits behind the network and may be throttled by provisioned IOPS or burst credits. But "often" isn't a promise. Measure it on your own queries before cutover and again after.

The practical rule: set a baseline from RDS before you touch anything (p50 and p95 latency for the top queries, API response times, CPU and I/O), agree an acceptable regression threshold, and compare after cutover. If the numbers fall outside it, you have the rollback path to use.

Data protection considerations

If the database holds personal data about people in the EU or UK (contact details in a CRM, for instance), moving it between providers is a processing change you should document. You'll need a data processing agreement with the new hosting provider, a record of where backups live, encryption at rest and in transit, and an access log for who can reach the servers. See the regulation text itself: GDPR (Regulation 2016/679). Public reference data is a different matter from customer contact records, so classify tables before you decide what needs the strictest controls. This is a planning prompt, not legal advice: ask your counsel or data protection lead to confirm what applies to your case.

The full migration checklist

Print this, paste it into your tracker, and don't tick anything you haven't verified yourself.

Best practices worth repeating

Keep the PostgreSQL major version the same during the move, then upgrade later as its own project. Changing version, host, provider and architecture in one weekend is how small problems become unfindable ones.

Change one variable at a time. Keep the application code frozen during the migration window. Write everything down as you go, because the person who does the cutover is often tired, and tired people follow checklists better than they follow memory.

And plan for the first minor-version upgrade, the first disk failure and the first expired credential. Those arrive eventually, and the team that has drilled them treats them as maintenance.

FAQ

Related reading: Infrastructure as Code Done Wrong: 7 IaC Anti-Patterns Creating Cloud Chaos · Observability on a Startup Budget: What to Instrument First · Migrating from Jenkins to GitHub Actions Without Stopping Releases