
Prečo Engine nebeží na Verceli
Author
Zdeny
Date Published
Vercel je skvelá platforma pre statické Next.js weby. ISR funguje, edge functions sú rýchle, DX je špička. Pre Payload v3 s Postgres a Jobs Queue je ale nevhodný. Tu sú tri dôvody, prečo Engine beží na Railway.
1. Connection storms
Vercel spustí novú Lambda inštanciu pre každý request. Pri traffic spiku — newsletter blast, viral post — môžete mať 100+ paralelných inštancií, každá otvára databázové spojenie. Postgres pool má default limit 100. Výsledok: 500 errors a application timeout.
Railway beží ako perzistentný Node.js proces. Jeden stabilný connection pool, ktorý škáluje s pamäťou, nie s requestmi. Žiadny connection storm.
2. Cold starts
Payload init trvá 5 až 7 sekúnd. Vercel funkcia po pár minútach nečinnosti zaspí. Prvý návštevník po hodine čaká 5+ sekúnd len na warm-up.
Railway beží 24/7. TTFB pod 100 ms vždy, bez ohľadu na traffic patterns. To je rozdiel medzi „web je rýchly“ a „web je rýchly len pre toho, kto má šťastie“.
3. Payload Jobs Queue
Payload v3 má built-in Jobs Queue pre background tasky — naplánované posty, odosielanie e-mailov, spracovanie obrázkov. Vyžaduje perzistentný proces. Vercel funkcia zaniká po HTTP odpovedi, takže Jobs Queue nemá kde bežať.

Cost dopad
Pre typický klientsky projekt: Vercel Pro + Supabase Pro vyjde na ~50 USD/mesiac. Railway + Cloudflare R2 na ~10–15 USD/mesiac. Pri 12 klientoch je to úspora, ktorú vraciame späť do klientskeho maintenance.
Kedy Vercel áno? Pre čisto statické marketingové weby bez backendu je stále prvou voľbou. Engine ale takým prípadom nie je — Payload, Postgres a Jobs Queue menia rovnicu.

Upřímný pohled na to, proč jsme po pěti letech opustili WordPress a postavili vlastní Engine. Rychlost, bezpečnost a vlastnictví kódu.

Prečo berieme performance a accessibility ako tvrdý CI gate, nie ako marketingovú frázu. Core Web Vitals, performance budget a etika prístupnosti.
