Dlaczego Engine nie działa na Vercelu

Vercel to świetna platforma dla statycznych stron Next.js. ISR działa, edge functions są szybkie, DX jest na najwyższym poziomie. Dla Payload v3 z Postgres i Jobs Queue jest jednak nieodpowiedni. Oto trzy powody, dla których Engine działa na Railway.

1. Connection storms

Vercel uruchamia nową instancję Lambda dla każdego requestu. Przy traffic spiku — newsletter blast, viral post — możesz mieć 100+ równoległych instancji, z których każda otwiera połączenie z bazą danych. Postgres pool ma domyślny limit 100. Rezultat: 500 errors i application timeout.

Railway działa jako trwały proces Node.js. Jeden stabilny connection pool, który skaluje się z pamięcią, a nie z requestami. Żadnego connection stormu.

2. Cold starts

Payload init trwa od 5 do 7 sekund. Funkcja Vercela po kilku minutach bezczynności zasypia. Pierwszy odwiedzający po godzinie czeka 5+ sekund tylko na warm-up.

3. Payload Jobs Queue

Payload v3 ma wbudowaną Jobs Queue do zadań w tle — zaplanowane posty, wysyłanie e-maili, przetwarzanie obrazów. Wymaga trwałego procesu. Funkcja Vercela kończy się po odpowiedzi HTTP, więc Jobs Queue nie ma gdzie działać.

Wpływ na koszty

Dla typowego projektu klienckiego: Vercel Pro + Supabase Pro wychodzi ~50 USD/miesiąc. Railway + Cloudflare R2 ~10–15 USD/miesiąc. Przy 12 klientach to oszczędność, którą zawracamy z powrotem w maintenance klienta.

Kiedy Vercel tak? Dla czysto statycznych stron marketingowych bez backendu wciąż jest pierwszym wyborem. Engine nie jest jednak takim przypadkiem — Payload, Postgres i Jobs Queue zmieniają równanie.