Gatling vs k6: ¿simulaciones en la JVM o un binario Go?

Gatling y k6 son herramientas open source que guardan las pruebas de carga como código en tu repositorio, y cualquiera de las dos prueba bien una API HTTP bajo carga. Elige Gatling si tu equipo trabaja en Java, Kotlin o Scala, o si quieres un informe HTML después de cada ejecución sin configurar nada. Elige k6 si quieres un único binario de Go sin JVM, gRPC y pruebas de navegador de serie, y umbrales capaces de detener antes de tiempo una ejecución que falla.

Los datos de esta comparación Gatling vs k6 salen de la documentación y del repositorio de cada proyecto, comprobados el 9 de octubre de 2026.

¿Cuál es la diferencia entre Gatling y k6?

La mayor diferencia es el entorno de ejecución. Gatling corre en la JVM y escribes las pruebas con uno de sus SDK, mientras que k6 es un único programa compilado en Go que ejecuta JavaScript.

El README de Gatling menciona un SDK de Java para Java, Kotlin y Scala, que se ejecuta con un plugin de Maven, Gradle o sbt. Su SDK de JavaScript y TypeScript se instala con npm, y su herramienta de línea de comandos descarga GraalVM, así que incluso una simulación en JavaScript corre sobre una JVM.

k6 se instala como paquete o como binario independiente, sin ningún otro entorno de ejecución. También ejecuta directamente archivos .ts, y su soporte de TypeScript elimina los tipos sin comprobarlos (comprobado el 9 de octubre de 2026).

¿Cómo se escribe la misma prueba en cada herramienta?

Las dos herramientas pueden expresar la misma prueba en JavaScript. Gatling la llama simulación y describe la carga con un perfil de inyección, y k6 la llama script y describe la carga con un escenario y su executor.

Esta es una prueba en la que llegan diez usuarios nuevos por segundo durante cinco minutos, y que falla si el percentil 95 supera los 500 ms o si falla más del 1 % de las peticiones. Con el SDK de JavaScript de Gatling, basada en su tutorial de la primera simulación:

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),
    );
});

La misma prueba en k6, con el 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");
}

Se lanzan con npx gatling run y k6 run script.js.

¿Cómo modelan la carga Gatling y k6?

Las dos admiten modelos de carga abiertos y cerrados. En Gatling eliges con el método de inyección que llamas, y en k6 con el executor que configuras.

En Gatling, injectOpen recibe tasas de llegada como constantUsersPerSec, e injectClosed objetivos de concurrencia como constantConcurrentUsers. k6 tiene seis executors: los dos de tasa de llegada siguen el modelo abierto, y los otros cuatro el cerrado, en el que un usuario virtual solo empieza su siguiente iteración cuando termina la anterior.

Un escenario de k6 con tasa de llegada inicia las iteraciones desde un grupo de usuarios virtuales reservados de antemano, y cuando ese grupo se agota, k6 se salta iteraciones y las cuenta como iteraciones descartadas (comprobado el 9 de octubre de 2026). Nuestra guía sobre el modelo de carga abierto vs cerrado explica cuándo conviene cada uno.

¿Cómo deciden Gatling y k6 si una prueba ha pasado?

Las dos convierten los objetivos de rendimiento en un resultado de éxito o fallo con el que puede trabajar un pipeline de CI. Gatling comprueba sus objetivos cuando termina la ejecución, y k6 además puede detener una ejecución en cuanto se incumple un objetivo.

Las assertions de Gatling se evalúan después de la simulación, y una sola assertion fallida hace fallar la simulación y el build. Los thresholds de k6 terminan una ejecución fallida con un código de salida distinto de cero, y un threshold con abortOnFail detiene la prueba en el momento en que falla (comprobado el 9 de octubre de 2026).

¿Qué protocolos y pruebas de navegador cubre cada herramienta?

Las dos cubren HTTP y WebSockets de serie. Gatling añade Server-Sent Events y JMS, y k6 añade gRPC y sesiones reales de navegador.

Según el README de Gatling, gRPC, MQTT y GraphQL son componentes aparte con la Gatling Enterprise Component License, limitados sin Enterprise a cinco usuarios simultáneos y a pruebas de cinco minutos. k6 menciona HTTP/1.1, HTTP/2, WebSockets y gRPC como protocolos integrados, y suma otros mediante extensiones xk6 como Kafka y Redis.

Para pruebas de navegador, k6 tiene un módulo de navegador que controla un navegador basado en Chromium y recoge métricas del frontend. La documentación de Gatling no describe ningún motor de navegador: el Recorder de Gatling convierte una sesión de navegador o un archivo HAR en una simulación a nivel HTTP (comprobado el 9 de octubre de 2026).

¿Cómo se lanza una prueba más grande de lo que genera una máquina?

La edición open source de Gatling genera carga desde una sola máquina, y la ejecución distribuida requiere Gatling Enterprise. k6 puede repartir una prueba en un clúster de Kubernetes con el k6-operator, que es open source, o ejecutarla en Grafana Cloud k6.

La guía de instalación de Gatling pide una cuenta de Enterprise para la ejecución distribuida, que usa generadores de carga gestionados o ubicaciones privadas en tu propia cuenta de AWS, Azure, GCP o Kubernetes. El k6-operator reparte una prueba entre varias instancias de k6 dentro de un clúster (comprobado el 9 de octubre de 2026).

Hay un tercer camino para los scripts de k6. LoadFocus, que publica este sitio, ejecuta scripts de k6 en su propia infraestructura en la nube desde 25 regiones, con los usuarios y la duración tomados de la configuración de la prueba. Su validador de scripts avisa de que los escenarios con tasa de llegada se ejecutan allí con un número fijo de usuarios, así que un script de modelo abierto como el de arriba no mantiene su tasa de llegada en LoadFocus. LoadFocus no ejecuta simulaciones de Gatling, de modo que para Gatling el camino hacia más máquinas es Gatling Enterprise.

¿Qué informes obtienes?

Gatling genera un informe HTML después de cada ejecución sin configurar nada. k6 muestra un resumen en la terminal y puede producir un informe HTML desde su panel web integrado.

El informe HTML de Gatling muestra en gráficos los percentiles del tiempo de respuesta, los usuarios iniciados por segundo y las peticiones por segundo a lo largo de la prueba. k6 muestra un resumen al final de la prueba, y su panel web enseña gráficos en directo y exporta un informe HTML autónomo cuando defines K6_WEB_DASHBOARD_EXPORT.

¿Cuál deberías elegir?

Gatling encaja con equipos que trabajan sobre la JVM, y k6 con equipos que quieren un único binario y JavaScript. Los protocolos, las pruebas de navegador y el escalado deciden casi todos los demás casos.

Elige Gatling en lugar de k6 cuando tu equipo trabaje sobre la JVM y quiera pruebas en Java, Kotlin o Scala construidas con Maven, Gradle o sbt junto al código de la aplicación, cuando necesites JMS o Server-Sent Events, o cuando quieras un informe HTML después de cada ejecución sin configurar nada.

Elige k6 en lugar de Gatling cuando quieras un único binario en CI sin JVM que instalar, cuando tus pruebas necesiten gRPC o sesiones reales de navegador, cuando los thresholds deban detener antes de tiempo una ejecución que falla, o cuando pienses escalar en Kubernetes con un operator open source.

FAQ

¿Es Gatling más rápido que k6? No lo hemos medido nosotros, así que no vamos a nombrar un ganador. La comparación justa es el mismo escenario con las dos herramientas en tu propio hardware.

¿Puede Gatling ejecutar scripts de k6? No según la documentación de Gatling, que no describe ninguna forma de ejecutar scripts de k6. Los dos SDK usan API distintas y los conversores de Gatling cubren JMeter y LoadRunner, así que un script de k6 hay que reescribirlo como simulación de Gatling, incluso con el SDK de JavaScript.

¿Puede LoadFocus ejecutar pruebas de Gatling? No. LoadFocus ejecuta scripts de k6 y planes de prueba de JMeter. Para repartir una simulación de Gatling entre varias máquinas, usa Gatling Enterprise.

Lecturas relacionadas

• Pruebas de carga con Gatling: la herramienta JVM a fondo
• k6 vs Artillery: qué herramienta de pruebas de carga elegir
• Gatling vs JMeter: ¿pruebas como código o un plan en GUI?
• Gatling vs Locust: ¿simulaciones JVM o locustfiles Python?
• Pruebas de carga gRPC: herramientas, configuración, métricas

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.