SSD SATA ou NVMe para programar: quando vale a pena

Você trocou o HD por um SSD e o computador mudou de vida. Agora está pensando em trocar o SSD SATA por um NVMe e espera outra transformação. Pode acontecer, ou você pode gastar dinheiro e não notar diferença nenhuma no dia a dia. A diferença entre os dois é real, mas o momento em que ela importa para quem programa é muito mais específico do que os números da caixa sugerem.

O resumo, antes dos detalhes:

O que separa SATA e NVMe

A diferença começa na interface. O SATA III trafega a 6 Gb/s com codificação 8b/10b, o que dá um teto de 600 MB/s; na prática, os SSDs SATA param perto de 550 MB/s em leitura sequencial. Por cima dele roda o AHCI, o protocolo pensado para HDs rotacionais. A especificação do AHCI 1.3.1, da Intel, define uma lista de comandos por porta com no máximo 32 entradas (os "command slots"), e o Native Command Queuing também vai até 32. Ou seja: uma fila, 32 comandos. Para um HD com uma cabeça de leitura, era mais que suficiente.

O NVMe foi desenhado para flash, direto sobre o barramento PCIe. Em vez de uma fila, o protocolo permite até cerca de 64 mil filas de I/O, cada uma com até cerca de 64 mil comandos (a comparação "1 fila, 32 comandos" contra "64K filas, 64K comandos por fila" está na visão geral do NVMe apresentada no workshop da OpenFabrics em 2013). Ninguém usa tudo isso; o ponto é que cada núcleo da CPU pode ter a sua fila e falar com o SSD sem disputar lock com os outros, e o SSD recebe trabalho em paralelo suficiente para ocupar todos os chips de flash ao mesmo tempo.

As velocidades sequenciais seguem a geração do PCIe. Fazendo a conta com a taxa de cada geração e a codificação 128b/130b, quatro lanes dão cerca de 3,9 GB/s no Gen3, 7,9 GB/s no Gen4 e 15,8 GB/s no Gen5. Os drives chegam perto: Gen3 bons ficam em ~3.500 MB/s, Gen4 em ~7.000 MB/s, e o Samsung 9100 PRO, um Gen5, é anunciado com até 14.800 MB/s nas versões de 4 e 8 TB. No papel, é mais de 25 vezes o SATA. Na sua rotina, outra história.

Quanto disco um build usa de verdade

A velocidade do armazenamento só aparece quando o gargalo é o armazenamento. Para medir isso em vez de chutar, compilei o Redis 7.2.5 (cerca de 1.600 arquivos de código, incluindo as dependências jemalloc, Lua e hiredis) num container Debian, com o cache de páginas do kernel limpo antes de cada build (echo 3 > /proc/sys/vm/drop_caches) e lendo os contadores pgpgin e pgpgout do /proc/vmstat:

cold build 20.08s  read_MB=93  written_MB=336
cold build 19.98s  read_MB=95  written_MB=336

Em 20 segundos de build, o disco entregou uns 94 MB de leitura (código-fonte, compilador, bibliotecas) e recebeu 336 MB de escrita (objetos e binários). Mesmo no teto do SATA, isso daria menos de um segundo de leitura, e a escrita vai primeiro para o cache em RAM e é descarregada em segundo plano. Em três rodadas, o build com cache frio e o build com tudo já em memória ficaram a no máximo 6% um do outro (de 21,1 a 23,1 segundos frio, de 20,6 a 21,7 quente, num segundo lote de medições só de tempo).

Os limites desse teste, para você não generalizar demais: rodei num notebook com Intel Core Ultra 7 255HX e SSD NVMe, dentro da VM do Docker Desktop (WSL 2), e não tinha um SSD SATA para comparar direto. O que o teste mostra é o volume de I/O de um build C de porte médio: pequeno demais para o SSD ser o gargalo. Um monorepo gigante, um build Rust com centenas de crates ou um projeto C++ enorme leem e escrevem muito mais, e aí vale repetir a medição no seu caso. Na maioria dos builds, quem manda é a CPU; o post sobre núcleos e threads de CPU explica por quê.

Quando o NVMe faz diferença

Cópias e arquivos grandes. Mover dezenas de gigabytes, restaurar um dump de banco, puxar e extrair imagens Docker pesadas, clonar um repositório com histórico enorme. Aqui a leitura e a escrita sequenciais aparecem direto no relógio.

Muitas operações pequenas em paralelo. Um PostgreSQL local sob teste de carga, vários containers gravando log ao mesmo tempo, um npm install num monorepo grande. É onde as filas do NVMe e a latência menor por operação pesam mais que a velocidade sequencial.

Swap quando a RAM acaba. Se a memória estoura, o sistema passa a usar o disco como extensão dela. Com NVMe, a degradação é menos dolorosa que com SATA, mas continua sendo degradação: o problema real é falta de RAM, como mostra o post sobre como funciona a memória RAM.

Onde SATA e NVMe empatam: abrir aplicativos já usados, rodar o servidor de desenvolvimento (pnpm dev, flask run), editar código, navegar. O sistema operacional mantém em RAM tudo que foi lido recentemente, e o armazenamento nem é consultado.

Latência: o número que não vai na caixa

Velocidade sequencial é o que o fabricante anuncia. Para banco de dados e para o compilador abrindo centenas de arquivos pequenos, o que conta é a latência de cada leitura aleatória. Aqui o NVMe ganha por arquitetura: não há controlador SATA nem AHCI no caminho, o comando vai da fila do núcleo direto para o SSD. A ordem de grandeza é de dezenas de microssegundos por leitura aleatória em SSDs SATA e um pouco menos em NVMe, e os melhores NVMe ficam abaixo disso; os valores exatos variam muito de modelo para modelo, então desconfie de qualquer número único.

Uma pessoa na frente da tela não percebe a diferença entre 30 e 80 microssegundos. Uma carga com milhares de operações por segundo percebe.

M.2 não é NVMe: como saber o que você tem

M.2 é um formato físico, não um protocolo. Um slot M.2 pode aceitar SSD SATA, NVMe ou os dois, dependendo da placa-mãe. Em geral, SSD M.2 NVMe tem a chave M (um recorte no conector) e SSD M.2 SATA tem as chaves B+M (dois recortes), mas a palavra final é do manual da placa ou do notebook, que diz o que cada slot suporta. Um SSD SATA num slot M.2 funciona... na velocidade do SATA.

Para conferir o que já está instalado:

# Linux: a coluna TRAN mostra sata ou nvme
lsblk -d -o NAME,TRAN,ROTA,MODEL

# Linux, com o pacote nvme-cli instalado
sudo nvme list

# Windows: BusType mostra NVMe, SATA ou SAS
Get-PhysicalDisk | Select-Object FriendlyName, BusType, MediaType, Size

No Windows, o Gerenciador de Dispositivos também mostra o modelo em "Unidades de disco"; com o modelo, a página do fabricante diz se é SATA ou NVMe e de qual geração.

A decisão prática para quem programa

Comprando máquina nova: NVMe é o padrão em praticamente qualquer notebook ou desktop atual, e não há motivo para escolher SATA num equipamento novo. Se a dúvida é qual máquina comprar, o post sobre como escolher notebook para programação coloca o SSD na ordem certa de prioridade.

Atualizando uma máquina com SATA: descubra o gargalo antes. Com menos de 16 GB de RAM e Docker, navegador e IDE abertos, mais memória rende muito mais que trocar o SSD. Se a RAM já sobra e a lentidão aparece em cópias grandes ou bancos locais, o NVMe compensa, desde que a placa tenha slot compatível.

Desenvolvimento web típico (Node, Python, alguns containers, editor, navegador): SATA dá conta. O armazenamento quase nunca é o gargalo nessa carga.

Perguntas frequentes

NVMe melhora o tempo de compilação?

Pouco, na maioria dos projetos. No build do Redis que medi, o disco movimentou cerca de 430 MB em 20 segundos, e o build com cache frio ficou dentro de 6% do build com tudo em memória. A compilação é limitada pela CPU; o armazenamento só começa a aparecer em projetos muito grandes. Meça o seu antes de comprar: se o build com cache quente é tão lento quanto o frio, o SSD não é o problema.

Vale a pena colocar NVMe num notebook que hoje usa SATA?

Se o notebook tem slot M.2 com suporte a NVMe, pode valer, principalmente se você faz cópias grandes ou roda bancos localmente. Se ele só tem baia de 2,5" ou M.2 apenas SATA, não dá: um SSD SATA de boa qualidade é o upgrade possível. Antes de comprar, confira o manual e o preço por gigabyte no dia, porque a diferença de preço entre SATA e NVMe variou bastante nos últimos anos.

SSD NVMe esquenta mais que SATA?

Sim. Drives Gen4 e Gen5 sob carga sustentada esquentam o bastante para reduzir a velocidade (throttling) sem dissipação adequada. Desktops resolvem com dissipador no slot M.2. No uso típico de desenvolvimento, que não mantém o SSD em carga contínua por minutos, isso raramente aparece.

Como saber se o SSD é o gargalo?

No Linux, iostat -x 1 (pacote sysstat) mostra a fila média (aqu-sz) e o tempo de espera (r_await, w_await) por dispositivo. Não se guie só pelo %util: o próprio manual do iostat avisa que, em dispositivos que atendem pedidos em paralelo, como SSDs modernos, ele não reflete o limite real. Se o disco ficar ocioso a maior parte do tempo, o gargalo está em outro lugar. Quando o problema é falta de espaço, e não velocidade, o caminho é investigar o que encheu o disco.

Primeiro meça, depois troque

O NVMe é superior ao SATA em praticamente toda métrica técnica, das filas à latência. A pergunta é se o seu trabalho usa essa superioridade. Para escrever código, rodar servidor local e alguns containers, quase nunca: o build que medi movimentou poucas centenas de megabytes e foi limitado pela CPU. A troca que muda a percepção continua sendo sair do HD para qualquer SSD. De SATA para NVMe, compre se a medição mostrar disco ocupado; se mostrar RAM no limite, o dinheiro vai para memória.