How we migrated the database behind every Vercel build

Vercel’s build warm pool relies on state that tracks container readiness, authentication tokens, and billing mappings. Initially stored in Redis, this state became a liability as its durability requirements grew. Redis’s ephemeral nature meant data loss could disrupt billing or authentication, so Vercel migrated to DynamoDB, which offers native durability, TTL, and on-demand scaling. The trade-off was latency: Redis’s sub-millisecond operations were replaced with DynamoDB’s higher but predictable response times.

The migration had to happen without pausing production traffic. Vercel used a phased approach, with each phase gated behind a feature flag and a rollback path. This allowed the team to validate each step under live conditions, reducing risk. The schema redesign was critical: Redis’s sorted sets and strings were replaced with a container-centric model, where the container ID became the sort key and tokens were stored as hashes to prevent credential leakage.

Access patterns drove the schema design. Most operations targeted specific containers, so key lookups replaced Redis’s set operations. Status counts required a time-aware index to filter expired containers, and billing mappings were split into a separate table for consistent reads. This explicit modeling contrasts with Redis’s implicit structures, where operations like membership checks or status transitions were cheap but opaque. The result is a schema that trades Redis’s speed for DynamoDB’s durability and scalability.

The migration highlights a common tension in system design: balancing speed and durability. Redis excels at low-latency operations but is not a durable store. DynamoDB provides durability and scalability but requires careful schema design to match Redis’s performance. For engineers facing similar decisions, Vercel’s approach offers a template: model access patterns first, migrate in phases, and accept higher latency if durability is non-negotiable.