Proč Engine neběží na Vercelu

Vercel je skvělá platforma pro statické Next.js weby. ISR funguje, edge functions jsou rychlé, DX je špička. Pro Payload v3 s Postgres a Jobs Queue je ale nevhodný. Tady jsou tři důvody, proč Engine běží na Railway.

1. Connection storms

Vercel spustí novou Lambda instanci pro každý request. Při traffic spiku — newsletter blast, viral post — můžete mít 100+ paralelních instancí, každá otevírá databázové spojení. Postgres pool má default limit 100. Výsledek: 500 errors a application timeout.

Railway běží jako persistentní Node.js proces. Jeden stabilní connection pool, který škáluje s pamětí, ne s requesty. Žádný connection storm.

2. Cold starts

Payload init trvá 5 až 7 sekund. Vercel funkce po pár minutách nečinnosti usíná. První návštěvník po hodině čeká 5+ sekund jen na warm-up.

3. Payload Jobs Queue

Payload v3 má built-in Jobs Queue pro background tasky — naplánované posty, odesílání e-mailů, zpracování obrázků. Vyžaduje persistentní proces. Vercel funkce zaniká po HTTP odpovědi, takže Jobs Queue nemá kde běžet.

Cost dopad

Pro typický klientský projekt: Vercel Pro + Supabase Pro vyjde na ~50 USD/měsíc. Railway + Cloudflare R2 na ~10–15 USD/měsíc. Při 12 klientech je to úspora, kterou vracíme zpět do klientského maintenance.

Kdy Vercel ano? Pro čistě statické marketing weby bez backendu je pořád první volba. Engine ale takový případ není — Payload, Postgres a Jobs Queue mění rovnici.