Quanto de RAM um desenvolvedor realmente precisa?

A pergunta "quanto de RAM eu preciso?" tem uma resposta mais útil do que um número: descubra onde a sua memória acaba. Quase sempre ela acaba num lugar diferente do que o percentual de uso sugere.

A minha máquina de trabalho usa entre 70% e 85% da memória o dia inteiro. Olhando só esse número, parece uma máquina no limite. Não é. E a única vez que fiquei sem memória, a máquina tinha memória de sobra.

Para explicar isso, vou usar três máquinas: a minha e as de dois colegas de equipe. Os três trabalhamos nos mesmos projetos.

Três máquinas, os mesmos projetos

O ambiente de trabalho é o mesmo para os três: pelo menos dois projetos com banco de dados, Redis, fila e os serviços da aplicação rodando em Docker, além de IDE e navegador abertos. Ninguém roda modelo de IA local nem máquina virtual à parte.

	Minha máquina	Colega A	Colega B
Máquina	desktop, Intel Core i5-13600KF, macOS	MacBook, Apple M1	MacBook Pro, Apple M4
RAM	64 GB	16 GB	24 GB
Armazenamento	NVMe de 1 TB + SSD de 400 GB	256 GB	512 GB
IDE	VS Code, duas janelas ou mais	VS Code	PhpStorm
Memória dada ao Docker	24 GB	4 GB	8 GB
Pressão de memória	sempre verde, swap zerado	entre amarelo e vermelho	amarelo

Os dois colegas relatam a mesma coisa: não dá para trabalhar com muitas ferramentas abertas ao mesmo tempo.

A comparação não é um experimento controlado. A memória reservada ao Docker muda de uma máquina para outra, e o PhpStorm costuma ocupar mais memória que o VS Code. Mas o padrão é claro o bastante para ensinar alguma coisa.

O percentual de uso não diz o que você acha que diz

Um sistema operacional moderno não deixa memória parada. A RAM livre é usada como cache de arquivos, porque ler do cache é muito mais rápido do que ler do disco, e esse cache é liberado assim que um programa precisa do espaço. O macOS ainda comprime a memória que está parada antes de recorrer ao disco.

Por isso "85% em uso" pode ser uma máquina confortável que aproveita bem a RAM que tem. O percentual mede ocupação, não falta.

O que indica falta é outra coisa: o sistema precisando empurrar memória para o disco para abrir espaço. É isso que você sente como lentidão. E é isso que os indicadores certos mostram:

• macOS: no Monitor de Atividade, aba Memória, olhe o gráfico de pressão de memória e o swap usado. Verde é folga, amarelo é o sistema trabalhando para acomodar a carga, vermelho é falta.
• Windows: no Gerenciador de Tarefas, em Desempenho → Memória, compare a memória confirmada com o limite dela. Quando a confirmada se aproxima do limite, o sistema depende do arquivo de paginação.
• Linux: em free -h, a coluna que importa é available, não free. Em kernels com PSI habilitado, /proc/pressure/memory mostra quanto tempo os processos passam esperando memória.

A minha máquina opera entre 70% e 85% com pressão sempre verde e nenhum byte em swap. Ela não está apertada. Está usando a memória que tem.

A vez em que faltou memória com memória sobrando

Já vi aplicações morrerem por falta de RAM nessa máquina de 64 GB. Quem ficou sem memória não foi a máquina, foi o Docker.

No macOS e no Windows, o Docker Desktop roda os containers dentro de uma máquina virtual Linux, e essa máquina virtual tem um teto de memória que você define. O meu é 24 GB. Quando os containers de vários projetos somaram mais do que isso, o kernel da máquina virtual começou a encerrar processos para se proteger. Do lado de fora, o sistema operacional continuava com folga, e não tinha como emprestar essa folga para dentro.

A lição é que existem dois limites, não um. O limite da máquina e o limite que você deu ao Docker. Eles falham de jeitos diferentes: o primeiro aparece como lentidão generalizada, o segundo como um container morto enquanto todo o resto parece normal.

A minha resposta não foi aumentar o limite. Foi trabalhar com mais responsabilidade: no máximo dois ou três projetos com ambiente no ar ao mesmo tempo. Com 64 GB, esse limite é uma escolha minha, e eu poderia mudá-la.

Vale registrar que isso é específico de quem roda Docker dentro de uma máquina virtual. Com o Docker Engine rodando nativo no Linux, os containers dividem a memória do próprio sistema, e não existe esse segundo teto.

O custo de pouca RAM é o trabalho que você deixa de fazer

Com 16 GB, o colega A reservou 4 GB para o Docker. Com 24 GB, o colega B reservou 8 GB. Nenhum dos dois escolheu esses valores por achar que bastavam. Escolheram porque era o que cabia na máquina depois da IDE, do navegador e do próprio sistema.

E mesmo assim a pressão fica no amarelo, e no caso do colega A chega ao vermelho.

É aqui que a falta de memória costuma ser mal diagnosticada. Ela raramente aparece como um travamento. Aparece como um fluxo de trabalho que encolhe sem ninguém decidir isso: fechar o navegador para subir o ambiente, derrubar um projeto para abrir outro, evitar a ferramenta que ajudaria porque ela pesa. A máquina não quebra. Quem se adapta é você.

Nos notebooks com Apple Silicon há dois agravantes. A memória é unificada, ou seja, processador e GPU dividem o mesmo conjunto de RAM. E ela é soldada ao chip, sem possibilidade de ampliar depois da compra. A quantidade escolhida no dia da compra é a quantidade com que você vai trabalhar pelos próximos anos.

Como descobrir quanto você precisa

Não existe um número que sirva para todo desenvolvedor. Existe um método que serve para qualquer um.

1. Monte o seu pior dia normal. Não o dia médio, nem o dia excepcional. O dia em que você tem dois projetos no ar, a IDE, o navegador com a documentação e a ferramenta de banco de dados abertos ao mesmo tempo.
2. Observe a pressão, não o percentual. Com esse dia montado, veja a pressão de memória e o swap depois de uma ou duas horas de trabalho, não logo depois de abrir tudo.
3. Some o que roda junto, não o que está instalado. Uma ferramenta instalada que você abre uma vez por semana não entra na conta. Um container que fica no ar o dia inteiro entra.
4. Separe o limite do Docker do limite da máquina. Se o que morre são containers e a máquina está com folga, o problema é o teto da máquina virtual, e resolver isso não exige comprar nada.
5. Olhe para frente, principalmente se a RAM não puder ser ampliada. Projetos crescem, ferramentas pesam mais a cada versão, e hoje há quem rode modelos de IA localmente. Se a máquina já opera no amarelo, ela não vai melhorar com o tempo.

Os sinais que valem e os que não valem

Sinais de que falta memória de verdade:

• pressão de memória no amarelo ou vermelho durante o trabalho normal;
• swap crescendo ao longo do dia;
• lentidão ao alternar entre aplicações que já estavam abertas;
• você fechando ferramentas por hábito para conseguir trabalhar.

Sinais que parecem falta e não são:

• percentual de uso alto com pressão verde;
• muita memória em cache;
• um container morto por falta de memória enquanto o sistema está com folga. Aqui o limite a revisar é o do Docker, não o da máquina.

A pergunta que importa

As três máquinas mostram a mesma coisa de ângulos diferentes. Com 16 GB, o ambiente de trabalho foi reduzido para caber na máquina. Com 24 GB, cabe, mas sem folga. Com 64 GB, a máquina sobra, e o limite passa a ser uma configuração que você escolhe.

Para esse tipo de trabalho — vários serviços em containers, mais de um projeto e ferramentas pesadas abertas ao mesmo tempo —, a diferença entre as três configurações não aparece em benchmark. Aparece no que cada pessoa consegue manter aberto.

Então, antes de perguntar quanto de RAM você precisa, pergunte onde a sua memória acaba e o que você deixa de fazer por causa disso. Se a resposta for "nada", você já tem o suficiente. Se for "fecho o navegador para subir o ambiente", o número que você procura está acima do que tem hoje.