Un cliente me llamó en pánico hace dieciocho meses. Habían lanzado una API Node.js en Vercel, todo se veía bien durante las pruebas, y luego su primera carga concurrente real llegó y las conexiones WebSocket simplemente... se cayeron. En silencio. Sin error en el dashboard, sin alerta, nada. Tuve que explicarles que su plataforma elegida literalmente no puede mantener una conexión persistente abierta. No es un bug. Es el punto completo de serverless. Migramos a Render antes del final de esa misma semana.
Esa historia no es inusual. La he visto una docena de veces en Seahawk Media. Los desarrolladores eligen Vercel porque es genuinamente excelente para lo que hace, luego le añaden un caso de uso para el que nunca fue diseñado y se preguntan por qué todo se desmorona. Así que aquí está mi pensamiento real sobre cuándo usar cuál, basado en proyectos reales, no en benchmarks en un blog.
En Qué Vercel Es Realmente Bueno
Déjame ser claro: uso Vercel. Mucho. Para sitios de marketing, aplicaciones Next.js, frontends pesados en contenido donde la capa API es delgada, Vercel sigue siendo la forma más rápida de ir desde un git push a una URL en vivo con un CDN frente a él. Vercel Edge Network es genuinamente impresionante para contenido estático e ISR. Los despliegues de vista previa son magia para entregas a clientes.Vercel Edge Network is genuinely impressive for static and ISR content. Preview deployments are magic for client handoffs.
Donde brilla, específicamente:
- Aplicaciones Next.js usando ISR o SSG donde las páginas se pre-renderizan o regeneran según un cronograma
- Proyectos frontend-heavy donde el backend es una API de terceros (Stripe, Sanity, Shopify)
- Equipos que despliegan frecuentemente y necesitan previsualizaciones de rama para QA
- Cualquier cosa donde la latencia de arranque en frío es aceptable porque el tráfico es predecible y en ráfagas
El precio también es adecuado para estas cargas de trabajo. Una pequeña SaaS en el plan Pro a $20/mes tiene todo el sentido si tus funciones son de corta duración y sin estado.
La Restricción Serverless Innegable
Las funciones en Vercel tienen límite de tiempo. Por defecto es 10 segundos en el plan Hobby, hasta 300 segundos en Enterprise. Más importante aún, cada invocación está aislada. No hay memoria compartida entre solicitudes. No hay sistema de archivos persistente. No hay proceso de larga duración ejecutándose de fondo haciendo trabajo.
Para la mayoría de aplicaciones web, honestamente, eso está bien. Pero hay toda una categoría de cosas que simplemente no funcionan dentro de esas restricciones.
Dónde Serverless Empieza a Causarte Problemas
Allá por 2021, Seahawk tenía un proyecto fintech donde el cliente necesitaba feeds de transacciones en tiempo real empujados a un panel de control. El desarrollador original había intentado hacerlo un parche con polling cada dos segundos. Horrible. Necesitábamos WebSockets. Conexiones verdaderas, persistentes y con estado. Vercel quedó inmediatamente descartada.
Aquí es donde veo consistentemente que serverless llega a su límite:
- Conexiones WebSocket. Cualquier plataforma construida sobre AWS Lambda debajo no puede mantener un socket abierto. Sin excepciones. Any platform built on AWS Lambda underneath cannot hold a socket open. Full stop.
- Trabajos en segundo plano y colas. Si necesitas un worker que se despierte cada 15 minutos para procesar una cola de trabajos, necesitas un proceso que persista. Vercel Functions no es eso. 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.
- Cálculos de larga duración. Generación de PDF, transcodificación de video, exportación de reportes grandes. Incluso con el límite de 300 segundos, estás parcheando la arquitectura en lugar de trabajar con ella. PDF generation, video transcoding, large report exports. Even with the 300-second limit, you're patching around the architecture rather than working with it.
- Almacenamiento en caché en memoria. Si usas algo como node-cache para almacenar datos en RAM entre solicitudes, ese caché se destruye después de cada invocación de función. Quemarás tu pool de conexiones de base de datos sin razón. 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. - Connection pooling de base de datos. Este les muerde constantemente a las personas. Los ORMs como Prisma abren una nueva conexión por cada llamada de función. En cualquier nivel de tráfico razonable agotarás tu límite de conexiones de Postgres. Terminas agregando PgBouncer o el connection pooler de Supabase como solución alternativa, que funciona, pero estás luchando contra la plataforma. 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.
Lo que Render Hace Bien
Render ejecuta procesos persistentes reales. Servicios web, workers en segundo plano, trabajos cron. Cuando tu proceso Node inicia, se mantiene activo. Eso significa estado en memoria, servidores WebSocket, trabajos de larga duración, todo funciona como esperarías en cualquier caja Linux.
El nivel gratuito es útil para entornos de staging (aunque hace cold-start después de 15 minutos de inactividad, lo cual es molesto). El plan Individual de $7/mes te da un servicio persistente sin cold starts, y el plan de $25/mes aumenta la RAM y te da acceso SSH, que uso constantemente para debuggear.
Precios Que Tienen Sentido para Servicios Backend
Para un API backend que no necesita escala masiva, Render es notablemente predecible en costos. Pagas por la instancia, no por invocación. Eso importa cuando tienes un servicio haciendo trabajo constante y consistente. En Vercel, una función que se ejecuta miles de veces por hora suma de maneras que te sorprenden. En Render, es una tarifa fija mensual.
Hice una comparación el año pasado para un cliente que tenía un API Node.js promediando unos 50k requests por día. Su factura de Vercel había llegado a £180/mes. Movimos el API a una instancia de Render de $25, la conectamos a su frontend existente en Vercel, y el hosting del backend bajó a £25. El frontend se quedó en Vercel porque es ahí donde Vercel pertenece.
La Arquitectura que Realmente Uso Ahora
Después de construir suficientes de estas, he llegado a un modelo mental bastante claro. No es uno u otro.
- Frontend (Next.js, Astro, lo que sea) va en Vercel. Previews por rama, CDN edge, rollbacks instantáneos. Sin discusión.
- Cualquier backend con estado, API con conexiones persistentes, o proceso worker va en Render.
- Postgres o MySQL en Railway o el Postgres administrado de Render, dependiendo del presupuesto.Railway or Render's own managed Postgres, depending on budget.
- Redis en Upstash si es uso compatible con serverless, o una instancia de Render Redis si la app necesita garantías de persistencia.
Este split me tomó vergonzosamente mucho tiempo alcanzar. Por un tiempo intenté hacer que todo entrara en Vercel porque la DX es tan agradable. Pero luchar contra las limitaciones de la plataforma te cuesta más tiempo del que la conveniencia ahorra.
Conectando Frontend de Vercel a un Backend de Render
Técnicamente es directo. Configuras tu variable de entorno NEXT_PUBLIC_API_URL en Vercel hacia tu URL del servicio en Render, manejas CORS del lado de Render, y básicamente es eso. Render te da un subdominio estable de entrada (yourservice.onrender.com) y puedes adjuntar un dominio personalizado sin problema.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.
Una cosa a vigilar: los servicios del plan gratuito de Render se duermen después de 15 minutos de inactividad. Si tu frontend está en Vercel y tu backend está en un servicio gratuito de Render, los usuarios ocasionalmente golpearán un cold start de 30 segundos mientras el contenedor de Render se despierta. Para producción, simplemente paga el plan de $7. No vale la pena el daño a la experiencia del usuario.
Escenarios Específicos y Lo Que Yo Realmente Elegiría
Déjame ser directo aquí, porque es donde la mayoría de posts de comparación se vuelven vagos.
Escenario 1: sitio de marketing Next.js con formulario de contacto. Vercel. Obvio. ISR para las páginas de contenido, una ruta API simple para el formulario que llama a SendGrid. No hay razón para introducir Render. Vercel. Obviously. ISR for the content pages, a simple API route for the form that calls SendGrid. No reason to introduce Render.
Escenario 2: app SaaS con una API REST Node/Express, Postgres, y trabajos en segundo plano ocasionales. Frontend en Vercel, API backend en Render (plan de $25), Postgres en la base de datos gestionada de Render. Trabajos en segundo plano como Render Background Workers. Probablemente mi configuración más común en este momento. 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.
Escenario 3: app colaborativa en tiempo real usando Socket.io. Render, punto final. Necesitas un proceso persistente. Realmente inclinaría hacia un servicio de Render con al menos 512MB de RAM para una app Socket.io que haga cualquier cosa interesante. 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.
Escenario 4: frontend simple de WordPress sin cabeza. Vercel. Next.js con ISR extrayendo de WPGraphQL. El "backend" es WordPress, Render no entra en la ecuación. Vercel. Next.js with ISR pulling from WPGraphQL. The "backend" is WordPress, Render doesn't enter the picture.
Escenario 5: app FastAPI o Django en Python. Render. Vercel tiene soporte de runtime de Python pero es limitado y constantemente golpearás el techo de duración de la función. Render simplemente ejecuta tu proceso de Python como un servidor 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.
El Problema del Cold Start, Honestamente
La gente habla de los cold starts de Vercel como si fueran un inconveniente menor. Para la mayoría de cargas de trabajo frontend, lo son. Pero he visto funciones de Vercel tardar 3-4 segundos en arrancar en frío en el plan Hobby cuando tienes dependencias pesadas empaquetadas. Esa es una experiencia terrible para un usuario.
Los niveles no gratuitos de Render no tienen cold starts en absoluto. Tu proceso está activo. Los cold starts de AWS Lambda son la razón subyacente por la que Vercel tiene este problema, ya que las funciones de Vercel se ejecutan en Lambda bajo el capó. No es exactamente culpa de Vercel, es un compromiso del modelo 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.
Para APIs sensibles a la latencia, especialmente cualquier cosa orientada al usuario que se ejecute en cada solicitud, un servidor persistente en Render a menudo se siente más rápido en la práctica aunque las especificaciones brutas se vean comparables.
Cuando ninguno es la opción correcta
Si estás ejecutando algo que necesita escalar horizontalmente a docenas de instancias bajo demanda, probablemente estés buscando ECS en AWS, Google Cloud Run o Fly.io. El autoescalado de Render existe pero no es tan granular como te gustaría para tráfico genuinamente variable. Vercel obviamente escala horizontalmente por defecto ya que cada invocación de función es independiente.
Fly.io merece una mención aquí. Es conceptualmente más cercano a Render (VMs persistentes) pero con mejor distribución global y más control. Lo he usado para aplicaciones sensibles a la latencia donde necesitaba instancias en regiones específicas. Un poco más de overhead de DevOps que Render aunque.
FAQ
¿Render es más lento que Vercel para hosting frontend?
Para hosting de frontend puro, sí, en general. La CDN de Vercel está optimizada específicamente para esto. El hosting de sitios estáticos de Render funciona bien pero no tiene el mismo alcance de red edge. Si estás alojando un frontend, Vercel gana en velocidad de entrega.
¿Puedo ejecutar una aplicación Next.js en Render?
Puedes. Render soporta Node.js, así que puedes ejecutar next start en un servicio web de Render. Pierdes cosas como el ISR funcionando de la manera que Vercel lo maneja de forma nativa, y no obtendrás deployments de vista previa listos para usar. Para una aplicación Next.js, Vercel sigue siendo la mejor opción a menos que tengas razones específicas para evitarlo.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.
¿Vercel funciona con WebSockets?
No en el sentido tradicional. Vercel tiene algo de soporte para conexiones de larga duración mediante sus características de streaming más recientes, pero no es un sustituto para un servidor WebSocket adecuado. Si tu aplicación depende de socket.io o una librería similar con conexiones con estado, ejecutala en Render o Fly.io.socket.io or a similar library with stateful connections, run it on Render or Fly.io.
¿Qué hay de Netlify? ¿Por qué no lo mencionas mucho?
Netlify está bien. Está efectivamente en la misma categoría que Vercel para esta conversación: funciones serverless, CDN, excelente para frontends estáticos y SSR. Las mismas limitaciones de servidor persistente aplican. Simplemente uso más Vercel en Seahawk, así que ese es el análisis que puedo hacer honestamente.
¿Cómo influye el hosting de base de datos?
No ejecutes tu base de datos de producción en una instancia gratuita de Render. El Postgres gratuito en Render está bien para desarrollo y staging pero el límite de almacenamiento es ajustado y se suspende. Para producción típicamente uso el Postgres administrado pagado de Render ($7/mes iniciador) o Supabase si el cliente quiere Row Level Security y las herramientas de Supabase.
---
La versión corta: Vercel es una plataforma frontend que ejecuta código del lado del servidor. Render es una plataforma servidor que tiene una interfaz agradable. Una vez que internalizas esa distinción, la decisión para cualquier proyecto dado toma alrededor de treinta segundos. Usa ambos. Son genuinamente buenos en cosas diferentes y el costo de ejecutar una configuración híbrida es básicamente nada.