Aleksandr Filichkin
3 min readMay 2, 2022

AWS Lambda GraalVM native: Quarkus vs plain Java

I prefer to use plain Java code for GraalVM native AWS Lambda but my colleagues often ask me why I don’t consider some framework for this.

My first point is that our AWS Lamda code should be simple enough to write without frameworks also I had some concerns about the performance because frameworks are not free and it may increase the cold start time for AWS Lambda.

In this article, we will try to understand if Quarkus framework reduce the perfromance in comparing wit plain Java code + GraalVM native

I selected Quarkus because it’s the most popular and mature Framework for GraalVM native runtime.

We are going to test API-Gateway -> AWS Lambda->DynamoDb flow.

We will test only POST endpoint which will save the book into the DynamoDb table in the known AWS region(us-east-1).

The test flow


  • Native image compilation time and artifacts size
  • Start-up/cold start time for 128,256,512 mb setup
  • Warm-up execution time for 128,256,512 mb setup

Quarkus and plain java lambdas are using the same dispatcher with a common code. For Dynamodb is used AWS SKD v2 and Apache HTTP client(because in the warm state url-connection client is too slow and Netty client increases cold start)

GraalVM native version is the same in both versions java11–22

All code as usual you can see in my GitHub

Build time comparison

The Git repo has GitHub actions that perform all CI/CD stuff and post-deployment test call. It means for Native image compilation time we just can to check GitHub Actions log.

Java plain build took 3m 1s
Quarkus took 3m 50s

Cold start comparison

Plain java 128mb cold start
Quarkus 128mb cold start

In GitHub action log we see almost the same: Quarkus is slower than plain Java: 1.2s vs 1.9s

Warm state comparison

Warm state plain Java 128mb
Warm state Quarkus 128mb


To be honest, I’m a bit surprised. I didn’t expect that cold start with Quarkus about 60% slower than without any framework. The same for the warm state, for some reason Quarkus takes in average 130ms, but plain Java + GraalVM take only 14ms.

Here is the bug, that I reported to Quarkus to check this performance issue.