Qual VPS combina com o que você vai rodar?

Loja rodando WooCommerce, Shopify self-hosted alternativo ou qualquer stack própria de checkout tem um padrão de consumo bem diferente de um site estático: tráfego não é constante, ele explode em promoção, Black Friday, ou quando uma campanha de anúncio bate. O problema não é a média de acessos — é o pico. Uma VPS dimensionada pra tráfego médio pode responder bem 350 dias por ano e travar exatamente nos dias em que a loja mais precisa estar de pé.

O Básico (4GB RAM, 4 vCPU) segura uma loja pequena em dia normal, mas com margem apertada: WooCommerce + PHP-FPM + MySQL + cache já consomem uma fatia relevante dessa RAM em repouso, sobrando pouco fôlego pra picos de carrinho simultâneo. Isso é o tipo de coisa que só aparece quando a loja mais precisa da VPS de pé — não em teste de carga tranquilo num dia qualquer.

O Performance (12GB RAM, 6 vCPU) dá a folga real pra absorver esse tipo de pico sem downgrade de performance na hora H, além de suportar melhor plugins de gateway de pagamento, integração com marketplace e automações de estoque que costumam rodar em paralelo numa operação de e-commerce mais séria.

Esse é o uso mais comum entre quem contrata a You Secure, e é onde a estimativa de RAM importa mais — porque o custo de errar pra baixo é instabilidade em produção, não só lentidão. A stack típica (n8n + PostgreSQL + Redis) já ocupa uma base de ~1,7GB a 2GB antes de conectar o primeiro número de WhatsApp. A partir daí, cada instância/sessão da Evolution API consome entre 150MB (uso majoritariamente texto) e 300MB (uso pesado de áudio, imagem e vídeo).

No Básico (4GB RAM), depois da base da stack sobra pouco espaço — dá pra rodar de 5 a 10 instâncias com folga, o que serve bem pra testes ou operação bem pequena. No Performance (12GB RAM), com cerca de 6GB livres depois da base, a faixa sobe pra 20 a 35 instâncias, dependendo de quanto do tráfego é texto versus mídia — essa é a faixa que cobre a maioria das operações reais de automação com WhatsApp. No Ultra (20GB RAM) a faixa chega perto de 50 instâncias, e é o plano que faz sentido pra quem roda múltiplos clientes na mesma VPS ou combina automação pesada com workflows de agente de IA rodando em paralelo no n8n.

Vale reforçar: esses números são estimativas baseadas no comportamento típico do Baileys e do n8n sob diferentes cargas, não um benchmark medido de produção ao longo de vários dias — o consumo real varia com o tipo de nó usado, tamanho de payload e quantos workers estão ativos em queue mode. Planeje pelo cenário mais conservador da sua faixa e monitore depois de subir a stack.

Guias específicos: VPS para n8n · VPS para Evolution API · Quantas instâncias cabem em 8GB · Quantos workflows por VPS

Site institucional puro — poucas páginas, sem carrinho, sem automação por trás — é a carga mais leve dos cinco casos aqui. O Básico (4GB RAM, 4 vCPU, 100GB NVMe) costuma sobrar pra esse cenário, inclusive com margem pra alguns plugins de contato, SEO e cache padrão.

O que realmente determina se o Básico aguenta ou não não é o número de visitantes — é o quanto de plugin bagunçado está instalado. Page builder pesado, plugin de formulário mal otimizado rodando query desnecessária a cada request, e principalmente WooCommerce ou qualquer plugin de e-commerce ligado "só por garantia" mesmo sem uso ativo, são o que de fato consome RAM em excesso num WordPress. Um site com 3 mil visitas/dia e plugins enxutos pesa menos que um site com 300 visitas/dia carregado de plugin ruim.

Se o site tiver e-commerce ativo, formulários com automação disparando webhook, ou múltiplos sites WordPress na mesma VPS (comum em agência), o Performance (12GB RAM) é o degrau seguinte — não porque o tráfego pediu, mas porque a soma de aplicações concorrentes pediu.

ChromaDB, Qdrant, pipeline de embeddings e inferência de modelo leve rodando localmente formam o cenário que mais demanda RAM entre os cinco — porque não é uma aplicação sozinha, são três rodando ao mesmo tempo e competindo pelo mesmo recurso: o modelo (ou runtime de inferência) carregado em memória, o banco vetorial indexando e servindo queries, e a aplicação (geralmente um n8n ou API própria) orquestrando tudo. Cada peça isolada já consome uma fatia relevante de RAM; a soma das três em paralelo é o que estoura planos menores.

Modelos de linguagem leves rodando sem GPU dependida de CPU consomem RAM proporcional ao tamanho do modelo carregado — mesmo modelos considerados "pequenos" facilmente passam de alguns GB só pra manter os pesos em memória, antes de processar qualquer requisição. Some a isso o índice do banco vetorial crescendo com o volume de embeddings armazenados, e a folga que sobrava no Performance (12GB) desaparece rápido.

O Ultra (20GB RAM, 8 vCPU) é o plano com headroom real pra essa combinação — RAM suficiente pra manter modelo, banco vetorial e aplicação rodando concorrentemente sem um sufocar o outro, e vCPU extra porque inferência sem GPU é CPU-bound.

Ver também: VPS para IA self-hosted

Postgres, MySQL ou Redis rodando como serviço dedicado pra outra aplicação (não embutido junto com ela) é o caso mais difícil de generalizar dos cinco, porque o consumo depende quase inteiramente de duas variáveis que só você conhece: tamanho do dataset e número de conexões simultâneas abertas ao mesmo tempo. Um Postgres com poucos GB de dados e baixa concorrência roda tranquilo em RAM modesta; o mesmo banco com dataset de dezenas de GB e um pool de conexões grande de múltiplas aplicações clientes pede muito mais.

A regra prática, em vez de um número fixo: banco de dados quer ter RAM suficiente pra manter o índice (e idealmente boa parte dos dados quentes) em memória — quando o índice não cabe em RAM, cada query passa a bater em disco com mais frequência e a latência sobe visivelmente, mesmo em NVMe. Se você já sabe o tamanho aproximado do seu dataset, uma referência de bolso é mirar RAM na mesma ordem de grandeza do índice mais os dados acessados com frequência, não do dataset total.

Pra a maioria dos backends de porte pequeno a médio — poucas aplicações clientes, dataset na casa de poucos GB — o Performance (12GB RAM) já dá folga. Datasets grandes ou muitas conexões concorrentes (múltiplas aplicações ou múltiplos clientes batendo no mesmo banco) empurram pro Ultra (20GB RAM).