How Vercel Migrated the Database Behind All Its Builds

Vercel's every build starts from a build warm pool composed of standby containers. This pool manages the mapping that connects container readiness states, authentication tokens, running builds, and billable deployments.

Initially, state was stored in Redis for speed and ease of access, but problems grew over time. While tokens and container states could be regenerated if lost, losing the billing mapping meant it was impossible to recover which deployment should be charged for the build costs.

Vercel chose DynamoDB as the new storage solution, considering its on-demand scaling suited for bursty deployment traffic, built-in TTL, and the lack of need for connection management in high-concurrency environments. However, since it did not guarantee the same latency levels as Redis, schema design tailored to existing access patterns was required.

In the existing Redis structure, the following operations were handled efficiently:

• Storing tokens in sets and sorted sets with expiration
• Managing sorted sets by pending, polling, and building states
• Linking containers and deployments
• Querying container counts hundreds of times during the warm pool replenishment process

The new schema was designed around actual access patterns rather than the database itself. Since most operations start with a known container ID and only polling starts from a token, container ID was used as the sort key, and tokens were stored as hashed fields to ensure available authentication information was not exposed in table query results.

Since the pool continued to operate without interruption—handling container creation, polling, task assignment, and expiration—data could not be copied all at once. Accordingly, the migration was conducted in multiple stages while maintaining production traffic, with each stage placed behind a feature flag and configured for immediate rollback if necessary.