Reactive I/O layer transition in Quarkus 3.0 affecting Hibernate Panache

In Quarkus 3.0, the default reactive I/O layer migrated from Vert.x to Netty. This shift impacts extensions utilizing the reactive stack, such as quarkus-hibernate-reactive-panache and quarkus-reactive-pg-client, creating a compatibility boundary for applications migrated from the 2.x series.

Legacy codebases that directly interface with Vert.x-specific classes—such as io.vertx.core.Vertx—frequently encounter ClassNotFoundException or NoSuchMethodError when moved to Quarkus 3.0. While explicitly adding the quarkus-vertx extension can restore the missing APIs, it introduces concerns regarding resource duplication and potential event-loop overhead within the native bundle.

What are the performance and threading implications for reactive transaction management when switching from a Vert.x-based loop to the default Netty implementation? Is there a recommended configuration to bridge Vert.x-dependent logic without including the full Vert.x extension?