How we migrated the database behind every Vercel build
Vercel migrated the state tracking for its build warm pool from Redis to DynamoDB to ensure durability, executing a phased live migration under production traffic with rollback capabilities.
Every Vercel build begins in a warm pool of standby containers that require state tracking for authentication tokens, container statuses, and billing mappings. Initially stored in Redis for speed, the state became critical over time, as data loss could disrupt authentication or billing. The team opted to migrate to DynamoDB, prioritizing durability over Redis’s low latency, despite the challenge of performing the migration live under continuous production traffic.
The migration required redesigning data structures to fit DynamoDB’s model, replacing Redis’s sorted sets with a container-centric schema. The new design used container IDs as sort keys, stored tokens as hashed fields, and introduced time-aware indexes for status counts and deployment lookups. This shift from implicit Redis structures to explicit DynamoDB keys and indexes was essential to meet the access patterns needed for reliable operations.
The rollout proceeded in controlled phases: Redis-only, dual writes, shadow reads, DynamoDB-primary, and finally DynamoDB-only, each with rollback options. Dashboards tracked match rates, write errors, latency, and expiration to detect divergences early. A March incident, where comparison checks overloaded the system, led to adding an index for status counts, resolving O(n) performance issues and allowing the migration to resume safely.
By April, the Redis infrastructure experienced an outage, but the warm pool remained operational because it had already transitioned to DynamoDB as the source of truth. However, a stalled supply loop later revealed unmeasured behaviors, highlighting the need for deeper performance analysis beyond standard metrics. The migration ultimately ensured resilience against Redis failures while maintaining build continuity.