Um cliente me ligou em pânico há dezoito meses atrás. Ele tinha lançado uma API Node.js no Vercel, tudo parecia bem durante os testes, e então a sua primeira carga concorrente real bateu e as conexões WebSocket simplesmente... caíram. Silenciosamente. Sem erro no dashboard, sem alerta, nada. Tive que explicar a ele que a plataforma que escolheram literalmente não consegue manter uma conexão persistente aberta. Não é um bug. É o ponto inteiro do serverless. Migramos para Render no final dessa mesma semana.
Essa história não é incomum. Vi isso uma dúzia de vezes na Seahawk Media. Desenvolvedores escolhem Vercel porque é genuinamente excelente no que faz, e depois colam um caso de uso que nunca foi projetado para isso e se perguntam por que tudo desmorona. Então aqui está meu raciocínio real sobre quando usar qual, baseado em projetos reais lançados, não em benchmarks em um blog.
No Que Vercel é Realmente Bom
Deixa eu ser claro: eu uso Vercel. Muito. Para sites de marketing, apps Next.js, frontends pesados em conteúdo onde a camada de API é fina, Vercel ainda é o jeito mais rápido de ir de um git push para uma URL live com um CDN na frente. A Vercel Edge Network é genuinamente impressionante para conteúdo estático e ISR. Deployments de preview são mágica para handoffs com clientes.Vercel Edge Network is genuinely impressive for static and ISR content. Preview deployments are magic for client handoffs.
Onde ela brilha, especificamente:
- Aplicações Next.js usando ISR ou SSG onde as páginas são pré-renderizadas ou regeneradas em um cronograma
- Projetos front-end intensivos onde o backend é uma API de terceiros (Stripe, Sanity, Shopify)
- Times que fazem deploy frequente e precisam de previews de branch para QA
- Qualquer coisa onde a latência de cold start é aceitável porque o tráfego é previsível e em rajadas
O preço também é adequado para essas cargas. Um pequeno SaaS no plano Pro a $20/mês faz todo sentido se suas funções são de curta duração e stateless.
A Restrição Serverless Que Você Não Pode Contestar
Functions no Vercel sofrem timeout. Por padrão são 10 segundos no plano Hobby, até 300 segundos no Enterprise. Mais importante ainda, cada invocação é isolada. Não há memória compartilhada entre requisições. Sem sistema de arquivos persistente. Sem processo de longa duração rodando em background fazendo trabalho.
Para a maioria das aplicações web, honestamente, tudo bem. Mas há uma categoria inteira de coisas que simplesmente não funcionam dentro dessas restrições.
Onde Serverless Começa a Prejudicá-lo
Em 2021, Seahawk tinha um projeto fintech onde o cliente precisava de feeds de transações em tempo real enviados para um dashboard. O desenvolvedor original havia tentado gambiarra isso com polling a cada dois segundos. Horrível. Precisávamos de WebSockets. Conexões adequadas, persistentes e stateful. Vercel foi imediatamente descartado.
É aqui que consistentemente vejo serverless bater no teto:
- Conexões WebSocket. Nenhuma plataforma construída sobre AWS Lambda por baixo consegue manter um socket aberto. Ponto final. Any platform built on AWS Lambda underneath cannot hold a socket open. Full stop.
- Jobs em background e filas. Se você precisa de um worker que acorda a cada 15 minutos para processar uma fila de jobs, você precisa de um processo que persista. Vercel Functions não são isso. 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.
- Computações de longa duração. Geração de PDF, transcodificação de vídeo, exports de relatórios grandes. Mesmo com o limite de 300 segundos, você está remendando a arquitetura em vez de trabalhar com ela. PDF generation, video transcoding, large report exports. Even with the 300-second limit, you're patching around the architecture rather than working with it.
- Cache em memória. Se você está usando algo como node-cache para armazenar dados em RAM entre requisições, esse cache é destruído depois de cada invocação de função. Você queimará seu pool de conexões de banco de dados à toa. 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 banco de dados. Esse é o que mais pega as pessoas. ORMs como Prisma abrem uma nova conexão por chamada de função. Em qualquer nível razoável de tráfego você esgotará seu limite de conexões Postgres. Você acaba adicionando PgBouncer ou o connection pooler do Supabase como workaround, o que funciona, mas você está lutando contra a 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.
O que Render Faz Bem
Render executa processos persistentes de verdade. Web services, workers em background, cron jobs. Quando seu processo Node inicia, ele fica de pé. Isso significa estado em memória, servidores WebSocket, jobs de longa duração, tudo funciona do jeito que você esperaria em qualquer box Linux.
A tier gratuita é útil para ambientes de staging (embora sofra cold-starts após 15 minutos de inatividade, o que é chato). O plano Individual de $7/mês oferece um serviço persistente sem cold starts, e o plano de $25/mês aumenta a RAM e oferece acesso SSH, que uso constantemente para debugging.
Preços que Fazem Sentido para Backend Services
Para uma API backend que não precisa de escala massiva, Render é notavelmente previsível em custos. Você paga pela instância, não por invocação. Isso importa quando você tem um serviço fazendo trabalho constante e consistente. No Vercel, uma função que roda milhares de vezes por hora se acumula de formas que te pegam desprevenido. No Render, é uma taxa fixa mensal.
Fiz uma comparação no ano passado para um cliente que tinha uma API Node.js processando cerca de 50k requisições por dia. A conta deles no Vercel tinha chegado a £180/mês. Movemos a API para uma instância Render de $25, conectamos ao frontend Vercel existente deles, e o hosting backend caiu para £25. O frontend continuou no Vercel porque é lá que o Vercel faz sentido.
A Arquitetura que Eu Realmente Uso Agora
Depois de construir o suficiente dessas, cheguei a um modelo mental bem claro. Não é nem um nem outro.
- Frontend (Next.js, Astro, o que for) vai no Vercel. Previews de branch, edge CDN, rollbacks instantâneos. Sem discussão.
- Qualquer backend com estado, API com conexões persistentes, ou processo worker vai no Render.
- Postgres ou MySQL no Railway ou no Postgres gerenciado do Render, dependendo do orçamento.Railway or Render's own managed Postgres, depending on budget.
- Redis no Upstash se for uso compatível com serverless, ou uma instância Render Redis se a app precisa de garantias de persistência.
Essa separação demorou embaraçosamente para eu chegar. Por um tempo estava tentando encaixar tudo no Vercel porque a DX é tão boa. Mas lutar contra as limitações da plataforma custa mais tempo do que a conveniência economiza.
Conectando Frontend Vercel a um Backend Render
Mecanicamente é direto. Você define sua variável de ambiente NEXT_PUBLIC_API_URL no Vercel para a URL do seu serviço Render, cuida do CORS no lado do Render, e é basicamente isso. O Render te dá um subdomínio estável de cara (yourservice.onrender.com) e você consegue anexar um domínio customizado facilmente.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.
Uma coisa para ficar de olho: os serviços do plano gratuito do Render hibernam depois de 15 minutos de inatividade. Se seu frontend está no Vercel e seu backend em um serviço Render gratuito, os usuários ocasionalmente vão bater em um cold start de 30 segundos enquanto o container do Render acorda. Para produção, é só pagar o plano de $7. Não vale o estrago na experiência do usuário.
Cenários Específicos e O Que Eu Realmente Escolheria
Deixa eu ser direto aqui, porque é onde a maioria dos posts de comparação fica vaga.
Cenário 1: Site de marketing em Next.js com formulário de contato. Vercel. Óbvio. ISR para as páginas de conteúdo, uma simples rota de API para o formulário que chama SendGrid. Nenhuma razão para introduzir Render. Vercel. Obviously. ISR for the content pages, a simple API route for the form that calls SendGrid. No reason to introduce Render.
Cenário 2: App SaaS com uma REST API Node/Express, Postgres, e occasional background jobs. Frontend no Vercel, backend API no Render (plano $25), Postgres no banco de dados gerenciado do Render. Background jobs como Render Background Workers. Esse é provavelmente meu setup mais comum agora. 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.
Cenário 3: App colaborativo em tempo real usando Socket.io. Render, ponto final. Você precisa de um processo persistente. Eu realmente inclinaria para um serviço Render com pelo menos 512MB de RAM para um app Socket.io fazendo qualquer coisa interessante. 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.
Cenário 4: Frontend WordPress headless simples. Vercel. Next.js com ISR puxando do WPGraphQL. O "backend" é WordPress, Render não entra na jogada. Vercel. Next.js with ISR pulling from WPGraphQL. The "backend" is WordPress, Render doesn't enter the picture.
Cenário 5: App Python FastAPI ou Django. Render. O Vercel tem suporte a runtime Python mas é limitado e você vai constantemente bater no teto de duração da function. O Render simplesmente executa seu processo Python como um 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.
O Problema do Cold Start, Sendo Honesto
As pessoas falam sobre cold starts do Vercel como se fossem um incômodo menor. Para a maioria das cargas de trabalho frontend, são mesmo. Mas já vi funções do Vercel demorarem 3-4 segundos para fazer cold start no plano Hobby quando você tem dependências pesadas agrupadas. Essa é uma experiência terrível para o usuário.
Os planos pagos do Render não têm cold start nenhum. Seu processo está sempre ativo. Cold starts do AWS Lambda são o motivo subjacente de Vercel ter esse problema, já que as funções do Vercel rodam em Lambda por baixo dos panos. Não é exatamente culpa do Vercel, é a trade-off do 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 sensíveis a latência, especialmente qualquer coisa user-facing que rode a cada requisição, um servidor persistente no Render geralmente se sente mais rápido na prática, mesmo que as especificações brutas pareçam comparáveis.
Quando Nenhuma É a Opção Certa
Se você está rodando algo que precisa escalar horizontalmente para dezenas de instâncias sob demanda, você provavelmente está olhando para ECS no AWS, Google Cloud Run, ou Fly.io. O autoscaling do Render existe, mas não é tão granular quanto você gostaria para tráfego genuinamente variável. Vercel escala horizontalmente por padrão, já que cada invocação de função é independente.
Fly.io merece ser mencionado aqui. É mais próximo do Render conceitualmente (VMs persistentes), mas com melhor distribuição global e mais controle. Já usei para apps sensíveis a latência onde eu precisava de instâncias em regiões específicas. Um pouco mais overhead de DevOps que Render, mas vale a pena.
FAQ
Render é mais lento que Vercel para hospedagem de frontend?
Para hospedagem de frontend pura, sim, geralmente. A CDN do Vercel é otimizada especificamente para isso. A hospedagem de sites estáticos do Render funciona bem, mas não tem o mesmo alcance de rede edge. Se você está hospedando um frontend, Vercel vence em velocidade de entrega.
Posso rodar um aplicativo Next.js no Render?
Você consegue. O Render oferece suporte a Node.js, então você pode rodar next start em um web service do Render. Você perde coisas como ISR funcionando do jeito que o Vercel lida nativamente, e não terá deployments de preview prontos para usar. Para um app Next.js, Vercel ainda é a melhor escolha a menos que você tenha razões específicas para evitá-lo.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.
O Vercel funciona com WebSockets?
Não no sentido tradicional. O Vercel tem algum suporte para conexões de longa duração via seus recursos mais novos de streaming, mas não é um substituto para um servidor WebSocket apropriado. Se seu app depende de socket.io ou uma biblioteca similar com conexões stateful, rode no Render ou Fly.io.socket.io or a similar library with stateful connections, run it on Render or Fly.io.
E quanto ao Netlify? Por que você não menciona muito?
Netlify é bom. Ele está efetivamente na mesma categoria do Vercel para essa conversa: funções serverless, CDN, ótimo para frontends estáticos e SSR. As mesmas limitações de servidor persistente se aplicam. Eu apenas uso mais o Vercel na Seahawk, então é a comparação sobre a qual consigo falar honestamente.
Como o database hosting entra nisso?
Não rode seu banco de dados de produção em uma instância free do Render. O Postgres free no Render é bom para desenvolvimento e staging, mas o limite de armazenamento é apertado e ele é suspenso. Para produção eu normalmente uso o Postgres gerenciado pago do Render ($7/mês starter) ou Supabase se o cliente quer Row Level Security e as ferramentas do Supabase.
---
A versão curta: Vercel é uma plataforma frontend que acontece de rodar código server-side. Render é uma plataforma de servidor que acontece de ter uma UI legal. Uma vez que você internaliza essa distinção, a decisão para qualquer projeto leva uns trinta segundos. Use ambas. Elas são genuinamente boas em coisas diferentes e o custo de rodar um setup híbrido é basicamente nada.