A phased migration from Supabase

Who is this for?

Mobile application and backend teams.

Before you start

An owned staging environment, sample user journey and access model.

1. Inventory schema and product dependencies

List tables, views, triggers, extensions, RLS policies and role grants. Include direct Supabase API calls from mobile clients and Edge Functions usage.

2. Validate PostgreSQL compatibility

Check source and target versions, extensions and collation. Restore into an isolated target and test queries and permissions as the real application role, not an administrator.

3. Rebuild Auth and tenant boundaries

Plan user identity, social links and password/session migration separately. When records previously protected by RLS are exposed through a new API, validate equivalent tenant boundaries in the backend.

4. Handle files and realtime

Move Storage objects together with access policies and public/private URL behavior. Realtime membership and reconnection behavior do not arrive automatically with SQL restore.

5. Pilot, measure and cut over

Route one mobile workflow to a new endpoint. Compare SQL results and permission decisions; measure RAM, pooling and query latency. Define handling of writes during cutover and a rollback path.

6. Plan operational responsibility

Self-hosting or a custom API introduces backup, upgrade and monitoring work. We cannot guarantee an entire Supabase stack on a 2 GB VDS. Uygulama Cloud does not offer automatic restore or ready Supabase hosting; this guide is a migration plan.

7. Check extensions, roles and RLS

A restored schema does not prove identical behavior. Inventory PostgreSQL versions, extensions, functions and the application role. An RLS policy depending on an unavailable auth function needs adaptation. Passing as an administrator does not demonstrate ordinary-user isolation. Test migration order and reruns, and inventory global roles, secrets and external files separately.

8. Plan Auth, Storage and Realtime separately

Preserve or map user identities consistently. Check object data and metadata together, including URLs held by older app versions. Realtime and functions expose contracts that a new API will not automatically replace. Document the replacement path for each SDK dependency.

9. Connect restore, pilot and rollback

Restore to a separate environment before a pilot. Test login, RLS, files and updates with real application roles. Identify the writing authority at cutover. Rolling back means accounting for new writes, not merely switching an API address.