Todos os artigos
98 artigos · atualizado semanalmente Veja nossas Ferramentas
Todos os artigos
Comparativos

SSD SATA vs NVMe: quando a diferença importa de verdade

NVMe é 12x mais rápido que SATA nos benchmarks — mas para a maioria dos devs, o storage raramente é o gargalo. Quando vale o upgrade e quando é dinheiro jogado fora.

SSD SATA vs NVMe: quando a diferença importa de verdade
COVER · Comparativos

Você trocou o HDD por um SSD e o computador ficou transformado. Agora está pensando em trocar o SATA pelo NVMe e espera outra transformação. Pode ser que aconteça — ou pode ser que você gaste R$ 400 e não note diferença nenhuma no dia a dia. A diferença entre os dois existe, é real, mas o quando ela importa para um desenvolvedor é muito mais específico do que os benchmarks de caixa de produto sugerem.

O que separa SATA e NVMe (sem exageros)

A diferença começa na interface — o canal pelo qual o SSD conversa com o restante do computador.

SATA III usa o mesmo protocolo criado para HDDs rotacionais. Limite teórico de 600 MB/s, limite prático de ~550 MB/s de leitura sequencial. Para o HDD que substituiu, era uma revolução. Para flash storage, é um gargalo herdado por compatibilidade.

NVMe (Non-Volatile Memory Express) foi projetado do zero para SSDs sobre o barramento PCIe. Sem o overhead de protocolo do SATA, sem o limite de fila de um único comando do antigo AHCI. Um NVMe PCIe Gen4 lê acima de 7.000 MB/s em sequencial. Gen5 já passa de 14.000 MB/s em drives high-end.

Comparação de velocidade de leitura sequencial (aproximado):
SSD SATA III:     ~550 MB/s
SSD NVMe Gen3:  ~3.500 MB/s
SSD NVMe Gen4:  ~7.000 MB/s
SSD NVMe Gen5: ~14.000 MB/s

A diferença em números é dramática. A diferença que você vai sentir abrindo o VS Code, compilando um projeto médio ou inicializando o sistema operacional é outra conversa.

Quando a diferença é real

A velocidade do storage só aparece quando o gargalo é o storage. E na maior parte do tempo, para quem escreve código, não é.

Onde NVMe faz diferença mensurável:

Transferência de arquivos grandes. Mover uma ISO de 8 GB entre partições, fazer backup de uma imagem Docker pesada localmente, sincronizar um repositório com histórico extenso pela primeira vez. Com NVMe, isso demora segundos. Com SATA, demora minutos.

Compilação de projetos grandes com paralelismo alto. O compilador escreve objetos intermediários em paralelo. Com make -j16 em um projeto C++ de escala razoável ou um build Rust com muitas crates, o I/O de disco começa a aparecer na medição. A diferença não é de 12x como a velocidade sequencial sugere — é de 20-40% em casos típicos — mas é consistente.

Ambientes com muita escrita simultânea. Docker rodando vários containers que escrevem logs agressivamente, banco de dados local em cargas de teste pesadas, ou npm install em um monorepo grande com scripts paralelos. NVMe mantém IOPS altos; SATA começa a saturar.

Swap/paging quando a RAM acaba. Se você ficou sem RAM (o post sobre como funciona a memória RAM explica quando isso acontece), o sistema operacional começa a usar disco como extensão de memória. Com NVMe, a degradação é muito menos dramática. Com SATA, é dolorosa. Com HDD, é insuportável.

Onde SATA é equivalente:

  • Abrir aplicações já usadas recentemente (em cache no SO)
  • Rodar o servidor de desenvolvimento local (pnpm dev, flask run, etc.)
  • Editar arquivos de texto, código, markdown
  • Navegação web com cache ativo
  • Uso geral do sistema operacional no dia a dia

O sistema operacional mantém um cache agressivo de leitura na RAM. Depois que um arquivo foi lido uma vez, ele fica em memória — o storage não é consultado. Para workloads que cabem no cache (a maioria do uso cotidiano de desenvolvimento), SATA e NVMe performam igual porque nenhum dos dois chega a ser o gargalo real.

O fator latência que os benchmarks ignoram

Velocidade sequencial é o número que vai na caixa do produto. Latência de acesso aleatório é o que importa quando você está rodando um banco de dados local com consultas pequenas, ou quando o compilador está lendo dezenas de arquivos-fonte em paralelo com padrões não-sequenciais.

SSDs SATA têm latência de 50-100 microsegundos para acesso aleatório. NVMe chega a 20-30 microsegundos nos mais rápidos, com alguns drives high-end abaixo de 10µs.

Essa diferença de latência raramente aparece em uso interativo — o humano na frente da tela não percebe 30 vs 80 microsegundos. Ela aparece em cargas com muitas operações pequenas em paralelo, especialmente bancos de dados.

Formatos físicos: M.2, PCIe, e a confusão do conector

Um detalhe que complica a conversa: M.2 é um formato físico, não um protocolo. Um slot M.2 pode rodar SATA ou NVMe dependendo do que a placa-mãe suporta e do drive instalado.

Há M.2 SATA (usa o protocolo SATA pelo conector M.2) e M.2 NVMe (usa PCIe pelo mesmo conector). Você pode colocar um drive SATA em M.2 e ele vai funcionar... com velocidade de SATA. O conector não define o protocolo.

Na prática, drives M.2 NVMe são o padrão em qualquer notebook ou desktop lançado nos últimos 3 anos. Drives SATA 2.5" ainda aparecem em upgrades de hardware antigo — notebooks que não têm slot M.2 ou desktops com múltiplos bays 2.5".

A decisão prática para dev em 2026

Se você está comprando hardware novo: NVMe PCIe Gen4 é o padrão e não custa mais que SATA de qualidade similar. Não faz sentido escolher SATA em hardware novo.

Se você está atualizando hardware existente com SATA: avalie o gargalo real. Se a máquina tem menos de 16 GB de RAM, adicionar RAM vai ter impacto muito maior que trocar o SSD. O pós citado sobre memória RAM ajuda a diagnósticar isso. Se a RAM já está confortável e você sente lentidão em builds pesados ou cópias grandes, o upgrade para NVMe faz sentido.

Se você usa a máquina para desenvolvimento web típico (Node, Python, algumas instâncias Docker, editor, browser): SATA é mais que suficiente. O gargalo quase nunca é o storage em cargas assim.

Perguntas frequentes

NVMe melhora o tempo de compilação?

Depende do projeto e do hardware paralelo. Em projetos menores (a maioria das aplicações web), a compilação é limitada por CPU — o storage mal aparece no perfil. Em projetos C++ grandes, Rust com muitas dependências, ou monorepos com build paralelo agressivo, NVMe reduz o tempo de compilação em 15-40% em relação a SATA — não 12x como a diferença de velocidade sugere, porque o compilador também gasta tempo em CPU, parsing e linking.

Vale a pena colocar NVMe em um notebook com SATA III?

Se o notebook tem slot M.2 que suporta NVMe, sim — em laptops mais antigos isso pode ser uma atualização significativa. Se tem apenas slot M.2 SATA ou apenas bay 2.5", não: o upgrade para um SSD SATA de qualidade faz mais sentido que forçar NVMe onde a placa-mãe não tem suporte.

SSD NVMe esquenta mais que SATA?

Sim, notavelmente. Drives Gen4 e Gen5 em cargas sustentadas geram calor suficiente para acionar throttling térmico sem dissipação adequada. Desktops geralmente resolvem com heatsinks no slot M.2; notebooks de performance já incluem. É um tradeoff real que afeta performance sustentada em transferências longas — mas não workloads típicas de desenvolvimento, que não mantêm o drive sob carga contínua por minutos.

Como saber se meu SSD está sendo o gargalo?

No Linux, iostat -x 1 mostra utilização e tempo de espera por dispositivo em tempo real. %util perto de 100 e await alto indicam saturação. No Windows, o Monitor de Recursos mostra o mesmo. Se o storage raramente passa de 30-40% de utilização, o gargalo está em outro lugar.

O que realmente importa

NVMe é superior ao SATA em praticamente toda métrica técnica. A questão é se essa superioridade importa para o que você faz. Para desenvolvimento cotidiano — escrever código, rodar servidor local, gerenciar containers Docker em quantidade razoável — SATA entrega o suficiente porque o storage nunca vira o gargalo.

A troca que muda mais a percepção continua sendo a mesma de dez anos atrás: sair de HDD para qualquer SSD. De SATA para NVMe, o impacto depende muito do workload específico.

Entender a hierarquia de memória do seu sistema, como explica o post sobre como funciona a memória RAM, costuma revelar que RAM insuficiente é a causa mais comum de lentidão que as pessoas atribuem erroneamente ao storage.

RD
Autor
Rafael Duarte
Desenvolvedor backend com passagem por fintech e SaaS B2B — trabalhou em times que escalaram APIs de zero a milhões de requisições. Carrega cicatrizes de produção suficientes para ter opiniões fortes sobre ferramentas, padrões e decisões de arquitetura. Não é acadêmico: leu a RFC do UUID quando precisou escolher entre v4 e v7 para uma tabela de alta escrita.
Ver perfil