# Spring Boot vs Quarkus: JVMフレームワークの比較

> JVM向けのSpring Boot vs Quarkus: 遍在するエコシステム vs 高速起動でGraalVMネイティブなクラウドネイティブフレームワーク。起動、メモリ、CIへの適合を比較。

Source: https://latchkey.dev/ja/learn/tool-comparisons/spring-boot-vs-quarkus  
Updated: 2026-06-26

Spring Bootは膨大なエコシステムを持つ支配的なJVMフレームワークで、Quarkusは高速起動、低メモリ、GraalVMネイティブイメージに最適化されたクラウドネイティブフレームワークです。

Spring Bootは巨大なエコシステム、規約、統合を提供し、ほとんどのJavaサービスのデフォルトになっています。Quarkusはコンテナとサーバーレスのために作られ - 高速なboot、低メモリ、一級のGraalVMネイティブコンパイル - しつつ、慣れ親しんだ開発者体験を保ちます。トレードオフはエコシステムの幅広さ vs クラウドネイティブな起動とフットプリントです。

## Comparison

|  | Spring Boot | Quarkus |
| --- | --- | --- |
| エコシステム | 膨大 | 成長中、焦点を絞った |
| 起動時間 | 遅め (JVM) | 高速(特にネイティブ) |
| メモリフットプリント | より高い | 低い |
| ネイティブイメージ | Spring Native経由 | 一級 (GraalVM) |
| 最適な用途 | 幅広いエンタープライズアプリ | コンテナ / サーバーレス |

## CIでは

どちらもMavenまたはGradleでbuildし、JUnitでテストします。QuarkusのネイティブイメージのbuildはCIでかなり遅いですが、高速で小さなruntime成果物を生みます - buildをcacheし、ネイティブbuildはリリース時のみにすることを検討しましょう。どちらもMaven/Gradleの依存関係cacheをcacheします。コールドスタートとフットプリントが重要かどうかで選びましょう。

## 高速化する

実行間でMaven/Gradleの依存関係cacheとbuild cacheをcacheします。どちらもCI runnerでbuildし、高速なmanaged runnerは遅いQuarkusのネイティブイメージのステップに大いに役立ちます。

## Decide with your own numbers, not a feature table

Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.

```Terminal
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
  "<tool-a> install" "<tool-b> install"

# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"
```

> Measure the cold path. Warm local benchmarks favour whichever tool you already have cached, which is exactly the condition a CI runner never has.

## What actually changes when you switch

- Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
- Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
- CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
- Everyone on the team and every runner must move together. Pin the version so they cannot drift.

## 結論

エンタープライズアプリ向けに最も幅広いエコシステムと規約が欲しいなら: Spring Boot。コンテナ/サーバーレス向けに高速起動、低メモリ、ネイティブイメージが欲しいなら: Quarkus。幅広さにはSpring Boot、クラウドネイティブなフットプリントにはQuarkus。

## FAQ

### Spring Boot vs Quarkus: JVM Framework Compared?

Spring Boot offers an enormous ecosystem, conventions, and integrations, making it the default for most Java services. Quarkus is built for containers and serverless - fast boot, low memory, and first-class GraalVM native compilation - while keeping a familiar developer experience.

### In CI?

Both build with Maven or Gradle and test with JUnit. Quarkus native-image builds are much slower in CI but yield fast, small runtime artifacts - cache the build and consider building native only on release. Cache the Maven/Gradle dependency cache for both. Choose by whether cold-start and footprint matter.

### Speed it up?

Cache the Maven/Gradle dependency cache and build cache between runs. Both build on CI runners; faster managed runners help a lot with the slow Quarkus native-image step.

### Which should I choose?

Want the broadest ecosystem and conventions for enterprise apps: Spring Boot. Want fast startup, low memory, and native images for containers/serverless: Quarkus. Spring Boot for breadth, Quarkus for cloud-native footprint.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt