Quarkus Panache
Quarkus Panache is a simplified ORM layer built on top of Hibernate ORM that provides both Active Record and Repository patterns with dramatically less boilerplate. Active Record pattern: entity extends PanacheEntity with built-in methods (find, list, persist, delete, count). Repository pattern: inject PanacheRepository<T> for separation of concerns. Panache generates bytecode at build time via Quarkus augmentation — field access is automatically rewritten to getter/setter calls. First-class support for HQL, raw SQL, and type-safe operations. Integrates tightly with Quarkus reactive stack via Panache with Hibernate Reactive.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Panache parameterized queries prevent SQL injection by default. HQL string concatenation can create injection vulnerabilities — always use named parameters. Database credentials via Quarkus config properties, not hardcoded. @RolesAllowed on resource level for authorization.
⚡ Reliability
Best When
You're building a Quarkus service that needs standard CRUD database operations with minimal ceremony — Panache eliminates 80% of JPA boilerplate while staying on top of proven Hibernate ORM.
Avoid When
You need non-Quarkus portability, require complex Hibernate inheritance strategies, prefer explicit SQL (use jOOQ), or are working outside the JVM ecosystem.
Use Cases
- • Define agent data models in Quarkus with minimal boilerplate using Panache Active Record — AgentEntity.find('status', 'active').list() without writing repository classes
- • Implement repository pattern for agent domain with PanacheRepository — inject AgentRepository, use built-in CRUD, add custom HQL queries as typed methods
- • Page through agent results using Panache's built-in pagination — AgentEntity.findAll().page(Page.of(0, 20)).list() for agent data browsing APIs
- • Use Panache's stream() for reactive agent data processing — AgentEntity.streamAll() returns Stream<Agent> for large agent dataset processing without loading all in memory
- • Write testable Quarkus agent services using @QuarkusTest with Panache's transaction support — @TestTransaction annotation rolls back after each test
Not For
- • Non-Quarkus Java applications — Panache is Quarkus-specific; use Spring Data JPA or plain Hibernate for non-Quarkus apps
- • Complex ORM requirements needing full Hibernate control — Panache adds conventions that can be limiting; use Hibernate ORM directly for complex inheritance hierarchies or advanced mapping
- • Non-JVM stacks — Panache is Java/Kotlin only; use jOOQ for SQL-first Java or SQLAlchemy for Python
Interface
Authentication
ORM library — no auth concepts. Database credentials configured via quarkus.datasource properties or environment variables in application.properties.
Pricing
Quarkus Panache is Apache 2.0 licensed, maintained by Red Hat. Free for all use including commercial.
Agent Metadata
Known Gotchas
- ⚠ Active Record requires entity to extend PanacheEntity — forgetting extends PanacheEntity (or PanacheEntityBase for custom ID) causes 'method not found' at build time; the entity class IS the query API
- ⚠ Field access rewriting requires Quarkus augmentation — Panache rewrites public field accesses to getter/setter calls at build time; accessing entity fields outside Quarkus context (plain JUnit without @QuarkusTest) skips rewriting and bypasses JPA dirty checking
- ⚠ @Transactional is required for mutations — persist(), delete(), update() outside a transaction throw TransactionRequiredException; annotate CDI beans with @Transactional or use Panache.withTransaction() for programmatic transactions
- ⚠ panachePersist() vs persist() in reactive — Panache Reactive uses Uni<Void> returns; mixing blocking Panache with reactive Panache in same project causes ClassCastException; commit to one flavor (blocking or reactive) per service
- ⚠ Pagination is zero-indexed — Page.of(pageIndex, pageSize) uses 0-based page index; off-by-one errors when converting from 1-based user-facing page numbers are common; Page.ofSize(pageSize).index(pageIndex) is cleaner
- ⚠ HQL parameter syntax differs from SQL — Panache HQL uses :paramName positional parameters and 'fieldName = :param' not column names; using SQL column names (snake_case) instead of Java field names (camelCase) in HQL causes query compilation error
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Quarkus Panache.
Scores are editorial opinions as of 2026-03-06.