Why Engine Doesn't Run on Vercel

Vercel is a great platform for static Next.js sites. ISR works, edge functions are fast, the DX is top tier. But for Payload v3 with Postgres and a Jobs Queue, it's a poor fit. Here are three reasons why Engine runs on Railway.

1. Connection storms

Vercel spins up a new Lambda instance for every request. During a traffic spike — a newsletter blast, a viral post — you can end up with 100+ parallel instances, each opening a database connection. The Postgres pool has a default limit of 100. The result: 500 errors and application timeouts.

Railway runs as a persistent Node.js process. One stable connection pool that scales with memory, not with requests. No connection storm.

2. Cold starts

Payload init takes 5 to 7 seconds. A Vercel function goes to sleep after a few minutes of inactivity. The first visitor after an hour waits 5+ seconds just for the warm-up.

3. Payload Jobs Queue

Payload v3 has a built-in Jobs Queue for background tasks — scheduled posts, sending emails, image processing. It requires a persistent process. A Vercel function dies after the HTTP response, so the Jobs Queue has nowhere to run.

Cost impact

For a typical client project: Vercel Pro + Supabase Pro comes to ~50 USD/month. Railway + Cloudflare R2 to ~10–15 USD/month. Across 12 clients that's a saving we put right back into client maintenance.

When is Vercel the answer? For purely static marketing sites with no backend it's still the first choice. But Engine isn't that case — Payload, Postgres and the Jobs Queue change the equation.