Moving an AWS database into a Supabase target requires more than a database export. WZ-IT provides a Supabase migration from €3,490 after assessing RDS, Aurora and the connected applications.
In an AWS RDS or Aurora PostgreSQL to Supabase migration, the database core is compatible but the operating model is different. AWS-specific roles, parameter groups, IAM connections, VPC controls and dependent services are not represented by a PostgreSQL dump alone.
The first step is therefore separating what lives in the database from what the AWS environment provides.
Distinguish RDS from Aurora
Identify the engine and operating pattern before planning:
- RDS for PostgreSQL
- Aurora PostgreSQL-Compatible
- Aurora Serverless
- read replicas or Aurora readers
- Multi-AZ and failover configuration
- RDS Proxy or other connection pools
- IAM Database Authentication
- AWS Database Migration Service
Supabase does not automatically replace the full AWS architecture. Decide whether only PostgreSQL moves, whether the target becomes a complete Supabase backend, or whether the application and other AWS services leave as well.
Technical source assessment
| Area | Typical RDS or Aurora question |
|---|---|
| Network | Private subnets, security groups, peering, VPN and allowed transfer paths |
| Roles | rds_superuser, owners, IAM Auth and provider-internal roles |
| Extensions | Availability and version parity on Supabase |
| Parameters | Parameter group differences and wal_level |
| Data | Size, write rate, large objects and partitioning |
| Availability | Read replicas, Multi-AZ, failover and downtime objective |
| Integrations | Lambda, S3, EventBridge, Secrets Manager, CloudWatch and Glue |
Aurora behaves like PostgreSQL for many SQL workloads but adds its own operating and scaling capabilities. These are not exported as database objects.
Build a secure transfer path
RDS often runs only inside private subnets. Test and cutover need a controlled network path, such as:
- a temporary migration VM inside the AWS VPC
- VPN between AWS and the target environment
- narrowly scoped, time-limited access
- transfer through encrypted dump files
- logical replication across restricted endpoints
Credentials should exist only for the required period and be rotated after migration. A production database should not be made broadly public for convenience.
Dump and restore
Native PostgreSQL tools can move the database within a planned maintenance window. The rehearsal checks:
- whether every extension exists on Supabase
- whether RDS-internal roles or owners appear in the dump
- whether functions depend on AWS services
- how long export, transfer and restore take
- which target compute and IOPS are required for import
The official Supabase RDS migration guide uses a provider-neutral dump without ownership and privileges.
Replication and short downtime
Logical replication can preload data when the source has a high write rate. Parameter groups, replication privileges, publications, primary keys and network access all need to support it.
Cutover tasks remain even with replication:
- freeze schema changes during migration
- reconcile sequences before switching
- transfer non-replicated objects separately
- pause writes briefly
- confirm the final replication position
- switch applications and workers together
A blanket zero-downtime promise is not credible without these checks.
Application dependencies in AWS
Applications may remain in AWS and connect to Supabase externally after the database move. A complete AWS exit also needs to assess:
- Lambda and server-side jobs
- S3 buckets and upload paths
- Secrets Manager and Parameter Store
- Cognito or other identity providers
- SQS, SNS and EventBridge
- CloudWatch logs, metrics and alerts
- private DNS and VPC endpoints
Supabase Auth, Storage, Realtime and Functions can cover some requirements, but they are not automatic one-to-one replacements.
Switch and validate the application
Connect a staging deployment to Supabase before cutover. Test:
- direct and pooled database access
- TLS, timeouts and connection limits
- transactions and prepared statements
- critical read and write paths
- jobs, Lambda calls and webhooks
- roles, grants and RLS
- backup and recovery of the target
Use the Supabase migration checklist for the sequence. If the platform should ultimately run on customer-controlled infrastructure, also review Supabase Cloud to self-hosted migration.
After cutover
Keep RDS or Aurora unchanged through the agreed rollback window. Retire replication, snapshots and AWS resources only after data acceptance, performance validation and a target backup.
WZ-IT can then operate the platform as managed Supabase.
