In this article
Context
Our platform content (topics, domains, glossary terms, patterns, decisions) has been stored in Supabase. As our content grows and we add AI features requiring vector search and serverless edge deployments, we need to re-evaluate our database choice. Key drivers: better Vercel Edge compatibility, cost predictability, and branching support for content staging.
Options Evaluated
Stay with Supabase
- +Existing integration — no migration cost
- +Supabase provides Auth, Storage, and Realtime in addition to PostgreSQL
- +Large community and good DX
- −Supabase connection pooling (PgBouncer) has known issues with serverless Edge deployments
- −No native database branching for staging/preview environments
- −Connection limits on free/launch plans can cause issues at scale
Neon (Serverless PostgreSQL)
- +Native serverless architecture — instant cold start, no connection pool management
- +Database branching enables preview deployments with isolated data branches
- +HTTP driver (@neondatabase/serverless) works perfectly in Vercel Edge Functions
- +Auto-suspend on inactivity reduces cost significantly
- +pgvector support for vector search
- −Migration effort: schema + data transfer required
- −No Auth/Storage/Realtime — must use separate services for those
- −Smaller community than Supabase
- −Auto-suspend creates cold start latency for infrequently-used branches
PlanetScale (MySQL)
- +Excellent serverless MySQL with branching
- +Strong ecosystem
- −MySQL, not PostgreSQL — loses pgvector and our SQL expertise
- −We are committed to PostgreSQL for team familiarity
Decision
We migrated from Supabase to Neon. The primary drivers were: (1) Neon's HTTP driver (@neondatabase/serverless) eliminates the connection pooling friction that caused intermittent errors in Vercel Edge deployments, (2) database branching allows us to create isolated preview environments for every Vercel preview deployment with real content data, and (3) the serverless billing model is more cost-effective for our usage pattern.
Consequences
- •Migrate schema and seed data from Supabase to Neon — completed via migration scripts
- •Replace supabase-js client with @neondatabase/serverless + neon() HTTP driver
- •Set up Neon branch-per-preview-deployment via Neon GitHub integration
- •Move user auth from Supabase Auth to Firebase Auth (already partially in place)
- •Retain Supabase for any Realtime features until a replacement is evaluated
- •Document connection string pattern: NEON_DATABASE_URL with pooled connection string for serverless