How to Scale Your SaaS After Migrating to Supabase

From Migration to Scale

Migrating to Supabase is step one. Getting it to perform at scale is step two. A fresh Supabase setup with default settings handles most small apps fine — but as you grow to thousands of concurrent users, you need to optimize proactively.

1. Configure Connection Pooling Correctly

PostgreSQL connections are expensive. Each connection uses ~5-10MB of RAM. Without pooling, 100 concurrent API requests can crash your database.

Supabase uses PgBouncer for connection pooling. Use the pooler connection string (port 6543) instead of direct (port 5432) for your application:

# Use pooled connection for app (port 6543)
DATABASE_URL=postgresql://postgres.ref:[password]@aws-0-region.pooler.supabase.com:6543/postgres

# Use direct connection for migrations only (port 5432)
DIRECT_URL=postgresql://postgres.ref:[password]@aws-0-region.supabase.com:5432/postgres

In Prisma, configure both:

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DIRECT_URL")
}

2. Add Indexes for Your Query Patterns

The most impactful performance change is proper indexing. Run EXPLAIN ANALYZE on your slowest queries and add indexes where you see sequential scans:

-- Find slow queries
SELECT query, mean_exec_time, calls
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 20;

-- Add index for common filter
CREATE INDEX CONCURRENTLY idx_orders_user_id_created
ON orders(user_id, created_at DESC);

3. Use Supabase Edge Functions for Heavy Logic

Move CPU-intensive operations out of your main API and into Supabase Edge Functions. They run in Deno on Supabase's edge network, reducing latency for global users.

// supabase/functions/process-payment/index.ts
import { serve } from "https://deno.land/std/http/server.ts"

serve(async (req) => {
  const { orderId } = await req.json()
  // Heavy processing here
  return new Response(JSON.stringify({ success: true }))
})

4. Implement Query Caching

For data that doesn't change often (pricing, config, public profiles), cache at the API layer:

// Next.js with fetch caching
const { data } = await supabase
  .from('pricing_plans')
  .select('*')

// Or use Next.js unstable_cache
import { unstable_cache } from 'next/cache'
const getPricingPlans = unstable_cache(
  async () => supabase.from('pricing_plans').select('*'),
  ['pricing-plans'],
  { revalidate: 3600 }
)

5. Use Realtime Selectively

Supabase Realtime is powerful but expensive at scale. Each channel uses a persistent WebSocket connection. Only enable it where real-time updates genuinely matter (chat, live dashboards) — not for everything.

6. Set Up Read Replicas (Self-Hosted)

If you're self-hosting and have heavy read workloads, set up PostgreSQL streaming replication and point read-only queries to the replica:

-- Read queries go to replica
const replicaClient = createClient(REPLICA_URL, ANON_KEY)
const { data } = await replicaClient.from('posts').select('*')

Monitoring at Scale

Set up these monitoring basics before scaling:

• Supabase Dashboard → Reports for query performance
• pg_stat_statements for slow query analysis
• Database size alerts (80% disk usage)
• Connection count monitoring

Ready to migrate and scale? Our team handles the full journey from Lovable Cloud to production-ready Supabase.