Vercel moved build-warm-pool state off Redis live, then had to redesign the loop Redis had been hiding

What we checked

• What is the canonical Vercel URL for the migration write-up? confirmed. The canonical source is the Vercel engineering post “How we migrated the database behind every Vercel build,” published 11 August 2026 and indexed on the company blog the same day. Authors are Melkey Moksyakov, Janos Szathmary, and Andrew Healey, with Kevin Corbett as a contributor. [1][2]
• Has this exact case study already been published in New Runtime? refuted. New Runtime’s infrastructure topic hub lists other Vercel items, including Passport, Sandbox Unix boundaries, and mcp-handler 2.0, but not this warm-pool migration. A search of newruntime.com for the Redis-to-DynamoDB build-database write-up did not return a matching analysis. [12]
• Did Vercel migrate the database behind every build, the warm-pool state, from Redis to DynamoDB while production traffic continued? confirmed. The post states that every Vercel build starts in the build warm pool, that pool state lived in Redis, and that the team moved it to DynamoDB because billing mappings could not be rebuilt if Redis lost them. The pool never stops, so the migration ran live under production traffic rather than as a pause-copy-restart. [1]
• Did the migration run while the service handled 6,000 deployments a minute? unresolved. The engineering post never states a 6,000-deployments-a-minute figure. Official Vercel limits document 6,000 deployments created per day on the Pro plan, enforced as api-deployments-paid-per-day over 86,400 seconds, which is a per-account daily cap, not platform-wide per-minute throughput. The originating social URL could not be opened in this session. [1][10]
• Was the rollout done through feature-flagged phases with a rollback at every step? partly confirmed. The post lists five feature-flagged phases: Redis-only, dual writes, shadow reads, DynamoDB-primary, and DynamoDB-only, and says every phase kept a rollback open for as long as possible. It also says the last step, removing Redis writes, was the only one without an easy rollback, with lingering tokens expiring within about ten minutes. [1]
• Did shadow-read comparison load take down builds in a region before an index landed? confirmed. Vercel writes that in March one region’s builds went down, that investigation pointed at comparison machinery added to check two stores, and that throttling had been reviewed but was not enough. A pull request four days later added the time-aware index status counts needed; without it every count was O(n) while comparisons counted constantly. [1]

What we found

• The canonical source is Vercel’s 11 August 2026 engineering post, also listed that day on the company blog under the blurb that the warm pool is one of the most critical services and was moved from Redis to DynamoDB live through feature-flagged phases. Vercel Community’s 17 August 2026 weekly recap pointed readers at the same post. A later independent teardown treats the five-phase ladder, not the brand names, as the transferable design. [1][2][3][4]
• Vercel did not copy Redis data structures into DynamoDB. After listing eight access patterns, the team centered the model on the container: warmPoolId as partition key, containerId as sort key, token stored as a hash so a table read never returns a usable credential, status as pending, polling, or building, and a single expiresAt. Status counts use a time-aware index that already skips expired rows. Billing lookups got a separate table with consistent reads, which matches AWS’s model that strongly consistent GetItem, Query, and Scan are supported on tables and local secondary indexes, not on global secondary indexes. [1][5]
• The stated DynamoDB fit—on-demand scaling for bursty traffic, native TTL, no connection management—is real in AWS docs, with an important expiry caveat. On-demand mode is the default serverless throughput option and advertises single-digit millisecond latency, not Redis’s about-one-millisecond operations. TTL deletes expired items typically within a few days, not immediately, and AWS tells operators to filter expired items on Query and Scan. Vercel’s queryCount already filters expiresAt > now, so application expiry and native TTL are not the same SLA. [1][6][7][8]
• The rollout was Redis-only, dual writes with Redis as truth and DynamoDB failures logged rather than fatal, shadow reads that compared both stores, DynamoDB-primary with Redis writes kept on, then DynamoDB-only. Dashboards watched match rates, write errors, per-query latency, and expiration counts before each advance. The last step, removing Redis writes, had no easy rollback. The April retrospective put the start in February and the finish in April, with Redis calls gone from warm-pool paths. [1]
• Two failures in March show why dual-running stores are not free. Comparison load took down builds in one region until a missing status-count index landed four days later. Later that month the Redis infrastructure being left actually went down; warm-pool token handling stayed up because it was already reading DynamoDB as truth, while builds still felt the outage through upstream services that had not moved. Vercel’s public status homepage as of 23 October 2026 does not retain March 2026 incidents, so those events remain first-party testimony. [1][9]
• The 6,000-deployments-a-minute claim in the flagged social post is not in the engineering write-up. Official limits list 6,000 deployments created per day on Pro, 450 per hour, and 120 per five minutes, all per owner, plus a community recap that said zero downtime and millions of deployments. The post itself records a regional outage during shadow comparisons, so zero-downtime language overstates it. Related work by Healey and Moksyakov on 30 July 2026 cut end-to-end deployment time by up to seven seconds, which is adjacent platform work, not a throughput proof. [1][10][3][11]

What it means

Sort state into rebuildable and irreplaceable before you pick a store. Tokens that regenerate in ten minutes can live in a cache; billing maps that exist nowhere else cannot. If you must move irreplaceable state, run a five-flag ladder and treat shadow comparison as production load with its own kill switch, sampling, and indexes. Instrument the control loop, not a single store percentile: Vercel’s P95 looked like a few milliseconds while P90 was about 17x, and hundreds of serialized reads turned that into a stalled pool. Do not bake a latency ratio into batch size. Prefer concurrency that tolerates a few extra warm containers over a constant that will drift with load.

Hash secrets in the durable table, filter expiry in queries rather than trusting native TTL to vanish rows on time, and keep writing the old store through new-primary so rollback remains a flag flip. The Hive pool still exists to hide compute boot; this migration is what keeps that pool’s bookkeeping from becoming an unbilled or unauthenticated outage. The same pattern applies to GPU schedulers, agent sandboxes, and any always-on queue whose cache quietly became the ledger.

Still open

• What platform-wide deployments-per-minute figure, if any, applied during February–April 2026, given that 6,000 per minute is absent from the engineering post and 6,000 per day is a Pro account limit?
• Which region failed in March, on which dates, and is there a retained official status incident for the comparison-load outage or the later Redis failure?
• What did DynamoDB cost relative to Redis, and were remaining upstream pipeline services later moved off Redis?
• Did hashed tokens, the billing-mapping table, or concurrent supply calls change customer-visible build start time in a measured way beyond the separate July 2026 changelog?