In this article
The problem
Our platform content (topics, domains, glossary terms, patterns, decisions) had been stored in a legacy PostgreSQL setup. 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.
What we weighed
Stay with the existing PostgreSQL setup
- +Existing integration — no migration cost
- +Familiar operational model
- +Large community and good DX
- −Connection pooling had friction 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 ecosystem than older managed PostgreSQL platforms
- −Auto-suspend creates cold start latency for infrequently-used branches
PlanetScale (MySQL)
- +Excellent serverless MySQL with branching
- +Strong ecosystem
- −MySQL-only at the time of this decision — loses pgvector and our SQL expertise (PlanetScale added PostgreSQL support in September 2025, after this decision was made)
- −We are committed to PostgreSQL for team familiarity
What we chose
We migrated the content database to Neon. The primary drivers were: (1) Neon's HTTP driver (@neondatabase/serverless) eliminates connection pooling friction 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.
What it committed us to
- •Migrate schema and seed data to Neon — completed via migration scripts
- •Use @neondatabase/serverless + neon() HTTP driver for serverless reads and writes
- •Set up Neon branch-per-preview-deployment via Neon GitHub integration
- •Use Clerk Auth for account identity
- •Evaluate separate realtime infrastructure only if product features need it
- •Document connection string pattern: NEON_DATABASE_URL with pooled connection string for serverless