How to Migrate Paused Supabase Projects in India to IndBase

The Pain of Inactive Project Pausing in India

Developers using global free-tier database services frequently run into a painful obstacle: automated project pausing. Under Supabase's standard terms, databases without active API transactions for 7 consecutive days are put into a sleep state. For sandbox apps, development environments, and low-volume staging sites, this means the next database request hits a 30-second cold start wall, leading to front-end timeout crashes and interrupted client feedback cycles.

Compounding this, global providers route free tier workloads to far-flung regions like Singapore (ap-southeast-1) or the US. Migrating your workloads to a dedicated local sovereign alternative like IndBase Cloud keeps your database active 24/7, eliminates automated sleep pauses, and drops connection latency to a sub-5ms round-trip.

Step 1: Export Your Supabase Schema and Data

Since both Supabase and IndBase run on standard Postgres, you can migrate your database states using standard command-line tools like pg_dump. First, retrieve your Supabase connection details from their console dashboard, then execute the dump:

# Export database schema and table rows to a compressed dump file
pg_dump -h db.supabase.co -U postgres -d postgres -F c -b -v -f supabase_backup.dump

Enter your database admin password when prompted. This command safely packs all tables, custom schemas, row-level policies, and indices.

Step 2: Initialize Your IndBase Cluster

Next, log in to the IndBase console, create a new project, and select your preferred Indian region (Mumbai or Bangalore) to anchor your data locally. Once provisioned, copy your new target Postgres credentials and database connection string:

postgres://postgres:[PASSWORD]@mumbai.indbase.cloud:5432/postgres

Step 3: Restore Database Schema & Data

Before running the restore, clean the default schema structure on the fresh target instance to prevent primary key conflicts, then execute the restore with pg_restore:

# Restore schemas, indices, and rows onto IndBase
pg_restore -h mumbai.indbase.cloud -U postgres -d postgres -v supabase_backup.dump

Once executed, your entire table layout, pgvector embeddings, and trigger configurations are restored and operational.

Step 4: Migrating Authentication & User Logs

IndBase features a fully JWT-compliant auth engine matching standard JSON Web Token schemas. If you used custom metadata columns in your authentication tables, verify that your user schema references match the restored auth tables. Because schemas are aligned, you don't need to rebuild user authentication profiles or reset existing passwords.

Step 5: Update Env Variables

Finally, swap out your old credentials in your frontend application (e.g., your Next.js `.env.local` or secrets file):

# Old
# NEXT_PUBLIC_SUPABASE_URL=https://xyz.supabase.co
# NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGciOi...

# New
NEXT_PUBLIC_INDBASE_URL=https://api.indbase.cloud
NEXT_PUBLIC_INDBASE_ANON_KEY=eyJhbGciOi...
INDBASE_DATABASE_URL=postgres://postgres:[PASSWORD]@mumbai.indbase.cloud:5432/postgres

Restart your application server. Your queries will now execute against your active IndBase database inside India, cutting latency to under 5ms and keeping your database awake permanently!