Event sourcing on the JVM: Axon, KurrentDB, and Cratis Chronicle

Axon Framework, KurrentDB, and Cratis Chronicle all support event-sourced JVM systems, but they are not the same kind of product. Axon is an application framework with command, event, and query infrastructure plus pluggable event storage. KurrentDB and Chronicle are separate server products used through client SDKs.

This page compares the concerns where those products overlap. It does not treat a database client as an application framework, and it does not treat framework breadth as proof that a database is missing features.

Comparison layers

Axon Framework is the application-framework option; Axon Server is optional event infrastructure. KurrentDB and Chronicle are event servers consumed through clients. The matrix compares overlapping concerns and labels whether responsibility sits in the framework, server, or client; it does not treat the products as equivalent feature bundles.

What is being compared

• Axon Framework with Axon Server or another storage engine — a JVM framework for DDD, CQRS, command and query handling, event sourcing, and event processing. Axon Server is the default event store and message-routing option, while PostgreSQL and JPA storage engines are also documented.
• KurrentDB with its Java client — a dedicated event database with an official JVM client. Application-layer CQRS, aggregates, and read-model code remain application concerns.
• Cratis Chronicle with its JVM client — a separate event-sourcing server and processing runtime with Kotlin and Java APIs, artifact discovery, and an official Spring Boot starter.

Method and versions

Method

The table records released, documented capabilities at named versions. Sources come from each product’s own documentation, repository, license, or package registry and were checked on 2026-08-30. A listed capability is not a claim about performance, maturity, reliability, production suitability, or feature parity.

Tool	Compared version	Version source
Axon Framework	5.3.1; Axon Server documentation from the current installation and 2026.1 reference series where applicable	Axon Framework 5.3.1 on Maven Central, Axon 5.3 reference
KurrentDB	Server 26.0 documentation series; Java client 1.2.1	KurrentDB 26.0 installation documentation, Java client 1.2.1 on Maven Central
Cratis Chronicle	Server and .NET distribution 16.42.0; JVM client 2.10.0	Cratis.Chronicle 16.42.0 on NuGet, JVM client 2.10.0 on Maven Central

Core comparison

Question	Axon Framework 5.3.1	KurrentDB 26.0 with Java client 1.2.1	Cratis Chronicle 16.42.0 with JVM client 2.10.0
What is the product boundary?	A JVM application framework covering commands, events, queries, event-sourced entities, repositories, buses, and event processors. Event storage is pluggable.	A separate event-native database server. The Java client provides access from JVM applications without prescribing their application architecture.	A separate event-sourcing server and processing runtime. The JVM client declares event types, read models, projections, reducers, reactors, and constraints.
Where are events stored?	Axon Server is the default event store. Axon 5.3 also documents a PostgreSQL 16+ storage engine, a JPA-compatible aggregate storage engine, and an in-memory testing engine.	In streams managed by KurrentDB’s storage engine.	Through Chronicle’s documented server storage providers. The same server is used by the .NET, TypeScript, JVM, and Elixir clients.
What is the JVM programming model?	Annotated or declarative command, event, and query handlers; event-sourced entities; repositories; command, event, and query buses; and configurable event processors.	An official Java gRPC client for reading, appending, and subscribing to events. DDD, CQRS, aggregate, and read-model patterns are implemented by the application or other libraries.	Kotlin data classes or Java records annotated as events, annotated read models, and declarative or imperative processing artifacts discovered and registered with the server. Kotlin uses suspending APIs; Java uses blocking bridges.
What does Spring Boot integration provide?	The official starter detects handlers and event-sourced entities, configures command, event, and query buses, sets up event processors, and wires repositories and infrastructure. Auto-configured components can be replaced.	No Spring application framework is supplied by the server or Java client sources used for this page. This says nothing about community integration or ordinary Spring configuration around the client.	The official starter brings in the JVM client, discovers and registers application artifacts, activates them through the Spring container, and documents request identity, causation, units of work, and tenant routing.
How are events processed?	Subscribing and streaming processors invoke event handlers. Pooled streaming is the documented default; processor configuration covers segmentation, parallel processing, tracking, and replay.	Catch-up subscriptions keep position in the client. Persistent subscriptions keep position on the server and support consumer groups, acknowledgements, retries, parked events, and replay. KurrentDB documents at-least-once delivery and no ordering guarantee for persistent subscriptions.	Reactors handle event-driven application work, Reducers derive typed read models, and Observers provide low-level subscriptions. The JVM client declares Reactors and Reducers with annotations.
How are read models produced?	Event-handling components assigned to event processors update application-owned read models; streaming processors support replay through reset tokens and reset handlers.	Built-in and user-defined JavaScript projections can emit or link events. KurrentDB also documents catch-up subscriptions as the better fit for many application read models.	Reducers and declarative projections produce typed read models retrievable through the JVM client.
How can events reach other systems?	Axon documents event distribution within and across bounded contexts through Axon Server contexts or a separate message broker, with explicit context mapping recommended.	Server-side Connectors filter or transform events and send them to external sinks; clients can also consume subscriptions directly.	The server exposes gRPC and REST APIs; Reactors and JVM webhook definers provide application-defined paths for event-driven work outside the process.
What runs in production?	Axon Framework runs inside the JVM application. Axon Server, when selected, runs separately; PostgreSQL or JPA storage can be selected instead. Available Axon Server capabilities depend on the chosen edition and license.	A separate KurrentDB server, as a single node or documented cluster topology, plus the Java client in the application. Some features require a license key.	The Chronicle Kernel runs as a separate Docker-hosted server; the JVM client and optional Spring Boot starter run in the application. Workbench is bundled with the server.
What is the license boundary?	Axon Framework is Apache License 2.0. Axon Server has free and paid editions with different capabilities.	Kurrent License v1 for the server; KurrentDB states that it is not an OSI-approved open-source license. The Java client is Apache License 2.0.	MIT License for Chronicle and the JVM client. Other Cratis products retain their own license and release boundaries.

Where each option fits

These are not quality rankings. They identify the architectural choice each product makes most explicit.

Axon Framework and Axon Server

Examine Axon closely when you want a JVM application framework to define command, event, and query handling; event-sourced entities; repositories; buses; and processing as one model. Its Spring Boot integration and storage-engine choices are central parts of that experience. Axon Server adds event storage and message routing, while the documented PostgreSQL and JPA paths allow different infrastructure choices.

KurrentDB

Examine KurrentDB closely when you want the event store to be dedicated infrastructure, need a JVM client alongside clients for other languages, or want server-managed persistent subscriptions and connectors while keeping the JVM application architecture in your own code.

Cratis Chronicle

Examine Chronicle closely when you want event storage and event processing behind a separate runtime while declaring typed JVM artifacts through Kotlin, Java, or Spring Boot. Chronicle’s broader Cratis application ecosystem is currently centered on .NET and React; JVM teams should evaluate the Chronicle JVM client and Spring Boot starter on their own documented behavior rather than assuming parity with that .NET application path.

Questions to answer before choosing

1. Framework boundary: Do you want a JVM framework to own commands, queries, entities, repositories, and event processing, or do you want an event server behind an application model you choose separately?
2. Storage boundary: Should events live in Axon Server, PostgreSQL or JPA through Axon, KurrentDB’s own engine, or one of Chronicle’s documented providers?
3. Spring boundary: Do you need Axon’s CQRS application framework integrated with Spring, a Spring-configured database client, or Chronicle artifact registration and request integration?
4. Processing model: Which handlers must share a transaction, which processors must be replayable, and where should checkpoints, retries, and failed work be owned?
5. Language boundary: Is the JVM the only system boundary, or must several language clients use the same event server?
6. Operations: How will your team inspect processor or subscription progress, failed processing, projections, replay, and recovery for the exact topology you deploy?
7. Commercial and license boundary: Which server edition, support terms, and licenses apply to the exact components you intend to run?

Decision criteria to verify separately

This comparison does not score several decision-critical dimensions that depend on the exact deployment profile:

• append and side-effect atomicity, plus read consistency;
• event schema evolution, replay, and migration behavior;
• backup, restore, upgrade, failure, and recovery procedures;
• authentication, tenancy, encryption, PII, and redaction controls; and
• support, commercial terms, and operational responsibility.

Verify each dimension against the exact product versions and deployment profiles before choosing.

Limitations

• This is a documentation comparison, not a benchmark or production evaluation.
• Axon Framework is broader than a database client. The table compares overlapping concerns without treating the difference as an advantage or deficiency by itself.
• Client availability does not establish client parity.
• Storage-engine or provider availability does not establish parity between implementations.
• Product-family membership does not establish integration depth, common maturity, compatibility, support, or one commercial boundary.
• Versions and documentation change independently; verify the cited sources against the release you plan to adopt.

Sources

Sources checked 2026-08-30:

• Axon: Axon Framework repository, event infrastructure and storage engines, Spring Boot integration, event processors, Axon Server installation, and Apache-2.0 license.
• KurrentDB: introduction and clients, installation, persistent subscriptions, projections, Connectors, Java client, and Java-client license.
• Cratis Chronicle: Chronicle repository, JVM client repository, Spring Boot guide, Chronicle license, JVM-client license, NuGet, Maven Central, and Docker Hub.

Corrections and refresh

We recheck this page when a compared product changes a relevant major or minor release, license, client list, or documented capability, and at least every 90 days. If a statement cannot be confirmed from the named product’s own current public sources, we correct or remove it.

If you find a factual error or a better first-party source, send the correction.