Gatling vs k6: simulações na JVM ou um único binário Go?

Gatling e k6 são ferramentas open source que guardam os testes de carga como código no seu repositório, e qualquer uma das duas testa bem uma API HTTP sob carga. Escolha o Gatling se o seu time trabalha em Java, Kotlin ou Scala, ou quer um relatório HTML depois de cada execução sem configurar nada. Escolha o k6 se você quer um único binário Go sem JVM, gRPC e testes de navegador prontos para uso, e thresholds capazes de parar cedo uma execução que está falhando.

Os dados desta comparação Gatling vs k6 vêm da documentação e do repositório de cada projeto, conferidos em 9 de outubro de 2026.

Qual é a diferença entre Gatling e k6?

A maior diferença é o ambiente de execução. O Gatling roda na JVM e você escreve os testes com um dos SDKs dele, enquanto o k6 é um único programa compilado em Go que executa JavaScript.

O README do Gatling cita um SDK Java para Java, Kotlin e Scala, executado por um plugin de Maven, Gradle ou sbt. O SDK de JavaScript e TypeScript é instalado pelo npm, e a ferramenta de linha de comando dele baixa o GraalVM, então até uma simulação em JavaScript roda em uma JVM.

O k6 é instalado como pacote ou binário independente, sem nenhum outro ambiente de execução. Ele também roda arquivos .ts diretamente, e o suporte a TypeScript remove os tipos sem checá-los (conferido em 9 de outubro de 2026).

Como escrever o mesmo teste em cada ferramenta?

As duas ferramentas conseguem expressar o mesmo teste em JavaScript. O Gatling chama o teste de simulação e descreve a carga com um perfil de injeção, e o k6 chama de script e descreve a carga com um cenário e o executor dele.

Este é um teste em que dez novos usuários chegam a cada segundo durante cinco minutos, e a execução falha se o percentil 95 passar de 500 ms ou se mais de 1% das requisições falharem. No SDK de JavaScript do Gatling, baseado no tutorial da primeira simulação:

import {
  constantUsersPerSec, global, scenario, simulation,
} from "@gatling.io/core";
import { http } from "@gatling.io/http";

export default simulation((setUp) => {
  const api = http.baseUrl("https://staging.example.com");

  const users = scenario("API users")
    .exec(http("list users").get("/api/users"));

  setUp(users.injectOpen(constantUsersPerSec(10).during(300)))
    .protocols(api)
    .assertions(
      global().responseTime().percentile(95).lt(500),
      global().failedRequests().percent().lt(1),
    );
});

O mesmo teste no k6, com o executor constant-arrival-rate:

import http from "k6/http";

export const options = {
  scenarios: {
    api_users: {
      executor: "constant-arrival-rate",
      rate: 10,
      timeUnit: "1s",
      duration: "5m",
      preAllocatedVUs: 50,
    },
  },
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
}

Rode os dois com npx gatling run e k6 run script.js.

Como o Gatling e o k6 modelam a carga?

Os dois suportam modelos de carga abertos e fechados. No Gatling, a escolha vem do método de injeção que você chama, e no k6 vem do executor que você configura.

No Gatling, injectOpen recebe taxas de chegada como constantUsersPerSec, e injectClosed recebe metas de concorrência como constantConcurrentUsers. O k6 tem seis executors: os dois por taxa de chegada seguem o modelo aberto, e os outros quatro seguem o fechado, em que um usuário virtual só começa a próxima iteração quando a anterior termina.

Um cenário do k6 por taxa de chegada inicia as iterações a partir de um pool de usuários virtuais pré-alocados, e quando esse pool se esgota, o k6 pula iterações e as conta como iterações descartadas (conferido em 9 de outubro de 2026). Nosso guia sobre o modelo de carga aberto vs fechado explica quando usar cada um.

Como o Gatling e o k6 decidem se um teste passou?

Os dois transformam metas de desempenho em um resultado de aprovação ou reprovação que um pipeline de CI consegue usar. O Gatling verifica as metas quando a execução termina, e o k6 também consegue parar uma execução assim que uma meta é descumprida.

As assertions do Gatling são avaliadas depois da simulação, e uma única assertion com falha derruba a simulação e o build. Os thresholds do k6 encerram uma execução com falha com um código de saída diferente de zero, e um threshold com abortOnFail para o teste no momento em que falha (conferido em 9 de outubro de 2026).

Quais protocolos e testes de navegador cada ferramenta cobre?

As duas cobrem HTTP e WebSockets sem instalar nada a mais. O Gatling acrescenta Server-Sent Events e JMS, e o k6 acrescenta gRPC e sessões reais de navegador.

Segundo o README do Gatling, gRPC, MQTT e GraphQL são componentes separados sob a Gatling Enterprise Component License, limitados sem o Enterprise a cinco usuários simultâneos e a testes de cinco minutos. O k6 lista HTTP/1.1, HTTP/2, WebSockets e gRPC como protocolos nativos, e soma outros com extensões xk6 como Kafka e Redis.

Para testes de navegador, o k6 tem um módulo de navegador que controla um navegador baseado em Chromium e coleta métricas de frontend. A documentação do Gatling não descreve nenhum motor de navegador: o Recorder do Gatling transforma uma sessão de navegador ou um arquivo HAR em uma simulação no nível HTTP (conferido em 9 de outubro de 2026).

Como rodar um teste maior do que uma máquina consegue gerar?

A edição open source do Gatling gera carga a partir de uma única máquina, e execuções distribuídas exigem o Gatling Enterprise. O k6 consegue espalhar um teste por um cluster Kubernetes com o k6-operator, que é open source, ou rodá-lo no Grafana Cloud k6.

O guia de instalação do Gatling pede uma conta Enterprise para execuções distribuídas, que usam geradores de carga gerenciados ou locais privados na sua própria conta AWS, Azure, GCP ou Kubernetes. O k6-operator divide um teste entre várias instâncias do k6 em um cluster (conferido em 9 de outubro de 2026).

Existe um terceiro caminho para scripts k6. A LoadFocus, que publica este site, roda scripts k6 na própria infraestrutura de nuvem a partir de 25 regiões, com os usuários e a duração definidos nas configurações do teste. O validador de scripts da plataforma avisa que cenários por taxa de chegada rodam lá com um número fixo de usuários, então um script de modelo aberto como o de cima não mantém a taxa de chegada na LoadFocus. A LoadFocus não roda simulações do Gatling, então para o Gatling o caminho para mais máquinas é o Gatling Enterprise.

Que relatórios você recebe?

O Gatling gera um relatório HTML depois de cada execução sem configurar nada. O k6 mostra um resumo no terminal e consegue produzir um relatório HTML a partir do dashboard web embutido.

O relatório HTML do Gatling traz gráficos dos percentis do tempo de resposta, dos usuários iniciados por segundo e das requisições por segundo ao longo do teste. O k6 mostra um resumo no fim do teste, e o dashboard web dele exibe gráficos ao vivo e exporta um relatório HTML autocontido quando você define K6_WEB_DASHBOARD_EXPORT.

Qual escolher?

O Gatling combina com times que trabalham na JVM, e o k6 com times que querem um único binário e JavaScript. Protocolos, testes de navegador e escala decidem a maior parte dos outros casos.

Escolha o Gatling em vez do k6 quando o seu time trabalha na JVM e quer testes em Java, Kotlin ou Scala montados com Maven, Gradle ou sbt junto do código da aplicação, quando você precisa de JMS ou Server-Sent Events, ou quando quer um relatório HTML depois de cada execução sem configurar nada.

Escolha o k6 em vez do Gatling quando você quer um único binário na CI sem JVM para instalar, quando os seus testes precisam de gRPC ou de sessões reais de navegador, quando os thresholds devem parar cedo uma execução que está falhando, ou quando você pretende escalar no Kubernetes com um operator open source.

FAQ

O Gatling é mais rápido que o k6? Não medimos isso por conta própria, então não vamos apontar um vencedor. A comparação justa é rodar o mesmo cenário com as duas ferramentas no seu próprio hardware.

O Gatling consegue rodar scripts do k6? Não segundo a documentação do Gatling, que não descreve nenhuma forma de rodar scripts do k6. Os dois SDKs usam APIs diferentes e os conversores do Gatling cobrem JMeter e LoadRunner, então um script do k6 precisa ser reescrito como simulação do Gatling, mesmo com o SDK de JavaScript.

A LoadFocus consegue rodar testes do Gatling? Não. A LoadFocus roda scripts k6 e planos de teste JMeter. Para distribuir uma simulação do Gatling entre várias máquinas, use o Gatling Enterprise.

Leituras relacionadas

• Teste de carga com Gatling: análise da ferramenta JVM
• k6 vs Artillery: qual ferramenta de teste de carga escolher
• Gatling vs JMeter: testes como código ou plano na GUI?
• Gatling vs Locust: simulações na JVM ou locustfiles Python?
• Teste de carga gRPC: ferramentas, configuração e métricas

As afirmações técnicas deste artigo não foram revisadas de forma independente.