Un caso documentado en el blog oficial de GraalVM: trivago migró su gateway GraphQL a binarios nativos y bajó de 43 réplicas a 12.
Otro caso, publicado en el blog de AWS Open Source: Disney Streaming cortó sus cold starts de Lambda de 3.6 segundos a menos de 100 milisegundos con Native Image (mejora de ~36x, misma Lambda de 3.008 MB). Misma herramienta, gratis, open source, disponible hace años.
Y aun así, la mayoría de devs Java ni siquiera la ha probado.
¿Por qué?
Java tiene un punto débil histórico que todos conocemos: arranca lento y come memoria. Tu Spring Boot necesita 3-4 segundos para levantar y unos 400 megas de RAM. En serverless, esos 3 segundos son inaceptables. En Kubernetes, esos 400 megas significan menos pods por nodo. Durante años la respuesta fue "bueno, eso es Java, nada que hacer". O peor: "cámbiate a Go".
La buena noticia es que existe una herramienta de Oracle Labs que resuelve exactamente esto: GraalVM Native Image. Lo que hace es tomar tu aplicación Java y compilarla a un binario nativo, literalmente un ejecutable de máquina, como si fuera C o Rust. Sin JVM en runtime.
Te explico la mejora que trae con números, según los casos públicos de trivago (GraalVM Blog), Disney Streaming (AWS Open Source Blog), Java Code Geeks (octubre 2025) e inner-product.com:
- Arranque típico (benchmarks): de unos 3-4 segundos a ~37-100 milisegundos (rango documentado entre ~35x y ~100x según la app).
- Memoria RSS: típicamente de 400-450 MB a ~100 MB (~4x menos).
- Infraestructura (trivago): de 43 a 12 réplicas, de 15 a 5 cores de CPU.
- Lambda (Disney): de 3.6 s a menos de 100 ms en una función de 3.008 MB.
No paro de decirte cosas buenas de GraalVM, ¿no? Pues bueno, hablemos de sus trade-offs.
GraalVM arrastra "problemas" de compatibilidad que con los años han mejorado pero siguen existiendo.
Te explico: no todas las librerías sirven en GraalVM (aunque la mayoría sí), y en el video que subí hoy te cuento incluso cómo han creado categorías para saber si son o no compatibles con GraalVM, una locura.
El video lo puedes ver aquí.
Te adelanto que el video no va solo de eso, allá hay un plot twist (o más) que no te vas a querer perder.
Hay otra creencia extendida que voy a derribar aquí: compilar tu código Java a nativo no hace que tu app funcione más rápido. Inicia más rápido, eso sí, y consume menos recursos.
Pero la realidad es que los datos dicen que puede ser entre un 10-30% más lenta, y eso pasa por algo que se llama JIT. También lo explico en el video.
Si después de ver ese video no amas Java por lo menos un poco, hay algo mal.
Por cierto, por si te lo perdiste, la semana pasada anuncié que voy a colaborar con Ricardo de Programando en Java en una master class que se realizará este 26 de mayo, gratis, en YouTube.
Antes de irme, tengo algo más que contarte.
La semana pasada se estrenó un capítulo de un podcast que me invitaron a grabar (también Ricardo). De hecho, de ahí surgió la idea de hacer la masterclass y el bootcamp.
Ahí cuento muchas cosas de mí que honestamente nunca dije en internet, hay mucho chisme, así que te invito a verlo dando click aquí.
Por último, subí el último video de la serie "Primer Trabajo Programador", por ende ya puedes ver la serie completa acá.
Gracias por leer, nos vemos mañana.