Warum Engine nicht auf Vercel läuft

Vercel ist eine großartige Plattform für statische Next.js-Websites. ISR funktioniert, Edge Functions sind schnell, die DX ist Spitze. Für Payload v3 mit Postgres und Jobs Queue ist es aber ungeeignet. Hier sind drei Gründe, warum Engine auf Railway läuft.

1. Connection Storms

Vercel startet für jeden Request eine neue Lambda-Instanz. Bei einem Traffic-Spike — ein Newsletter-Blast, ein viraler Post — können Sie 100+ parallele Instanzen haben, jede öffnet eine Datenbankverbindung. Der Postgres-Pool hat ein Default-Limit von 100. Das Ergebnis: 500 Errors und Application Timeout.

Railway läuft als persistenter Node.js-Prozess. Ein stabiler Connection Pool, der mit dem Speicher skaliert, nicht mit den Requests. Kein Connection Storm.

2. Cold Starts

Der Payload-Init dauert 5 bis 7 Sekunden. Eine Vercel-Funktion schläft nach ein paar Minuten Inaktivität ein. Der erste Besucher nach einer Stunde wartet 5+ Sekunden allein auf das Warm-up.

3. Payload Jobs Queue

Payload v3 hat eine eingebaute Jobs Queue für Background-Tasks — geplante Posts, E-Mail-Versand, Bildverarbeitung. Sie erfordert einen persistenten Prozess. Eine Vercel-Funktion endet nach der HTTP-Antwort, also hat die Jobs Queue keinen Ort, an dem sie laufen kann.

Kostenwirkung

Für ein typisches Kundenprojekt: Vercel Pro + Supabase Pro kommt auf ~50 USD/Monat. Railway + Cloudflare R2 auf ~10–15 USD/Monat. Bei 12 Kunden ist das eine Ersparnis, die wir direkt wieder in die Kunden-Maintenance stecken.

Wann ist Vercel die richtige Wahl? Für rein statische Marketing-Websites ohne Backend ist es nach wie vor die erste Wahl. Engine ist aber kein solcher Fall — Payload, Postgres und die Jobs Queue verändern die Gleichung.