How we migrated the database behind every Vercel build
By Steven Van ·
Every build on Vercel starts in the build warm pool, which is a set of standby containers that let builds begin without waiting for new compute.
Vercel has moved the database behind its build warm pool, the standby containers that let builds start without waiting for new compute, from Redis to DynamoDB. The pool tracks which containers are ready, the tokens they use to authenticate, and the mapping that ties each running build to the deployment it gets billed for. A lost token or container status can be rebuilt within about ten minutes, but a lost billing mapping can't be recovered, and all of it had been sitting in Redis, run as an ephemeral cache rather than durable storage.
Because the pool never stops, with containers coming up, polling and expiring around the clock, the migration ran live under production traffic rather than as a single cutover. Vercel describes rolling it out in feature-flagged phases: Redis-only, dual writes, shadow reads that compared both stores, DynamoDB as primary, and finally DynamoDB-only, keeping a rollback path open at every stage except the last, since any leftover Redis token expires within ten minutes anyway. DynamoDB offered on-demand scaling for bursty deploy traffic, native TTL and no connections to manage at high concurrency, but not Redis's millisecond latency, so the schema had to be redesigned around the container itself, including a time-aware index to keep status counts fast.
The rollout hit one production incident along the way: in March, the extra load from comparing both stores during shadow mode took down builds in one region. The fix, a missing index for status counts, shipped four days later, and the rollout continued.
