R2dbc 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.

Eight Connections, Zero Available

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

Part 18 of the Micronaut native image series. Follows Part 17, which found that reactive and imperative produced identical throughput on the 28-API workload. Assumes familiarity with R2DBC and Project Reactor.

60.8 and 59.9

Two frameworks. Different HTTP servers, different dependency trees, different teams maintaining them. Under load, both reactive stacks land at almost the same throughput:

Framework	Model	Runtime	Mem	rps	p95	k6 errors
Micronaut	Reactive	Native	128 MB	60.8	15000.6 ms	14.1%
Spring Boot	Reactive	Native	128 MB	59.9	13548.7 ms	2.0%
Micronaut	Imperative	Native	256 MB	251.9	2554.8 ms	0%
Spring Boot	Imperative	Native	256 MB	220.6	2588.9 ms	0%
Quarkus	Reactive	Native	256 MB	258.7	—	0%

Imperative hits 220–252. Quarkus reactive hits 259. Micronaut and Spring Boot reactive: 60.

265 req/s on All Three Runtimes (Until You Add a Memory Limit)

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

Part 15 of the Micronaut native image series. Assumes familiarity with reactive Java (Mono/Flux) and container memory limits.

The Draw

Native image, JVM, and virtual threads walk into a benchmark. Same reactive Micronaut service. Same k6 load profile. Same PostgreSQL. Same mock APIs with realistic latency jitter.

Runtime	Req/s	Errors	RSS (avg)
Native (unlimited)	264	1.0%	273 MB
JVM (unlimited)	266	1.0%	551 MB
Virtual threads (unlimited)	265	1.0%	543 MB

265 req/s. All three. The error rates match the mock server’s configured failure rate — the application itself isn’t failing. Reactive code runs identically on native image, HotSpot, and loom-carrier Netty.

flatMap's Second Argument Saved 1.7 Million Requests

Mon, 15 Jun 2026 00:00:00 +0000

Midway through a code review of the reactive pipeline, staring at this line in NeoService.java:

.flatMap(neo -> saveAsteroidWithApproaches(sessionId, neo))

That’s Flux.flatMap() with one argument. The function. No concurrency limit. Reactor’s default: 256 concurrent inner subscriptions.

The R2DBC connection pool has 20 connections. Netty has 4 worker threads. flatMap will cheerfully create 256 concurrent database save operations on 20 connections and 4 threads, queuing 236 of them in memory. Every one holds a NeoAsteroidRecord entity, a NeoCloseApproach list, and whatever intermediate state Reactor needs for the inner publisher chain.

Seven Fixes, Zero Errors

Fri, 12 Jun 2026 00:00:00 +0000

The fix for “JVM dies at 256 MB under load” was not a JVM flag.

Part 4 ended with Serial GC — the only GC that fits in 256 MB — serving 4,550 requests before the OOM killer showed up. 81% error rate. Same flags, same container, same load profile. Seven code changes later: 1,740,000 requests. Zero errors.

No GC tuning. No new JVM flags at all. The problem was never the runtime. It was the code asking the runtime to hold things it didn’t need to hold.

Micronaut 5 Native Image: 14 Entries vs 1,913

Sat, 23 May 2026 00:00:00 +0000

Micronaut 5.0.0 dropped on May 20, 2026. The launch blog post promises first-class GraalVM native image support. The documentation is correct. It is also incomplete in ways that cost hours.

This is what building a non-trivial native image app looks like on day one: 4 HTTP clients hitting real APIs, reactive R2DBC pipeline into PostgreSQL, Liquibase migrations, @Scheduled cron jobs, Swagger UI. Everything that should Just Work and mostly does — except when it doesn’t, and the failure modes are silent.