How to Migrate from Supabase to AWS

From Supabase to AWS#

Supabase is where a lot of teams start, because it lets you build fast. You get PostgreSQL, Auth, Storage, and Edge Functions in one place, and you don't manage any infrastructure to get there.

The reasons to leave usually show up later, once the product is past its early stage and the requirements outgrow the all-in-one model:

• Advanced database management – high availability, read replicas, automated backups, and fine-tuned performance.
• Analytics and data warehousing – integrating with data lakes and large-scale ETL pipelines.
• Enterprise-grade compliance and security – meeting SOC, ISO, HIPAA, or FedRAMP standards.
• Granular IAM and networking – unifying database access, APIs, and infrastructure under a single identity and policy system.

This is the point where teams look at the hyperscalers: AWS, GCP, and Azure. The trade-off is that the convenience of one bundled platform is gone. In return, each component is its own purpose-built service and scales on its own.

This guide is written for AWS, but the order of operations and the architecture patterns carry over to GCP and Azure with little change.

We'll walk through each Supabase component and where it lands on AWS.

Debundle Supabase#

Recommended migration order:

The approach here is services-first: peel off the Supabase-specific services one at a time, and leave the database for last, where it turns into an ordinary PostgreSQL migration.

1. Networking & IAM – set up AWS infrastructure (VPC, subnets, IAM roles).
2. Auth – migrate to Cognito (decouples from Supabase auth schema).
3. Storage – migrate to S3 (decouples from Supabase storage schema).
4. Functions – redeploy to Lambda (update to use Cognito + S3).
5. Realtime – replace with AppSync/EventBridge (removes logical replication dependency).
6. Database – simple PostgreSQL migration of application data only (public schema).

Why this order? Once the services are moved, the Supabase auth and storage schemas stop being used. That leaves only your application data to migrate at the end, which means lower risk, a simpler cutover, and far less to validate.

A practical note: do every step in staging first, confirm it works, and only then repeat it in production.

1. Networking and IAM#

Supabase: Abstracted networking and simple project-level access roles.

AWS approach: Full-control networking and IAM system for isolation and compliance.

Migration focus:

1. Create VPC with public and private subnets across multiple Availability Zones.
2. Set up Security Groups for database, Lambda, and API Gateway.
3. Configure Route Tables and NAT Gateways for private subnet internet access.
4. Create IAM roles for Lambda, RDS, S3, and Cognito.
5. Set up VPC endpoints for AWS service access (S3, DynamoDB, etc.).
6. Use AWS Organizations for environment isolation (dev, staging, prod).

Key advantages:

• Granular control over infrastructure and networking.
• Centralized access and audit through IAM.
• Broad compliance coverage: AWS Compliance vs Supabase Security.

2. Auth → Amazon Cognito (or Alternatives)#

Supabase: GoTrue-based Auth with email/password and OAuth integration, connected to Postgres RLS.

AWS replacement:

• Amazon Cognito for user pools, federated identity, and SSO integration.
• Alternatives like BetterAuth, Auth0, or Clerk if developer-experience is a priority.

Migration focus:

1. Export user data (emails, metadata, OAuth IDs) from auth.users.
2. Import into Cognito User Pool.
3. Configure OAuth providers (Google, GitHub, etc.).
4. Update frontend SDKs and backend JWT verification.
5. Update application authorization logic (see RLS section below).
6. Require one-time user re-authentication after migration.

Key advantages:

• Deep IAM integration with AWS services.
• SAML/OIDC support and MFA.
• Fine-grained access control and security compliance.

3. Storage → Amazon S3#

Supabase: S3-compatible object storage managed inside Supabase, with integrated access policies and signed URLs.

AWS replacement:

• Amazon S3 for raw file storage.
• CloudFront for CDN delivery.

Migration focus:

1. Create an S3 bucket with IAM-based access.
2. Copy data using aws s3 sync or rclone.
3. Recreate folder structure and permissions.
4. Update signed URL logic to use S3 pre-signed URLs.
5. Add CloudFront for caching if needed.

Key advantages:

• Lifecycle policies, versioning, and encryption (SSE-KMS).
• Regional redundancy and cost-based storage tiers.
• Tight integration with Lambda, Athena, and Redshift.

4. Functions → AWS Lambda#

Supabase: Edge Functions built with Deno for lightweight APIs.

AWS replacement:

• AWS Lambda for event-driven functions.
• API Gateway for HTTP endpoints.

Migration focus:

• Rewrite Deno functions in Node.js, Python, or Go.
• Deploy via Lambda console, CLI, or IaC (Terraform/CDK).
• Store environment variables in Secrets Manager or Parameter Store.
• Connect Lambda to S3, DynamoDB, or EventBridge as needed.

Key advantages:

• Multiple runtimes and deployment methods.
• Native observability via CloudWatch.
• Scales automatically with demand.

5. Realtime and Events → AppSync / EventBridge#

Supabase: Realtime engine based on Postgres logical replication and WebSockets.

AWS replacements:

• AppSync – GraphQL subscriptions for live updates.
• EventBridge, SNS, or SQS – event-driven messaging.
• API Gateway WebSockets – persistent connections for custom protocols.

Migration focus:

1. Identify realtime use cases (chat, collaboration, notifications).
2. Choose appropriate AWS service per pattern.
3. Replace database-triggered realtime with event-driven design.

Key advantages:

• Decoupled architecture.
• Scalable pub/sub and async event flows.
• Integrates natively with Lambda and analytics pipelines.

6. Database → Amazon RDS / Aurora#

Supabase: Managed PostgreSQL with auth, storage, and public schemas.

AWS replacement:

• Amazon RDS (PostgreSQL) – Multi-AZ, automated backups, PITR, read replicas.
• Amazon Aurora (PostgreSQL-compatible) – high-performance clustered Postgres.
• DynamoDB – optional for NoSQL or key-value workloads.

Why migrate last:

By the time you reach this step, Auth is on Cognito, Storage is on S3, and Realtime has moved to AppSync/EventBridge. The Supabase auth and storage schemas are dormant: your application no longer touches them.

So the database migration is the boring kind, which is exactly what you want. It's a plain PostgreSQL migration of your application data, the public schema.

Handling Row-Level Security (RLS) Policies

Supabase leans on PostgreSQL Row-Level Security (RLS) policies a lot. Those policies reference Supabase-specific functions and the auth.users table:

-- Example Supabase RLS policy
CREATE POLICY "Users can only see their own data"
ON public.profiles
FOR SELECT
USING (auth.uid() = user_id);

The catch is that auth.uid() and auth.jwt() are Supabase-specific functions, and they stop working once you're on Cognito.

Migration Strategy: Replace RLS with Application-Level Authorization

The common approach is to lift authorization out of the database and into your application layer (the Lambda functions):

• More flexible – Works with any auth provider (Cognito, Auth0, BetterAuth, etc.).
• Easier to test – Authorization logic can be unit tested independently.
• Framework-agnostic – Not tied to PostgreSQL-specific features.
• Modern best practice – Industry standard for cloud-native applications.
• Better debugging – Authorization failures are easier to trace in application code.

Implementation example:

// Lambda function with application-level authorization
const getUserProfile = async (event) => {
  // Extract Cognito user ID from JWT claims
  const cognitoUserId = event.requestContext.authorizer.claims.sub;

  // Enforce authorization in application code
  const profile = await db.query('SELECT * FROM profiles WHERE user_id = $1', [cognitoUserId]);

  return profile;
};

Database migration focus:

1. Audit RLS policies – Identify all RLS policies in your schema (see RLS migration strategy above).
2. Set up RDS/Aurora instance in the VPC created in step 1.
3. Export public schema and data using pg_dump (ignore dormant auth and storage schemas).
4. Restore into RDS or Aurora (same Postgres version).
5. Implement application-level authorization – Migrate RLS logic to Lambda functions as shown above.
6. Remove RLS policies – Drop policies once application-level authorization is tested and deployed.
7. Recreate extensions (e.g., pgcrypto, uuid-ossp) if used in application.
8. Validate schema and queries in staging environment.
9. Update application connection strings to point to RDS/Aurora.
10. Perform final cutover during low-traffic window.

Key advantages:

• Performance tuning and CloudWatch metrics.
• Private networking in VPC with security groups.
• Access to AWS analytics tools (Redshift, Athena, Glue).

Conclusion#

Migrating from Supabase to AWS is more than a lift-and-shift. You're trading a bundled platform for a set of independent services, and the payoff is room to scale.

The services-first order keeps the risk where you can manage it: Networking & IAM → Auth → Storage → Functions → Realtime → Database.

Because the services move first, the final database step is a plain PostgreSQL-to-PostgreSQL migration of your application data, which is lower risk, simpler to cut over, and easier to validate.

Supabase is good at helping you build fast. AWS is good at what comes after that: advanced database management, analytics, IAM, and compliance. If you handle the order carefully, the result is a foundation your product can keep growing on.