How we migrated the database behind every Vercel build

Vercel migrated the state supporting its build warm pool from Redis to DynamoDB after recognizing that Redis, used as an ephemeral cache, held critical billing mappings that could not be reconstructed if lost. The live migration required a redesigned container-centered DynamoDB schema, hashed tokens, expiry-aware status indexes, and a separate strongly consistent billing-mapping table, followed by feature-flagged phases including dual writes, shadow reads, primary reads, and monitored rollback options. Shadow comparisons exposed an inefficient status-counting implementation that caused excessive load until an index was added, while a Redis outage later demonstrated that state already moved to DynamoDB remained available. After DynamoDB’s higher read latency caused the pool’s supply loop to stall because it performed a state check before each container creation, engineers identified a pre-existing N+1 query pattern masked by Redis’s speed and replaced serialized operations with concurrent supply calls that tolerate limited overprovisioning. Completed in April, the migration removed Redis from warm-pool paths, made essential state durable, and improved the pool-management design by eliminating its dependence on exceptionally low per-query latency.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.