Un client m'a appelé en panique il y a environ dix-huit mois. Il avait lancé une API Node.js sur Vercel, tout semblait correct pendant les tests, et puis leur première vraie charge concurrente a frappé et les connexions WebSocket ont juste... disparu. Silencieusement. Aucune erreur dans le tableau de bord, aucune alerte, rien. J'ai dû leur expliquer que leur plateforme choisie ne peut littéralement pas maintenir une connexion persistante ouverte. Ce n'est pas un bug. C'est tout l'intérêt du serverless. Nous avons migré vers Render avant la fin de cette même semaine.
Cette histoire n'est pas inhabituelle. Je l'ai vue une douzaine de fois chez Seahawk Media. Les développeurs choisissent Vercel parce que c'est vraiment excellent pour ce qu'il fait, puis ils ajoutent un cas d'usage pour lequel il n'a jamais été conçu et se demandent pourquoi les choses s'effondrent. Voici donc ma vraie réflexion sur quand utiliser l'un ou l'autre, basée sur des projets réels livrés, pas sur des benchmarks dans un blog.
Ce que Vercel est vraiment bon à faire
Soyons clair : j'utilise Vercel. Beaucoup. Pour les sites marketing, les applications Next.js, les frontends riches en contenu où la couche API est fine, Vercel est toujours le moyen le plus rapide de passer d'un git push à une URL en direct avec un CDN devant. Le Vercel Edge Network est vraiment impressionnant pour le contenu statique et ISR. Les déploiements en aperçu sont magiques pour les remises aux clients.Vercel Edge Network is genuinely impressive for static and ISR content. Preview deployments are magic for client handoffs.
Où il excelle, spécifiquement :
- Des apps Next.js utilisant ISR ou SSG où les pages sont pré-rendues ou régénérées selon un planning
- Des projets orientés frontend où le backend est une API tierce (Stripe, Sanity, Shopify)
- Des équipes qui déploient fréquemment et ont besoin de previews sur branches pour la QA
- N'importe quoi où la latence de cold start est acceptable parce que le trafic est prévisible et par rafales
La tarification convient aussi pour ces workloads. Une petite SaaS sur le plan Pro à 20 $/mois a tout son sens si vos fonctions sont de courte durée et sans état.
La Contrainte Serverless Incontournable
Les fonctions sur Vercel dépassent le délai imparti. Par défaut c'est 10 secondes sur le plan Hobby, jusqu'à 300 secondes en Enterprise. Plus important encore, chaque invocation est isolée. Il n'y a pas de mémoire partagée entre les requêtes. Pas de système de fichiers persistant. Pas de processus de longue durée qui tourne en arrière-plan et fait du travail.
Pour la plupart des apps web, franchement, c'est acceptable. Mais il existe toute une catégorie de choses qui simplement ne fonctionnent pas à l'intérieur de ces contraintes.
Où Serverless Commence à Vous Causer des Problèmes
En 2021, Seahawk avait un projet fintech où le client avait besoin de flux de transactions en temps réel poussés vers un tableau de bord. Le développeur original avait essayé de bricoler ça avec du polling toutes les deux secondes. Horrible. On avait besoin de WebSockets. De vraies connexions persistantes et avec état. Vercel était immédiatement hors de question.
C'est là que je vois systématiquement le serverless atteindre ses limites :
- Les connexions WebSocket. Toute plateforme construite sur AWS Lambda ne peut pas maintenir une socket ouverte. C'est aussi simple que ça. Any platform built on AWS Lambda underneath cannot hold a socket open. Full stop.
- Les tâches de fond et les files d'attente. Si vous avez besoin d'un worker qui se réveille toutes les 15 minutes pour traiter une file de travail, vous avez besoin d'un processus persistant. Les Vercel Functions ne le sont pas. 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.
- Les calculs longue durée. Génération de PDF, transcodage vidéo, exports de rapports volumineux. Même avec la limite de 300 secondes, vous patchez l'architecture plutôt que de travailler avec elle. PDF generation, video transcoding, large report exports. Even with the 300-second limit, you're patching around the architecture rather than working with it.
- La mise en cache en mémoire. Si vous utilisez quelque chose comme node-cache pour stocker des données en RAM entre les requêtes, ce cache est détruit après chaque invocation de fonction. Vous allez épuiser votre pool de connexions à la base de données pour rien. 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. - Le pooling de connexions à la base de données. C'est celui-ci qui attrape les gens constamment. Les ORM comme Prisma ouvrent une nouvelle connexion par appel de fonction. À n'importe quel niveau de trafic raisonnable, vous allez épuiser votre limite de connexions Postgres. Vous finissez par ajouter PgBouncer ou le connection pooler de Supabase comme contournement, ce qui fonctionne, mais vous combattez la plateforme. 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.
Ce que Render maîtrise bien
Render exécute de vrais processus persistants. Services web, workers de fond, tâches cron. Quand votre processus Node démarre, il reste actif. Cela signifie que l'état en mémoire, les serveurs WebSocket, les tâches longue durée, tout fonctionne comme vous le feriez sur n'importe quelle machine Linux.
L'offre gratuite est utile pour les environnements de staging (bien qu'elle cold-start après 15 minutes d'inactivité, ce qui est gênant). Le plan Individual à 7 $/mois vous donne un service persistant sans cold starts, et le plan à 25 $/mois augmente la RAM et vous donne l'accès SSH, que j'utilise constamment pour déboguer.
Une tarification qui a du sens pour les services backend
Pour une API backend qui n'a pas besoin d'une scalabilité massive, Render offre une prévisibilité des coûts remarquable. Vous payez pour l'instance, pas par invocation. C'est important quand vous avez un service qui fait un travail constant et régulier. Sur Vercel, une fonction qui s'exécute des milliers de fois par heure s'accumule de manière insidieuse. Sur Render, c'est une redevance mensuelle forfaitaire.
J'ai fait une comparaison l'année dernière pour un client qui avait une API Node.js avec une moyenne d'environ 50 000 requêtes par jour. Sa facture Vercel était montée à 180 £/mois. Nous avons déplacé l'API vers une instance Render à 25 $, l'avons connectée à leur frontend Vercel existant, et leur hébergement backend est passé à 25 £. Le frontend est resté sur Vercel parce que c'est là où Vercel a sa place.
L'architecture que j'utilise réellement maintenant
Après en avoir construit suffisamment, je me suis établi dans un modèle mental assez clair. Ce n'est pas l'un ou l'autre.
- Le frontend (Next.js, Astro, peu importe) va sur Vercel. Previews par branche, CDN edge, rollbacks instantanés. Pas de débat.
- Tout backend stateful, API avec connexions persistantes, ou processus worker va sur Render.
- Postgres ou MySQL sur Railway ou la Postgres managée de Render, selon le budget.Railway or Render's own managed Postgres, depending on budget.
- Redis sur Upstash si c'est une utilisation compatible avec le serverless, ou une instance Redis Render si l'app a besoin de garanties de persistance.
Ce split m'a pris honteusement longtemps à arrêter. Pendant un moment, j'essayais de faire rentrer tout dans Vercel parce que le DX est tellement sympa. Mais combattre les contraintes de la plateforme vous coûte plus de temps que ce que la commodité économise.
Connecter un frontend Vercel à un backend Render
Mécaniquement, c'est simple. Tu définis ta variable d'environnement NEXT_PUBLIC_API_URL dans Vercel vers ton URL de service Render, tu gères CORS côté Render, et c'est essentiellement tout. Render te donne un sous-domaine stable d'emblée (yourservice.onrender.com) et tu peux attacher un domaine personnalisé sans difficultés.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.
Un point à surveiller : les services de la couche gratuite de Render se mettent en veille après 15 minutes d'inactivité. Si ton frontend est sur Vercel et ton backend sur un service Render gratuit, tes utilisateurs vont occasionnellement essuyer un démarrage à froid de 30 secondes le temps que le conteneur Render se réveille. Pour la production, paye simplement le plan à 7 $. Ça ne vaut pas la peine de pourrir l'UX.
Scénarios Spécifiques et ce que je Choisirais Réellement
Je vais être direct ici, parce que c'est là que la plupart des articles comparatifs deviennent vagues.
Scénario 1 : Site marketing Next.js avec formulaire de contact. Vercel. Évidemment. ISR pour les pages de contenu, une simple route API pour le formulaire qui appelle SendGrid. Aucune raison d'introduire Render. Vercel. Obviously. ISR for the content pages, a simple API route for the form that calls SendGrid. No reason to introduce Render.
Scénario 2 : App SaaS avec une API REST Node/Express, Postgres, et des jobs en arrière-plan occasionnels. Frontend sur Vercel, backend API sur Render (plan 25 $), Postgres sur la base de données managée de Render. Jobs en arrière-plan en tant que Render Background Workers. C'est probablement ma configuration la plus courante en ce 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.
Scénario 3 : App collaborative en temps réel utilisant Socket.io. Render, point final. Tu as besoin d'un processus persistant. Je pencherais réellement pour un service Render avec au moins 512 Mo de RAM pour une app Socket.io faisant quelque chose d'intéressant. 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.
Scénario 4 : Frontend WordPress headless simple. Vercel. Next.js avec ISR tirant de WPGraphQL. Le « backend » est WordPress, Render n'entre pas en jeu. Vercel. Next.js with ISR pulling from WPGraphQL. The "backend" is WordPress, Render doesn't enter the picture.
Scénario 5 : App Python FastAPI ou Django. Render. Vercel a un support du runtime Python mais c'est limité et tu vas constamment te cogner au plafond de durée des fonctions. Render exécute simplement ton processus Python comme un serveur normal. 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.
Le Problème du Démarrage à Froid, Honnêtement
Les gens parlent des cold starts de Vercel comme s'il s'agissait d'une gêne mineure. Pour la plupart des workloads frontend, c'en est une. Mais j'ai vu des fonctions Vercel mettre 3-4 secondes à faire un cold start sur le plan Hobby quand vous avez des dépendances lourdes bundlées. C'est une terrible première expérience pour un utilisateur.
Les tiers non-gratuits de Render ne font pas de cold start du tout. Votre processus est actif. Les cold starts AWS Lambda sont la raison sous-jacente pour laquelle Vercel a ce problème, puisque les fonctions de Vercel s'exécutent sur Lambda sous le capot. Ce n'est pas exactement la faute de Vercel, c'est le compromis du modèle serverless.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.
Pour les APIs sensibles à la latence, en particulier tout ce qui est orienté utilisateur et s'exécute à chaque requête, un serveur persistant sur Render se sent souvent plus réactif dans la pratique même si les spécifications brutes semblent comparables.
Quand aucune des deux n'est le bon choix
Si vous exécutez quelque chose qui doit se scaler horizontalement sur des dizaines d'instances à la demande, vous regardez probablement ECS sur AWS, Google Cloud Run, ou Fly.io. L'autoscaling de Render existe mais il n'est pas aussi granulaire que vous ne le voudriez pour un trafic véritablement variable. Vercel bien sûr se scale horizontalement par défaut puisque chaque invocation de fonction est indépendante.
Fly.io mérite une mention ici. C'est conceptuellement plus proche de Render (VMs persistantes) mais avec une meilleure distribution mondiale et plus de contrôle. Je l'ai utilisé pour des apps sensibles à la latence où j'avais besoin d'instances dans des régions spécifiques. Un peu plus de surcharge DevOps que Render cependant.
FAQ
Render est-il plus lent que Vercel pour l'hébergement frontend?
Pour l'hébergement frontend pur, oui, généralement. Le CDN de Vercel est optimisé spécifiquement pour cela. L'hébergement de sites statiques de Render fonctionne bien mais il n'a pas la même portée de réseau edge. Si vous hébergez un frontend, Vercel gagne en vitesse de livraison.
Puis-je exécuter une app Next.js sur Render?
C'est possible. Render supporte Node.js, donc vous pouvez exécuter next start sur un service web Render. Vous perdez des fonctionnalités comme ISR qui fonctionne à la manière native de Vercel, et vous n'obtiendrez pas les déploiements de prévisualisation prêts à l'emploi. Pour une application Next.js, Vercel reste le meilleur choix sauf si vous avez des raisons spécifiques de l'éviter.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.
Est-ce que Vercel fonctionne avec les WebSockets ?
Pas au sens traditionnel. Vercel offre un certain support pour les connexions longue durée via ses fonctionnalités de streaming plus récentes, mais ce n'est pas un substitut à un vrai serveur WebSocket. Si votre application dépend de socket.io ou d'une bibliothèque similaire avec des connexions avec état, exécutez-la sur Render ou Fly.io.socket.io or a similar library with stateful connections, run it on Render or Fly.io.
Et Netlify ? Pourquoi ne l'évoquez-vous pas davantage ?
Netlify convient. C'est effectivement dans la même catégorie que Vercel pour cette conversation : fonctions sans serveur, CDN, excellent pour les frontends statiques et SSR. Les mêmes limitations de serveur persistant s'appliquent. J'utilise simplement Vercel davantage chez Seahawk, donc c'est la comparaison dont je peux parler honnêtement.
Comment l'hébergement de base de données entre-t-il en ligne de compte ?
Ne lancez pas votre base de données de production sur une instance gratuite de Render. Le Postgres gratuit de Render convient au développement et à la préproduction, mais la limite de stockage est serrée et il se fait suspendre. Pour la production, j'utilise généralement le Postgres géré payant de Render (7 $/mois pour le forfait de base) ou Supabase si le client souhaite Row Level Security et les outils Supabase.
---
En bref : Vercel est une plateforme frontend qui exécute du code côté serveur. Render est une plateforme serveur qui possède une belle interface. Une fois que vous avez intégré cette distinction, la décision pour tout projet donné prend environ trente secondes. Utilisez les deux. Ils sont véritablement bons à des choses différentes et le coût d'une configuration hybride est pratiquement nul.