Plans are based on application instances, nodes and a message-throughput tier. The Individual plan is free for non-production use. Team starts at $150 a month, Small Business at $1,750 a month, and Enterprise is priced by agreement for regulated, zero-downtime workloads.

Axoniq. Community forum and AI assistance on Individual and Team, business-hours support for critical issues from Small Business, priority SLAs on Enterprise, plus long-term support for teams still on Axon Framework 4.

With one domain and a conversation with a solutions architect. Consultancy packs of 20 hours are available on paid plans for the first project, and the free plan is enough to prove the idea before anyone signs anything.

AXONIQ AND APACHE KAFKA

Keep Kafka. Give it a memory.

Q: Do we have to replace Kafka?

No. Kafka keeps moving information between your systems. Axon Server keeps the record and runs the domain. Many Axoniq customers run both.

Q: What changes for the teams that use Kafka today?

Nothing. The domain keeps publishing to the topics they already read; a message converter keeps the record format they expect. Analytics, reporting, data lakes and other teams keep working as before.

Q: Is Axon Server a replacement for Kafka?

No. Kafka moves events between systems. Axon Server stores, routes and streams them inside a domain, and the extension connects the two. Many teams that run Axon Server also run Kafka.

Q: Can I use Kafka as my event store?

You can make it work for a small system. You will build per-entity reads, conflict detection, snapshots and replays yourself, and pay streaming prices for retention. The list above is what that looks like after a year.

Q: Do my Kafka consumers have to change?

No. The extension publishes to your existing topics. The record key is the aggregate id by default, so ordering per key holds for everyone already reading them.

Q: Which Kafka does the extension work with?

It wraps the Kafka producer and consumer clients, so Apache Kafka and services that speak the Kafka protocol work. Configuration is the usual client properties.

Q: Axon Framework 4 or 5, and what is licensed?

Axon Framework 4 has the open-source Kafka extension; for Axon Framework 5, Kafka integration is an Axoniq Framework module, arriving in 5.5. Axon Framework 4 reached end of life on 30 June 2026. Axon Framework itself is Apache 2.0; the Axoniq Framework modules on top of it, including Axon Server connectivity in version 5, need a subscription for production use.

Kafka moves events between systems. Axon Server keeps them, routes them and streams them inside a domain. Run both, and nothing that reads Kafka today has to change.

Read the Kafka extension guide

Talk to a solutions architect

orders.events

Kafka topic, partition 0 of 12

retention 7d

dropped after 7dnew events, offset 48,2xx

OrderPlaced

key 4401 · off 48,207

PaymentReceived

key 4401 · off 48,208

StockReserved

key 4402 · off 48,209

OrderShipped

key 4401 · off 48,210

RefundIssued

key 4398 · off 48,211

fraud-checklag 0

analyticslag 2

notificationslag 0

Moves events between services. Forgets them once the window closes.

EVENT STREAMING

A Kafka topic is a conveyor belt. Events pass every consumer, then fall off when retention expires.

Order 4401

Event stream in Axon Server

 kept, append-only

seqeventat

#0OrderPlaced09:12:03

#1PaymentReceived09:12:41

#2StockReserved09:12:42

#3OrderShipped14:20:08

#4OrderDelivered+1d 11:47

current state

none yetPlacedPaidReservedShippedDelivered

derived from the events, never stored on its own

replaying 5 eventsrebuilt in 2 ms

Keeps every event of every order. Any state, from any point in time.

EVENT SOURCING

An Axon Server stream is a ledger per entity. Every event stays in sequence; state is rebuilt from them on demand.

Click an illustration to replay it

TWO DIFFERENT JOBS

Kafka moves.
Axon Server remembers.

Kafka is the fastest way to move information between systems, and it is very good at it. It was never meant to be the place where the business keeps its record. Axon Server is that place: every decision, in order, for as long as you need it, with the context to explain it.

Together they cover both jobs. Kafka keeps the company informed; Axon Server keeps the company’s memory. Nothing that reads from Kafka today has to change.

What the business needs	Apache Kafka	Axon Server
Its job	Moving information between systems, fast and at any volume	Keeping the record of what happened and why, and running the business logic that produces it
How long it remembers	Days by default, or you pay to keep more	As long as the business needs, with older history kept on cheaper storage
“What happened to this order?”	Not its job; you reconstruct it from other systems	Answered from the record, in full, in one step
Proving a decision to an auditor	Depends on what else kept a copy	Replay the record exactly as it stood at the time
Who relies on it	Integration, analytics and data teams	The product itself, compliance, risk, and the AI built on top
When things go wrong	Messages are delayed or delivered again	Rebuild any state from the record; incidents are fixed by replaying, not by reconciling

TOTAL COST

One product,
or ten

Teams that try to make Kafka their system of record end up buying and running ten products to fill the gap. Each one brings its own licence, specialists, upgrades and on-call rota, and together they still do not know what an order is.

Axon Server is one product from one vendor: one bill, one upgrade, one team that understands it. Support, long-term support and solutions architects come from Axoniq.

Kafkastreaming
PostgreSQLevent tables
Debeziumoutbox + CDC
RegistryAvro schemas
Redissnapshots
Consuldiscovery
Envoyrouting + LB
KubernetesHA operator
Grafanadashboards
Vaultaccess policies

10products to run, staff, secure, monitor and upgrade

Axon Server

The record, the routing and the delivery of events for a domain, in one product.

System of record
Routing
Delivery
Replay
High availability
Backups
Access control
Axoniq support

1product to run, staff, secure, monitor and upgrade

KAFKA AS THE RECORD

Streaming prices for history

Keeping every event in Kafka means paying streaming rates for data nobody streams, and paying engineers to build what is missing.

· Per-record lookups, conflict handling, snapshots and replays are built in-house

· Costs scale with retention, not with value

· Nobody owns the whole; ten teams own a piece

A DATABASE AS THE RECORD

Cheap start, expensive scale

Works in year one. By year three the database needs specialists, the tooling around it has ten owners, and every capability was written in-house.

· Performance work becomes a standing project

· Every outage is a reconciliation exercise

· Knowledge leaves with the people who built it

AXON SERVER

Built for this, priced simply

Plans are based on application instances, nodes and a throughput tier. Nothing per partition, nothing per GB retained.

✓ Free to start: the Individual plan, for non-production use

✓ Team from $150 a month, Small Business from $1,750 a month, Enterprise by agreement

✓ Support, upgrades and long-term support from the vendor

See pricing ↗

OUTCOMES

The questions you can finally answer

A record of every decision changes what the business can promise: to auditors, to customers, to the people fixing an incident at 2 am, and to the AI you are about to put in front of all of them.

AUDIT AND COMPLIANCE

Prove every decision

The record shows what happened, in order, with the context the system had at the time. Answers come from the record, not from a reconstruction project.

INCIDENTS

Fix by replaying

Rebuild any state from the record and replay what went wrong. No reconciliation across three systems, no guessing which copy was right.

AI YOU CAN DEFEND

Give models the why

Models and agents see the chain of decisions behind every state, not just the latest value. Explainability is a property of the record, not a feature bolted on.

DELIVERY

Ship on one runtime

Teams build on a platform that already does the hard parts. Axoniq’s own figure for customers: feature delivery from quarters to weeks.

ADOPTION

One domain at a time

Nobody replaces Kafka, and nobody should. The teams that did this well picked one domain, moved its record to Axon Server, kept publishing to the topics everyone already reads, and expanded from there.

Pick one domain

Orders, claims, payments: somewhere the questions “what happened” and “why” cost money today. Axoniq’s solutions architects help choose it.

Keep the record in Axon Server

The domain’s decisions are recorded there. Its milestones keep flowing to your Kafka topics, so analytics, reporting and other teams notice nothing.

Expand with evidence

The first audit, incident or model that uses the record makes the case for the next domain. Enterprise plans add a mirrored pre-production environment and priority support.

In production at Otto, Nets, MoneyLion, DPG Media and other teams.

Fortune 100 teams in automotive and financial services run Axoniq alongside Kafka

Questions the business asks

The ones that come up on every first call.

Do we have to replace Kafka?+

What changes for the teams that use Kafka today?+

What does it cost?+

Who supports it?+

How do we start?+

TWO DIFFERENT QUESTIONS

Streaming is not sourcing

Kafka answers what is happening now and who needs to hear it. A topic is a log read forward from an offset, ordered per partition, kept for a window. That is the right design for moving data at scale.

Event sourcing asks how this order, account or claim reached its state. That takes every event for one entity, in order, in one read, kept as long as the business exists, and a write that is rejected when the history under it has changed. Kafka has no concept of most of this. It does not know what an order is. Axon Server was built around exactly that question.

What you need	Apache Kafka	Axon Server
Job	Move events between systems, at any volume	Store events, route commands and queries, stream events to subscribers: the runtime inside a domain
Unit of order	Offset within a partition	Sequence per aggregate, global order across the context
Retention	A window, hours or days by default, or paid storage tiers	Permanent by default. Tiered storage moves older events to cheaper media; a context can be made ephemeral on purpose
Reading one entity’s history	Scan the partition, filter by key	One indexed read, flat as the store grows
Write guarantees	Appended without checking prior state. Conflicting writes are the consumer’s problem	Conflict detection on append: a write based on stale history is rejected, by aggregate sequence or by DCB consistency markers in Axon Framework 5
Delivery	Consumers poll the broker	Pushed to subscribers over gRPC with flow control; persistent streams with server-managed segments
Replay	Re-read a topic from an offset	Reset a processor to any position or instant; same events, same order

NOTHING DOWNSTREAM CHANGES

Keep Kafka. Run your domains on Axon Server.

Your Axon applications send commands, events and queries to Axon Server. The Kafka extension publishes the events you choose to your existing topics, so analytics, fraud models and the data lake keep reading what they read today.

What changes is where the truth lives: every order, payment or claim becomes a stream you can read, replay and prove. Fortune 100 teams in automotive and financial services went this way, keeping Kafka in place.

Order domain

Axon applications, Axon Server, your Kafka

Kafka extension

Axon appspublishconsume

Orders

Payments

Fulfillment

Axon Server

store, route, stream

1,204,117 events

commandseventsqueries

Kafkaunchanged

→orders.events

→payments.events

←legacy.orders

Downstream, as before

analytics · fraud ML · data lake

Apps write to Axon Server. The Kafka extension publishes the events you choose.

Events from elsewhere on Kafka are consumed and kept as part of the history.

Analytics, ML and the data lake keep reading the topics they read today.

Axon apps write to Axon Server. The extension publishes and consumes. The topics, and everything that reads them, stay as they are.

Axon Server is not just an event store

It is the runtime a domain runs on. Much of what Kafka does between systems, Axon Server does inside one.

EVENT STORE

Keeps the history

Append-only and indexed per context. Tiered storage, snapshots, multi-context isolation.

MESSAGE ROUTER

Routes commands and queries

Commands go to one handler per routing key. Point-to-point, subscription and streaming queries. Applications register on connect.

EVENT STREAMING

Streams to subscribers

Push over gRPC with flow control. Persistent streams with server-managed segments. Replay by resetting a position.

OPERATIONS

Runs as a cluster

Replication groups with RAFT, dashboard and metrics, backups, access control per context.

Three ways to get an event store, and what each costs

The workload is billions of small appends, reads of one entity at a time, and a history that never shrinks.

KAFKA TOPICS, OR CONFLUENT WITH INFINITE RETENTION

Streaming prices for history

Every event kept in a topic is billed per GB-month, on clusters sized for streaming, for data nobody streams.

· Reading one aggregate means scanning its partition by key

· With compaction on, older events for a key are dropped

· No way to reject a write because the state changed under it

· Snapshots, per-entity replay and routing are yours to build

POSTGRES EVENT TABLES

Cheap on day one, slow at a billion rows

A table with an index works until index growth and maintenance slow the write path.

· Subscribers poll, or chain LISTEN/NOTIFY to a query

· Replays read through the whole table

· Discovery, routing, snapshots and backups come from elsewhere

· Axoniq’s own write-throughput comparison puts Axon Server at 2 to 5× generic SQL and NoSQL stores from a cold start, 5 to 10× at scale

Performance at scale ↗

AXON SERVER

Built for the shape of the data

Append-only segments with an index, so reads stay flat as the store grows.

✓ Push delivery over gRPC with flow control, no polling

✓ Tiered storage moves older events to cheaper media

✓ Plans priced on application instances, nodes and a message-throughput tier; nothing per partition or per GB retained

✓ The Individual plan is free: one node, six app instances, non-production

See pricing ↗

The throughput figures are Axoniq’s published comparison on the Axon Server page, not an independent benchmark.

THE STITCH LIST

One runtime, or ten products

Teams that make Kafka their system of record end up assembling an event store from parts. Good parts, but ten products with ten upgrade cycles, and still nothing that knows what an order is.

Axon Server ships the list as one runtime: storage, streaming, routing, discovery, clustering, replays, snapshots, backups, metrics, access control. Two items disappear entirely. The event is the write, so there is no outbox to keep consistent and no second schema to register.

Kafkastreaming
PostgreSQLevent tables
Debeziumoutbox + CDC
RegistryAvro schemas
Redissnapshots
Consuldiscovery
Envoyrouting + LB
KubernetesHA operator
Grafanadashboards
Vaultaccess policies

10products to install, secure, monitor and upgrade

Axon Server

Event store, message router and event streaming for a domain, in one process.

Event store
Command routing
Queries
Streaming
Discovery
Snapshots
Replay
RAFT cluster
Backups
Metrics
Access control
Tiered storage

1runtime to install, secure, monitor and upgrade

Event sourcing around Kafka

What teams end up assembling

0 products1 product2 products3 products4 products5 products6 products7 products8 products9 products10 products

Kafka

broker, topics

PostgreSQL

event tables

Debezium

outbox + CDC

Registry

Avro schemas

Consul

discovery

Envoy

routing + LB

Kubernetes

HA operator

Redis

snapshots

Grafana

dashboards

Vault

access policy

Assembling an event store from parts…

10 products, 10 upgrade cycles. None of them knows what an order is.

AROUND KAFKA

Each capability arrives as another product wired back to the broker, with its own owner, upgrade and on-call rota.

Event sourcing on Axon Server

The same list, one runtime

1 runtime

Axon Serverone process, one upgrade

Streaming to subscribers (push)

Indexed event store

No outbox: event is the write

No registry: typed events

Service discovery

Command and query routing

Clustering with RAFT

Snapshots and replay

Dashboard and metrics

Access control

Same capabilities, shipped together…

One runtime, one upgrade cycle, one team that understands all of it.

INSIDE AXON SERVER

The same capabilities switch on inside one runtime, in the same order. Two are not needed at all.

Capability	Around Kafka you add	In Axon Server
Durable event storage	Postgres or Cassandra tables, your schema and indexes	Append-only, indexed event store per context
Delivery to subscribers	Kafka topics and consumer groups	Push with flow control; persistent streams with server-managed segments
Write and publish atomically	Outbox table plus Debezium or a poller	Not needed. The event is the write
Event contracts	Schema Registry, Avro or Protobuf per topic	Not needed as infrastructure. Typed events; payload conversion and upcasters handle versions
Service discovery	Consul, Eureka or Kubernetes DNS	Applications register their handlers on connect
Command and query routing	gRPC or REST behind Envoy, with hashing you maintain	Commands routed by routing key; point-to-point, subscription and streaming queries
High availability	Kubernetes operator, Postgres failover, Kafka ISR tuning	Replication groups with RAFT; data replicated to every storage node in the group
Snapshots	Redis or a table, plus the code that keeps it right	Stored in Axon Server, served first when an entity loads
Replay and reset	Offset resets, consumer-group tooling, rebuild scripts	Reset a processor from the framework or Axoniq Platform, or a persistent stream in Axon Server
Operations	Prometheus, Grafana, alert rules, backup scripts per store	Dashboard, actuator and gRPC metrics, backups of the config database, events and snapshots
Access control	Vault, Kafka ACLs, database roles	Application tokens and users with roles per context; LDAP and OAuth2

THE KAFKA EXTENSION

Two directions, one dependency

The extension sits between your Axon applications and your topics. Publishing and consuming are configured separately, so most teams start with one direction and add the other when a second domain needs the history.

Axon Server → Kafka

Publish the events you choose

The publisher is an ordinary event handler on an event processor you pick, so you decide which events leave the domain. Topic per message, the aggregate id as record key by default, payload as bytes or CloudEvents.

Publishing reference ↗

Kafka → Axon Server

Consume, and keep what matters

Topics feed subscribing or streaming event processors like any other source. Handle the events, or stream them on into Axon Server so they join the history.

Consuming reference ↗

Kafka ↔ Axon Server

Kafka between domains, Axon Server inside them

Commands and queries route through Axon Server within a domain. Integration events cross domain boundaries on Kafka. Each domain keeps its history; the enterprise keeps its bus.

Extension guide ↗

Publish one processor's events to a topicAxon Framework 4 · extension 4.12

// A KafkaPublisher writes to the topic; a KafkaEventPublisher feeds it from an event processor
KafkaPublisher<String, byte[]> publisher = KafkaPublisher.<String, byte[]>builder()
    .topicResolver(m -> Optional.of("orders.events"))   // default: "Axon.Events"
    .producerFactory(producerFactory)
    .messageConverter(converter)                       // default: DefaultKafkaMessageConverter
    .build();

KafkaEventPublisher<String, byte[]> handler = KafkaEventPublisher.<String, byte[]>builder()
    .kafkaPublisher(publisher)
    .build();

String group = KafkaEventPublisher.DEFAULT_PROCESSING_GROUP;
eventProcessing.registerEventHandler(c -> handler)
    .assignHandlerTypesMatching(group, t -> t.isAssignableFrom(KafkaEventPublisher.class))
    .registerSubscribingEventProcessor(group);         // or registerTrackingEventProcessor

Spring Boot starteraxon-kafka-spring-boot-starter

# org.axonframework.extensions.kafka
axon:
  kafka:
    message-converter-mode: cloud_event   # or the event serializer as bytes
    publisher:
      confirmation-mode: wait_for_ack    # none | wait_for_ack | transactional
    producer:
      event-processor-mode: tracking     # subscribing by default
    consumer:
      event-processor-mode: tracking

# Consuming: a StreamableKafkaMessageSource behind a
# tracking processor (the default), with a KafkaTrackingToken

Axon Framework 5 gets its own Kafka integration in 5.5, as an Axoniq Framework module built for the async-native processing model: non-blocking publication, consumer groups for parallel consumption, serialization through the message type system. Why it matters for Axon Framework 5

Questions engineers ask

The ones that come up on every first call about Kafka.

Is Axon Server a replacement for Kafka?+

Can I use Kafka as my event store?+

Do my Kafka consumers have to change?+

Which Kafka does the extension work with?+

Axon Framework 4 or 5, and what is licensed?+

Add a memory to the Kafka you already run.

Start with one domain. Publish its milestone events to the topics you have. Keep its history in Axon Server. Nothing downstream notices; the next audit, incident or model gets the whole story.

Kafka extension guide →

Configuration, publishing and consuming, with examples.

Start free →

The Individual plan: one Axon Server node, connected to the Axoniq Platform, for non-production use.

Read the series →

Kafka and Axoniq: from event streams to agentic backends.

Talk to us →

A solutions architect walks through your Kafka topology with you.

Keep Kafka. Give it a memory.

Kafka moves. Axon Server remembers.

One product, or ten

Axon Server

Streaming prices for history

Cheap start, expensive scale

Built for this, priced simply

The questions you can finally answer

Prove every decision

Fix by replaying

Give models the why

Ship on one runtime

One domain at a time

Pick one domain

Keep the record in Axon Server

Expand with evidence

Questions the business asks

Streaming is not sourcing

Keep Kafka. Run your domains on Axon Server.

Axon Server is not just an event store

Keeps the history

Routes commands and queries

Streams to subscribers

Runs as a cluster

Three ways to get an event store, and what each costs

Streaming prices for history

Cheap on day one, slow at a billion rows

Built for the shape of the data

One runtime, or ten products

Axon Server

Two directions, one dependency

Publish the events you choose

Consume, and keep what matters

Kafka between domains, Axon Server inside them

Questions engineers ask

Add a memory to the Kafka you already run.

Kafka moves.
Axon Server remembers.

One product,
or ten