Jdbc on tsvinc

2492, 2495, 2508

Tue, 07 Jul 2026 00:00:00 +0000

Part 19 of the Micronaut native image series. Follows Part 18, which chased a connection pool cancellation leak. Assumes familiarity with JDBC, R2DBC, and JPA/Hibernate.

The Table That Ended the Argument

Workload	Framework	rps	p95
`jdbc-synth`	Quarkus	2508.4	1.2 ms
`jdbc-synth`	Micronaut	2495.0	1.8 ms
`jdbc-synth`	Spring Boot	2491.8	1.6 ms
`r2dbc-synth`	Quarkus	2501.2	1.4 ms
`r2dbc-synth`	Micronaut	2480.2	2.2 ms
`r2dbc-synth`	Spring Boot	2478.7	2.3 ms

Native images at 256 MB. Same k6 load. Same Postgres. Zero errors across the board.

The Throughput Was Always 115

Thu, 02 Jul 2026 00:00:00 +0000

Part 17 of the Micronaut native image series. Follows Part 16, which compared reactive vs imperative on a lighter workload. Assumes familiarity with Project Reactor and virtual threads.

115

That’s the number. Requests per second. For all twelve scenarios.

Reactive R2DBC on native: 115. Imperative JDBC on JVM: 115. Virtual threads with loom-carrier: 114.5. Reactive on JVM with 512 MB memory limit: 115.2. Imperative on JVM unlimited: 115.1.

Twelve benchmark runs. Two codebases. Three runtime configurations. Six memory/container permutations each. 0% failure rate across the board. And the same number, over and over, like a metronome that doesn’t care what’s playing.

Designed a Reactive Benchmark. Imperative Won.

Tue, 30 Jun 2026 00:00:00 +0000

Part 16 of the Micronaut native image series. Follows Part 15, which benchmarked the reactive service alone. Assumes familiarity with Project Reactor and virtual threads.

The Hypothesis

The workload was designed to make reactive shine. Six endpoints exercising parallel fan-out, scatter-gather, bounded concurrency, and backpressure. A Go mock server injecting realistic latency jitter — ISS at 10-50ms with 3% failures, NEO at 30-150ms, connection resets via Hijack() + conn.Close(). k6 ramping to 200 VUs then sustaining 500 req/s constant arrival. If reactive Micronaut had a home-court advantage anywhere, it was here.

We Removed Reactor. Nothing Got Slower.

Sat, 20 Jun 2026 00:00:00 +0000

We took the entire reactive stack out. R2DBC, Mono, Flux, Reactor Core, loom-carrier, flatMap with its carefully-tuned concurrency arguments. Replaced it with JDBC, HikariCP, and blocking method calls. Same endpoints. Same Netty HTTP server. Same PostgreSQL. Same k6 load profile: 10 to 200 VUs, 500 req/s constant arrival rate, seven scenarios each.

Throughput didn’t move. Latency dropped. Memory dropped. GC pauses dropped 63% at 256 MB.

The Scoreboard

This is part of the series benchmarking a Micronaut 5.0.0 app under memory constraints. The reactive version is the one from Part 10 and Part 11 — fully tuned, flatMap concurrency bounded, R2DBC pool sized to match, loom-carrier enabled for virtual threads. The imperative version: JDBC/HikariCP, THREAD_PER_TASK executor for virtual threads, same pool size.