Untitled category

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.

Untitled category,  Untitled category

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