Quarkus y Micronaut en 2026: microservicios Java ligeros frente a Spring Boot

Spring Boot es el framework Java más usado del mundo, y con razón: tiene una comunidad enorme, una documentación excelente y funciona de maravilla para la mayoría de los proyectos. El problema es que nació antes de Kubernetes, antes del serverless, antes de que "escalar a cero" fuera algo que la gente exigiera por defecto.

Cuando un pod escala a cero y vuelve a arrancar, lo que más importa es el tiempo de arranque. Y aquí Spring Boot tiene un lastre histórico: en una aplicación media tarda entre 3 y 10 segundos en levantar. Con JVM calentada consume entre 300 y 500 MB de RAM. En un servidor dedicado eso no duele; en pods densamente empaquetados en un clúster de Kubernetes, multiplica el coste.

Quarkus (impulsado por Red Hat) y Micronaut (desarrollado por Object Computing) nacieron exactamente para resolver esto. No son alternativas a Spring porque Spring sea malo; son herramientas diseñadas desde cero para la nube, donde los tiempos de arranque y el consumo de memoria cuentan de verdad.

Quarkus: "Supersonic Subatomic Java"

El eslogan de Quarkus no es marketing vacío. La clave está en lo que hacen en tiempo de compilación: el escaneo de anotaciones, la inyección de dependencias y la generación de proxies, todo eso que Spring Boot resuelve al arrancar, Quarkus lo resuelve al compilar. El resultado es una aplicación que ya sabe exactamente qué clases necesita antes de ejecutar la primera línea.

Con JVM convencional, Quarkus arranca en torno a 500 ms y consume unos 120 MB de RAM, cifras que ya son competitivas con Spring Boot 3.x con virtual threads. Pero el salto real llega con GraalVM native image: arranque en menos de 50 ms y consumo de unos 35 MB. Para funciones serverless que se invocan con poca frecuencia, eso cambia por completo la ecuación económica.

El otro punto fuerte de Quarkus es el developer experience. El comando quarkus dev arranca un modo de desarrollo con hot reload en milisegundos, sin necesidad de reiniciar la aplicación, y expone una Dev UI en localhost:8080/q/dev donde puedes ver el estado de las extensiones, ejecutar queries de Panache o comprobar la configuración activa.

Extensiones de Quarkus

Quarkus trabaja con extensiones que ya tienen lista la configuración AOT y la compatibilidad con native image. Añadir soporte para Hibernate, PostgreSQL y Jakarta REST es una línea:

quarkus extension add quarkus-hibernate-orm quarkus-jdbc-postgresql quarkus-resteasy-reactive

Panache es la capa que Quarkus pone sobre Hibernate para simplificar el acceso a datos. Puedes usar el patrón Active Record directamente en la entidad:

public class Usuario extends PanacheEntity {
    public String nombre;
    public boolean activo;

    public static List<Usuario> findByActivo(boolean activo) {
        return list("activo", activo);
    }
}

Para el lado HTTP, RESTEasy Reactive implementa Jakarta REST sobre Mutiny, la librería reactiva de Quarkus, lo que te da I/O no bloqueante sin cambiar drásticamente la forma de escribir código.

Dev Services: infraestructura sin configurar nada

Una de las cosas que más agradecerás en el día a día es Quarkus Dev Services. Cuando arrancas con quarkus dev y tienes una extensión de base de datos configurada, Quarkus levanta automáticamente un container Docker con Postgres, MySQL o lo que toque, sin que tengas que hacer ningún docker run manual ni configurar localhost:5432 en el application.properties.

Lo mismo aplica para Kafka, Redis o Keycloak. La infraestructura de desarrollo se levanta sola y desaparece cuando paras la aplicación. Para equipos con desarrolladores nuevos o entornos de CI donde no quieres gestionar servicios externos, esto vale mucho.

Micronaut: inyección de dependencias sin reflexión

Micronaut toma un camino diferente al de Spring y al propio Quarkus para resolver el problema de la reflexión en runtime: usa procesadores de anotaciones (APT) en tiempo de compilación para generar directamente el código de inyección de dependencias. No hay reflexión en runtime, la inyección es tan rápida como código escrito a mano.

El resultado en arranque es comparable a Quarkus con JVM, y la compatibilidad con GraalVM native image está en el diseño desde el principio, no añadida después. La API es propia, similar en concepto a Spring pero sin Spring internamente:

@Singleton
public class UsuarioService {

    @Inject
    private UsuarioRepository repository;

    public List<Usuario> listarActivos() {
        return repository.findByActivo(true);
    }
}

@Controller("/usuarios")
public class UsuarioController {

    @Inject
    private UsuarioService service;

    @Get("/activos")
    public List<Usuario> activos() {
        return service.listarActivos();
    }
}

Micronaut también tiene buena integración con Groovy y Kotlin, no solo con Java. Si tu equipo trabaja en Kotlin para la JVM, Micronaut encaja bien. Y Micronaut Launch, su generador web de proyectos, es cómodo para arrancar una base nueva en segundos.

Quarkus vs Micronaut: las diferencias que importan

En términos de velocidad y consumo de RAM, los dos están en un nivel similar. Las diferencias reales son de enfoque y adopción:

• Quarkus usa CDI para inyección de dependencias y Jakarta REST para HTTP, los mismos estándares que ya conoces si vienes de Java EE o Spring. La curva de aprendizaje para un desarrollador Spring es bastante suave.
• Micronaut tiene su propia API. No es más difícil, pero es diferente, y en algunos edge cases la DI basada en APT es más eficiente que la de Quarkus.
• Quarkus tiene más adopción en 2026, un ecosistema de extensiones más amplio y el respaldo enterprise de Red Hat con soporte a largo plazo.
• Micronaut sigue siendo una opción sólida, especialmente si buscas algo agnóstico de vendor o si trabajas con Groovy o Kotlin.

Para la mayoría de proyectos nuevos en Java, Quarkus es la apuesta más segura por pura masa crítica de comunidad y extensiones disponibles.

Spring Boot 3.x con virtual threads: ¿sigue teniendo sentido migrar?

Spring Boot 3.x incorporó soporte para virtual threads de Project Loom, lo que cierra en buena parte la brecha de concurrencia con los frameworks reactivos. Ya no necesitas Reactor ni WebFlux para manejar muchas peticiones concurrentes con pocos threads reales.

Dicho esto, virtual threads no resuelven el tiempo de arranque ni el consumo de RAM en reposo. Si tienes funciones serverless que se invocan esporádicamente o pods que escalan a cero, Spring Boot sigue siendo más caro que Quarkus o Micronaut en esas métricas.

Para equipos que ya dominan Spring y tienen aplicaciones en producción: migrar a Quarkus no se justifica salvo que el coste de RAM sea un problema real o trabajes intensivamente con serverless. Para proyectos nuevos pensados para correr en contenedores ligeros o funciones cloud, Quarkus o Micronaut tienen una ventaja clara en el arranque frío.

Ciclo de desarrollo con Quarkus paso a paso

Crear un servicio nuevo con Quarkus CLI:

quarkus create app com.ejemplo:mi-servicio 
  --extension='resteasy-reactive,hibernate-orm-panache,jdbc-postgresql'

Arrancar en modo desarrollo:

quarkus dev

Desde ese momento tienes hot reload activo: editas una clase, Quarkus recompila solo lo necesario y el cambio está disponible en milisegundos sin reiniciar nada.

Para lanzar los tests:

quarkus test

Quarkus ejecuta los tests sin levantar la aplicación completa, usando JUnit 5 y sus propias anotaciones de test (@QuarkusTest). Los Dev Services también se activan en modo test, así que tienes Postgres disponible sin configurar nada.

Para compilar a nativo. Si tienes GraalVM instalado localmente:

quarkus build --native

Si no tienes GraalVM pero sí Docker, puedes compilar dentro de un contenedor:

quarkus build --native -Dquarkus.native.container-build=true

El binario resultante arranca en menos de 50 ms y no necesita JVM para ejecutarse. Puedes meterlo en una imagen Docker FROM scratch o FROM distroless y el tamaño final del contenedor ronda los 50-60 MB.

¿Cuándo elegir uno u otro?

Si vienes de Spring y quieres algo familiar: Quarkus. Si buscas el framework con más extensiones disponibles y mayor respaldo enterprise: Quarkus. Si trabajas con Kotlin o Groovy y prefieres algo sin vínculo con JBoss/Red Hat: Micronaut.

Si tu proyecto vive en un monolito Spring que funciona bien y no tienes restricciones de RAM ni serverless, no migres por modas. Pero si estás arrancando algo nuevo pensado para Kubernetes desde el día uno, merece la pena echarle un ojo a estas opciones antes de repetir la plantilla de siempre. Puedes ver cómo gestionar flujos complejos en Java en microservicios Java duraderos: de Spring Boot a Quarkus, y si te interesa combinar esto con inteligencia artificial, en Quarkus, Micronaut y las LLMs: microservicios de IA en Java tienes un punto de partida sólido.

Imagen: Pexels / Stanislav Kondratiev