Supabase Production Readiness Checklist

Supabase Production Readiness Checklist

Moving from development to production on Supabase requires deliberate configuration changes. The defaults that make development fast are not always appropriate for serving real users at scale. This checklist ensures your Supabase project is production-grade.

1. Plan and Infrastructure

• Upgrade to Pro or Team plan: The free tier has hard limits on database size, edge function invocations, and storage. Production workloads need the higher limits and SLAs of paid plans.
• Enable Point-in-Time Recovery (PITR): PITR allows you to restore your database to any second within the retention window. This is critical for recovering from data corruption, accidental deletions, or security incidents.
• Choose the right compute size: Monitor CPU and memory usage during load testing and size your database instance accordingly. Supabase allows scaling compute without downtime.

2. Connection Management

PostgreSQL has a limited number of direct connections. In production, always use the connection pooler (PgBouncer):

// Use the pooler connection string for application connections
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);
// The Supabase client automatically uses the correct endpoint

// For direct database access (migrations, admin tools), use:
// postgresql://postgres:[password]@db.[ref].supabase.co:5432/postgres

// For application connections through the pooler:
// postgresql://postgres.[ref]:[password]@aws-0-[region].pooler.supabase.com:6543/postgres

Set connection pool sizes based on your expected concurrent users. The default pool size of 15 is often too low for production.

3. Database Performance

Create indexes for columns used in RLS policies and frequently queried filters:

-- RLS policies often filter by user_id; index it
CREATE INDEX idx_scans_user_id ON public.scans (user_id);

-- Composite index for common query patterns
CREATE INDEX idx_scans_user_created ON public.scans (user_id, created_at DESC);

-- Analyze RLS policy performance
EXPLAIN ANALYZE SELECT * FROM public.scans WHERE user_id = 'some-uuid';

RLS policies execute on every query. Complex policies with subqueries or function calls can significantly impact performance. Profile your queries with EXPLAIN ANALYZE and simplify policies where possible.

4. Monitoring and Alerting

Set up comprehensive monitoring:

• Database metrics: CPU usage, memory, disk I/O, active connections, query latency.
• Edge Function metrics: Invocation count, error rate, latency percentiles (p50, p95, p99).
• Auth metrics: Sign-up rate, login failures, token refresh rate.
• Storage metrics: Bucket sizes, upload/download rates.

Use the Supabase dashboard Logs Explorer to create custom alerts:

-- Find slow queries (> 1 second)
SELECT
  query,
  calls,
  mean_exec_time,
  total_exec_time
FROM pg_stat_statements
WHERE mean_exec_time > 1000
ORDER BY total_exec_time DESC
LIMIT 20;

5. Security Hardening for Production

• Enable SSL enforcement: Require all database connections to use TLS.
• Network restrictions: Allowlist only the IPs that need direct database access.
• Custom domain: Set up a custom domain for your Supabase API (e.g., api.yourapp.com) to avoid exposing your project reference.
• Auth configuration: Disable unused OAuth providers, enable email confirmation, configure password strength requirements.

6. Staging Environment

Create a separate Supabase project for staging that mirrors production:

• Same schema (use migrations to keep them in sync)
• Same RLS policies
• Same Edge Functions
• Similar data volume (use anonymized production data for testing)

Never test against the production database. Use the staging environment for all development, testing, and QA.

7. Backup and Recovery

• Automated backups: Supabase runs daily backups on Pro plans. PITR provides second-level granularity.
• Test restores: Periodically test the restore procedure to ensure backups are valid and the process is documented. Do not wait for an incident to learn how to restore.
• Schema version control: Keep all migrations in version control (supabase/migrations/) so you can recreate the schema from scratch if needed.

8. Load Testing

Before launch, run load tests that simulate realistic traffic patterns:

# Example with k6
k6 run --vus 100 --duration 5m load-test.js

Test both read-heavy and write-heavy scenarios. Monitor database connection counts, query latency, and Edge Function cold start times during the test. Identify bottlenecks and resolve them before real users arrive.

Use AuditYour.app to run a comprehensive security scan as part of your production readiness review.