Rust vs Node.js: benchmark de backend e latência

Sharkbench é um projeto comunitário independente que mede três coisas: a capacidade de uma estrutura de lidar com solicitações HTTP simultâneas, operações de E/S e serialização JSON. O teste é executado no Docker/Linux em um Ryzen 7 7800X3D, com uma última atualização pública em 24 de agosto de 2025 (sharkbench.dev/web, acessado em 24 de agosto de 2026).

Fonte: Sharkbench, 24 de agosto de 2025 – Docker/Linux, Ryzen 7 7800X3D.

Axum — a estrutura que o Aurabase usa para seu núcleo Rust, verificado em Cargo.toml — processa 21.030 solicitações por segundo neste banco. Express, o framework Node.js mais utilizado em produção, processa 5.766 no mesmo hardware: um fator de 3,6. Este não é um caso isolado. As quatro estruturas Rust testadas estão todas dentro de uma faixa estreita de 18.000 a 22.000 req/s, enquanto as três estruturas Node.js testadas atingem um limite entre 5.766 e 9.340.

Na prática, “req/s” mede a taxa de transferência sob carga simultânea sustentada – e não a velocidade de uma solicitação isolada em um site de baixo tráfego. Para um endpoint chamado uma vez a cada poucos segundos, a diferença nunca é vista. Torna-se decisivo em um endpoint ativo — um fluxo em tempo real, uma API pública com tráfego pesado, um trabalho que reúne milhares de chamadas — onde o número de solicitações processadas por núcleo de CPU, para hardware igual, define diretamente a conta da infraestrutura.

A latência média segue a mesma hierarquia nesta bancada: 1,4 a 1,7 ms para os frameworks Rust testados, em comparação com 3,4 a 5,5 ms para os frameworks Node.js testados.

Fonte: Sharkbench, 24 de agosto de 2025 – latência média, não p99.

Este número é uma média, não um p99. As pausas de lixo em um tempo de execução gerenciado afetam principalmente a fila de despacho — as solicitações mais lentas, não a mediana. Este é o assunto de um artigo dedicado nesta série: por que a ausência do coletor de lixo altera a latência p99.

Rust gerencia a memória por propriedade, verificada em tempo de compilação – nenhum coletor de lixo rodando em segundo plano e interrompendo a execução. O Rust Book oficial resume da seguinte forma: “Nenhum dos recursos de propriedade irá desacelerar seu programa enquanto ele está em execução” (The Rust Programming Language, doc.rust-lang.org, acessado em 24 de agosto de 2026). A memória é liberada assim que a variável que a possui sai do escopo — um tempo conhecido em tempo de compilação, não uma pausa imprevisível em tempo de execução.

fn main() {
    let data = String::from("réponse API"); // `data` possui a string
    process(data); // posse sai daqui
    // `data` não é mais válido aqui - sem ponteiro pendente, sem liberdade dupla
} // `data` é liberado aqui, de forma determinística

fn process(s: String) {
    println!("{s}");
} // `s` sai do escopo aqui: liberação imediata, sem passagem de coleta de lixo

O Node.js, por outro lado, é executado em um único thread JavaScript e delega operações de E/S ao kernel por meio de um loop de eventos multifásico (temporizadores, retornos de chamada diferidos, pesquisa, verificação...) - mas qualquer cálculo síncrono nesse thread, incluindo uma passagem de coleta de lixo do mecanismo V8, bloqueia a execução enquanto ele é executado (documentação oficial do Node.js, nodejs.org, acessado em agosto 24, 2026). Esta é uma diferença no modelo de memória, não um detalhe de implementação.

O resultado mais contra-intuitivo da mesma bancada não diz respeito ao Rust: diz respeito ao próprio Node.js. Express - o mesmo código, a mesma API - vai de 5.766 req/s no Node.js para 18.917 req/s no Bun, um fator de ×3,3, sem alterar uma linha de código do aplicativo (Sharkbench, 24 de agosto de 2025).

Fonte: Sharkbench, 24 de agosto de 2025 – mesmo código Express, três tempos de execução JavaScript.

No Deno, esse mesmo código Express atinge 6.088 req/s – próximo ao Node.js, longe do Bun. A linguagem JavaScript é idêntica nos três casos; É o tempo de execução — seu mecanismo JS, sua implementação de loop de eventos, sua coleta de lixo — que muda o jogo. Comparar “Rust” com “Node.js” sem especificar o tempo de execução, versão e estrutura é como comparar configurações, não idiomas.

TechEmpower Framework Benchmarks ilustra a mesma ideia em uma escala maior. Seu repositório de código aberto foi atualizado em 24 de março de 2026, e sua rodada mais recente (rodada 23) foi objeto de uma postagem datada de 16 de março de 2026 (TechEmpower, acessado em 24 de agosto de 2026). Este projeto executa muitos tipos de testes em centenas de implementações, precisamente porque um único teste nunca representa um framework, muito menos uma linguagem.

A Convex, player no mercado de bancos de dados, formulou a posição mais clara sobre o assunto: recusar-se a participar da “guerra de gráficos de barras” de marketing entre bancos de dados concorrentes, considerada enganosa. “É escalar o teatro, não escalar”, escreve a equipe (Convex, acessado em 24 de agosto de 2026). Compartilhamos esta leitura: um número simples, sem metodologia publicada, não prova nada – nem para um concorrente, nem para nós.

O que isso muda em termos concretos: hardware (CPU, RAM), versão exata da estrutura e tempo de execução, tamanho da carga JSON, nível de competição e duração do teste, tudo varia na classificação – às vezes mais do que a escolha da linguagem em si. Um banco que não publica esses parâmetros não reproduz, portanto não se verifica — veja nossa metodologia completa e reproduzível para benchmarking de um backend.

O backend principal do Aurabase é escrito em Rust, em axum e tokio - verificado no Cargo.toml do monorepo: dez serviços (aura-gateway, aura-auth, aura-db…) compartilham a mesma dependência de espaço de trabalho axum (0.8) e o mesmo tempo de execução tokio, na edição 2021. O gateway que roteia o tráfego do plano de dados e do plano de gerenciamento depende de hyper além de axum - os detalhes completos estão em nosso artigo sobre a arquitetura do plano de dados/plano de gerenciamento do gateway. A estrutura do espaço de trabalho Cargo que suporta esses dez serviços está documentada em nosso artigo sobre o espaço de trabalho Cargo.

O que ainda não temos é um número publicado de taxa de transferência ou latência do Aurabase com metodologia e hardware documentados. Isto é deliberado: preferimos publicar a metodologia antes da figura e não o contrário — este é o assunto de um artigo futuro nesta série.

Para a comparação completa da arquitetura - núcleo Rust unificado na Aurabase versus pilha heterogênea Elixir/Go/TypeScript/Node documentada em um concorrente direto - veja nossa comparação detalhada Aurabase vs Supabase. Se você já estiver migrando um projeto, o guia de migração Supabase para Aurabase cobre o esquema, as políticas RLS e o SDK.

Todas as linhas citadas neste artigo, conforme publicado pelo Sharkbench em 24 de agosto de 2025 (Docker/Linux, Ryzen 7 7800X3D).

Cite estes dados: Sharkbench, “Web Framework Benchmarks,” sharkbench.dev/web, atualizado pela última vez em 24 de agosto de 2025.

Na bancada citada aqui, todas as estruturas Rust são executadas em uma faixa estreita - 18.000 a 22.000 req/s, 1,4-1,7 ms - muito à frente das estruturas Node.js no próprio Node.js (5.766-9.340 req/s, 3,4-5,5 ms). Mas o tempo de execução muda a situação tanto quanto a linguagem: Express on Bun quase alcança Axum on Rust.

Se você avaliar um back-end apenas com base no desempenho bruto, exija a metodologia antes do número: hardware, versão, tamanho da carga útil, nível de competição. A Aurabase ainda não divulgou seus próprios números; quando isso acontecer, a metodologia virá em primeiro lugar.