Ein Kunde rief mich vor etwa anderthalb Jahren in Panik an. Sie hatten eine Node.js API auf Vercel gestartet, alles sah beim Testen gut aus, und dann traf ihre erste echte gleichzeitige Last ein und die WebSocket-Verbindungen brachen einfach... zusammen. Stillschweigend. Kein Fehler im Dashboard, keine Benachrichtigung, nichts. Ich musste ihnen erklären, dass ihre gewählte Plattform buchstäblich keine persistente Verbindung offen halten kann. Es ist kein Bug. Das ist der ganze Sinn von Serverless. Wir sind noch in derselben Woche zu Render migriert.
Diese Geschichte ist nicht ungewöhnlich. Ich habe es ein Dutzend Mal bei Seahawk Media gesehen. Entwickler wählen Vercel, weil es wirklich exzellent für das ist, was es tut, dann bauen sie einen Use Case ein, für den es nie konzipiert wurde, und wundern sich, warum alles auseinanderfällt. Hier ist also mein tatsächliches Denken darüber, wann man was nutzt, basierend auf echten Projekten, nicht auf Benchmarks in einem Blog.
Wofür Vercel tatsächlich gut ist
Lass mich das klarmachen: Ich nutze Vercel. Viel. Für Marketing-Websites, Next.js Apps, inhaltsreiche Frontends, wo die API-Schicht dünn ist, ist Vercel immer noch der schnellste Weg vom Git Push zur live URL mit einem CDN davor. Das Vercel Edge Network ist wirklich beeindruckend für statische und ISR-Inhalte. Preview Deployments sind magisch für Client-Übergaben.Vercel Edge Network is genuinely impressive for static and ISR content. Preview deployments are magic for client handoffs.
Wo es besonders glänzt:
- Next.js-Apps mit ISR oder SSG, bei denen Seiten vorgeneriert oder planmäßig neu generiert werden
- Frontend-lastige Projekte, bei denen das Backend eine Drittanbieter-API ist (Stripe, Sanity, Shopify)
- Teams, die häufig deployen und für das QA Branch Previews benötigen
- Alles, wo Kaltstart-Latenz akzeptabel ist, weil der Traffic vorhersehbar und in Bursts auftritt
Auch die Preisgestaltung passt für diese Workloads. Ein kleines SaaS im Pro-Plan für $20/month macht völlig Sinn, wenn deine Funktionen kurzlebig und zustandslos sind.
Die Serverless-Beschränkung, die man nicht diskutieren kann
Funktionen auf Vercel haben ein Timeout. Standardmäßig 10 Sekunden im Hobby-Plan, bis zu 300 Sekunden im Enterprise-Plan. Noch wichtiger: Jeder Aufruf ist isoliert. Es gibt keinen gemeinsamen Speicher zwischen Anfragen. Kein persistentes Dateisystem. Kein langfristiger Prozess im Hintergrund, der arbeitet.
Für die meisten Web-Apps ist das ehrlich gesagt okay. Aber es gibt eine ganze Kategorie von Dingen, die einfach nicht innerhalb dieser Grenzen funktionieren.
Wo Serverless anfängt, dir wehzutun
2021 hatte Seahawk ein Fintech-Projekt, bei dem der Client Echtzeit-Transaktions-Feeds auf ein Dashboard pushen musste. Der ursprüngliche Entwickler hatte versucht, das mit Polling alle zwei Sekunden zu behelfsmäßig zu lösen. Furchtbar. Wir brauchten WebSockets. Richtige, persistente, zustandsbehaftete Verbindungen. Vercel kam nicht infrage.
Hier sehe ich durchgehend, wo Serverless an seine Grenzen stößt:
- WebSocket-Verbindungen. Jede Plattform, die auf AWS Lambda basiert, kann eine Socket-Verbindung nicht offenhalten. Punkt. Any platform built on AWS Lambda underneath cannot hold a socket open. Full stop.
- Background Jobs und Queues. Wenn du einen Worker brauchst, der alle 15 Minuten aufwacht, um eine Job-Queue zu verarbeiten, brauchst du einen Prozess, der persistent läuft. Vercel Functions sind das nicht. If you need a worker that wakes up every 15 minutes to process a job queue, you need a process that persists. Vercel Functions aren't that.
- Langläufige Berechnungen. PDF-Generierung, Video-Transkodierung, große Report-Exporte. Selbst mit dem 300-Sekunden-Limit flickst du an der Architektur herum, statt mit ihr zu arbeiten. PDF generation, video transcoding, large report exports. Even with the 300-second limit, you're patching around the architecture rather than working with it.
- In-Memory-Caching. Wenn du etwas wie node-cache verwendest, um Daten im RAM zwischen Requests zu speichern, wird dieser Cache nach jeder Function-Invocation zerstört. Du wirst dein Database Connection Pool ohne Grund überlasten. If you're using something like
node-cacheto store data in RAM between requests, that cache is destroyed after every function invocation. You'll burn your database connection pool for no reason. - Database Connection Pooling. Das trifft viele ständig. ORMs wie Prisma öffnen eine neue Verbindung pro Function Call. Bei vernünftigem Traffic wirst du dein Postgres-Connection-Limit erschöpfen. Du endest damit, PgBouncer oder Supabase's Connection Pooler als Umgehungslösung hinzuzufügen, was funktioniert, aber du kämpfst gegen die Plattform. This one bites people constantly. ORMs like Prisma open a new connection per function call. At any reasonable traffic level you'll exhaust your Postgres connection limit. You end up adding PgBouncer or Supabase's connection pooler as a workaround, which works, but you're fighting the platform.
Was Render richtig macht
Render führt echte persistent laufende Prozesse aus. Web Services, Background Worker, Cron Jobs. Wenn dein Node-Prozess startet, bleibt er laufen. Das bedeutet In-Memory-State, WebSocket-Server, langläufige Jobs – alles funktioniert so, wie du es auf jedem Linux-Box erwartest.
Der kostenlose Tier ist nützlich für Staging-Umgebungen (obwohl er nach 15 Minuten Inaktivität cold-startet, was lästig ist). Der $7/Monat Individual Plan gibt dir einen persistent laufenden Service ohne Cold Starts, und der $25/Monat Plan erhöht den RAM und gibt dir SSH-Zugriff, den ich ständig zum Debuggen nutze.
Preisgestaltung, die für Backend Services Sinn macht
Für ein Backend-API, das keine massive Skalierung benötigt, ist Render bemerkenswert kostensicher. Du zahlst für die Instanz, nicht pro Aufruf. Das spielt eine Rolle, wenn du einen Service hast, der stetig und konsistent arbeitet. Bei Vercel summieren sich Funktionen, die tausende Male pro Stunde laufen, auf Weise auf, die dich überraschen. Bei Render ist es eine pauschale monatliche Gebühr.
Ich habe letztes Jahr einen Vergleich für einen Kunden durchgeführt, der eine Node.js API mit durchschnittlich etwa 50.000 Anfragen pro Tag hatte. Seine Vercel-Rechnung war auf £180/Monat angewachsen. Wir haben die API auf eine Render-Instanz für £25 verschoben, sie mit ihrem bestehenden Vercel-Frontend verbunden, und ihr Backend-Hosting ist auf £25 gefallen. Das Frontend blieb auf Vercel, weil das ist, wo Vercel hingehört.
Die Architektur, die ich jetzt tatsächlich nutze
Nach dem Bau von genug davon habe ich mich auf ein ziemlich klares mentales Modell geeinigt. Es ist nicht entweder/oder.
- Frontend (Next.js, Astro, was auch immer) läuft auf Vercel. Branch Previews, Edge CDN, sofortige Rollbacks. Kein Wettbewerb.
- Jedes zustandsbehaftete Backend, API mit persistenten Verbindungen oder Worker-Prozess läuft auf Render.
- Postgres oder MySQL auf Railway oder Renders eigenem verwalteten Postgres, je nach Budget.Railway or Render's own managed Postgres, depending on budget.
- Redis auf Upstash, wenn die Nutzung serverlos-kompatibel ist, oder eine Render Redis-Instanz, wenn die App Persistenzgarantien braucht.
Diese Aufteilung hat mich beschämend lange gekostet zu erreichen. Eine Weile lang versuchte ich, alles in Vercel zu pressen, weil die DX so gut ist. Aber gegen die Beschränkungen der Plattform zu kämpfen kostet dich mehr Zeit, als die Bequemlichkeit spart.
Vercel Frontend mit einem Render Backend verbinden
Technisch ist das unkompliziert. Du setzt deine NEXT_PUBLIC_API_URL Umgebungsvariable in Vercel auf deine Render-Service-URL, handhabst CORS auf der Render-Seite, und das war's im Grunde. Render gibt dir sofort eine stabile Subdomain (yourservice.onrender.com) und du kannst ganz einfach eine Custom Domain anbinden.NEXT_PUBLIC_API_URL environment variable in Vercel to your Render service URL, handle CORS on the Render side, and that's basically it. Render gives you a stable subdomain out of the box ( yourservice.onrender.com) and you can attach a custom domain easily enough.
Eine Sache, auf die du achten solltest: Services im kostenlosen Tier von Render schlafen nach 15 Minuten Inaktivität ein. Falls dein Frontend auf Vercel und dein Backend auf einem kostenlosen Render-Service läuft, werden Nutzer gelegentlich einen 30-Sekunden-Cold-Start erleben, während der Render-Container aufwacht. Für Production lohnt sich der $7-Plan. Der UX-Schaden ist es nicht wert.
Spezifische Szenarien und was ich wirklich wählen würde
Lass mich direkt sein, denn hier werden die meisten Vergleichsartikel ungenau.
Szenario 1: Next.js-Marketing-Website mit Kontaktformular. Vercel. Offensichtlich. ISR für die Content-Seiten, eine einfache API Route für das Formular, die SendGrid aufruft. Kein Grund, Render einzuführen. Vercel. Obviously. ISR for the content pages, a simple API route for the form that calls SendGrid. No reason to introduce Render.
Szenario 2: SaaS-App mit Node/Express REST API, Postgres und gelegentlichen Background Jobs. Frontend auf Vercel, Backend-API auf Render ($25-Plan), Postgres auf Renders verwalteter Datenbank. Background Jobs als Render Background Workers. Das ist wahrscheinlich mein häufigstes Setup im Moment. Frontend on Vercel, backend API on Render ($25 plan), Postgres on Render's managed database. Background jobs as Render Background Workers. This is probably my most common setup right now.
Szenario 3: Echtzeit-Collaboration-App mit Socket.io. Render, definitiv. Du brauchst einen persistenten Prozess. Ich würde eigentlich einen Render-Service mit mindestens 512MB RAM für eine Socket.io-App wählen, die etwas Interessantes macht. Render, full stop. You need a persistent process. I'd actually lean toward a Render service with at least 512MB RAM for a Socket.io app doing anything interesting.
Szenario 4: Einfaches WordPress-Headless-Frontend. Vercel. Next.js mit ISR zieht von WPGraphQL. Das „Backend" ist WordPress, Render spielt keine Rolle. Vercel. Next.js with ISR pulling from WPGraphQL. The "backend" is WordPress, Render doesn't enter the picture.
Szenario 5: Python FastAPI oder Django App. Render. Vercel hat Python-Runtime-Unterstützung, aber sie ist begrenzt und du wirst ständig an die Function-Duration-Grenze stoßen. Render führt deinen Python-Prozess einfach wie einen normalen Server aus. Render. Vercel has Python runtime support but it's limited and you'll constantly bump into the function duration ceiling. Render just runs your Python process like a normal server.
Das Cold-Start-Problem, ehrlich gesagt
Man spricht über Vercels Cold Starts, als wären sie eine kleine Unannehmlichkeit. Für die meisten Frontend-Workloads sind sie das auch. Aber ich habe gesehen, dass Vercel-Funktionen im Hobby-Plan 3–4 Sekunden für einen Cold Start brauchen, wenn du schwere Dependencies gebündelt hast. Das ist eine furchtbare erste Erfahrung für einen Nutzer.
Renders kostenpflichtige Tiers haben gar keine Cold Starts. Dein Prozess läuft. AWS Lambda Cold Starts sind der Grund dafür, dass Vercel dieses Problem hat, weil Vercels Funktionen unter der Haube auf Lambda laufen. Es ist nicht wirklich Vercels Schuld, es ist ein Kompromiss des Serverless-Modells.AWS Lambda cold starts are the underlying reason Vercel has this problem, since Vercel's functions run on Lambda under the hood. It's not Vercel's fault exactly, it's the serverless model's trade-off.
Bei latenzsensitiven APIs – besonders bei allem, das auf Nutzerseite läuft und bei jedem Request ausgeführt wird – fühlt sich ein persistenter Server auf Render in der Praxis oft schneller an, obwohl die rohen Spezifikationen vergleichbar aussehen.
Wenn keine von beiden die richtige Wahl ist
Wenn du etwas ausführst, das horizontal auf Dutzende von Instanzen auf Abruf skalieren muss, schaust du dir wahrscheinlich ECS auf AWS, Google Cloud Run oder Fly.io an. Renders Autoscaling existiert, aber es ist nicht so differenziert, wie du es für echte variable Last brauchst. Vercel skaliert natürlich horizontal per Default, weil jede Funktionsaufrufe unabhängig ist.
Fly.io verdient eine Erwähnung hier. Es ist konzeptionell näher an Render (persistente VMs), aber mit besserer globaler Verteilung und mehr Kontrolle. Ich habe es für latenzsensitive Apps verwendet, wenn ich Instanzen in bestimmten Regionen brauchte. Ein bisschen mehr DevOps-Overhead als Render allerdings.
FAQ
Ist Render langsamer als Vercel beim Frontend-Hosting?
Für reines Frontend-Hosting, ja, in der Regel. Vercels CDN ist speziell dafür optimiert. Renders Static-Site-Hosting funktioniert gut, aber es hat nicht die gleiche Edge-Netzwerk-Reichweite. Wenn du ein Frontend hostst, gewinnt Vercel bei der Liefergeschwindigkeit.
Kann ich eine Next.js-App auf Render ausführen?
Das geht. Render unterstützt Node.js, du kannst also next start auf einem Render-Web-Service ausführen. Du verlierst allerdings Funktionen wie ISR, die Vercel nativ so handhabt, und du bekommst auch keine Preview-Deployments out of the box. Für eine Next.js-App ist Vercel immer noch die bessere Wahl, es sei denn, du hast spezifische Gründe, es zu vermeiden.next start on a Render web service. You lose things like ISR working the way Vercel handles it natively, and you won't get preview deployments out of the box. For a Next.js app, Vercel is still the better choice unless you have specific reasons to avoid it.
Funktioniert Vercel überhaupt mit WebSockets?
Nicht im klassischen Sinne. Vercel hat zwar eine gewisse Unterstützung für langlebige Verbindungen über ihre neueren Streaming-Features, aber das ist kein Ersatz für einen echten WebSocket-Server. Wenn deine App von socket.io oder einer ähnlichen Bibliothek mit zustandsbehafteten Verbindungen abhängt, führe sie auf Render oder Fly.io aus.socket.io or a similar library with stateful connections, run it on Render or Fly.io.
Wie sieht es mit Netlify aus? Warum erwähnst du es nicht viel?
Netlify ist okay. Es fällt effektiv in die gleiche Kategorie wie Vercel für diese Unterhaltung: Serverless Functions, CDN, großartig für statische und SSR-Frontends. Die gleichen Einschränkungen bei persistenten Servern gelten. Ich nutze bei Seahawk einfach mehr Vercel, daher kann ich diesen Vergleich ehrlich führen.
Welche Rolle spielt Database-Hosting?
Führe deine Production-Datenbank nicht auf einer kostenlosen Render-Instanz aus. Das kostenlose Postgres auf Render ist gut für Entwicklung und Staging, aber das Speicherlimit ist eng und es wird suspendiert. Für Production nutze ich normalerweise Renders kostenloses verwaltetes Postgres ($7/Monat Starter) oder Supabase, wenn der Kunde Row Level Security und die Supabase-Tools möchte.
---
Die Kurzfassung: Vercel ist eine Frontend-Plattform, die zufällig Server-seitigen Code ausführt. Render ist eine Server-Plattform, die zufällig eine schöne UI hat. Sobald du diesen Unterschied verinnerlicht hast, dauert die Entscheidung für jedes Projekt etwa dreißig Sekunden. Nutze beide. Sie sind wirklich gut in verschiedenen Dingen, und die Kosten für einen hybriden Setup sind praktisch null.