ActiveMQ Classic vs Artemis: Which Broker to Run, Support Status and Performance

The short answer

ActiveMQ Classic and Apache Artemis are separate brokers, and both are maintained. Classic is the original ActiveMQ: OpenWire at its centre, KahaDB storage, a network of brokers for scaling, and a decade of applications built around its behaviour. Apache lists Classic 6.3.x and 5.19.x as Active. Artemis began as ActiveMQ's next-generation broker, built on a non-blocking architecture with its own journal, an address model that treats every protocol the same way, full Jakarta Messaging 3.1 support and replication-based high availability; in November 2025 it became its own Apache project. For new deployments, Artemis is usually the stronger choice. For a working Classic estate on 5.19.x or 6.3.x, staying put is a reasonable decision, because moving to Artemis is a broker replacement, not an upgrade. If you are on 5.18 or earlier, fix the support gap first and decide on Artemis second.

ActiveMQ Classic vs Artemis at a glance

Two brokers, one history

For years the ActiveMQ project shipped both brokers: Classic as ActiveMQ 5.x and Artemis as ActiveMQ Artemis. Many people read that as old and new versions of the same product. They are not. Classic has its own next major version, 6.x, which moved to Jakarta Messaging, and Apache continues to release 5.19.x alongside it. On 19 November 2025 the ActiveMQ PMC voted to establish Apache Artemis as a separate project, now at artemis.apache.org. "Artemis MQ", "ActiveMQ Artemis" and "Apache Artemis" all refer to the same broker.

Support status is where most decisions start. Apache defines Active lines as receiving regular updates, including security patches, and Inactive lines as end of life with no further updates. Today that puts Classic 6.3.x and 5.19.x in support, and 6.2.x, 6.1.x, 6.0.x, 5.18.x and every older 5.x line out of it. Artemis publishes a single current release stream on the 2.x line.

Where the architectures differ

Artemis's own migration guide sets out the differences, and three of them shape everything else.

• Addressing. Classic was built as a JMS implementation, so queues, topics and durable subscriptions are first-class, and AMQP and MQTT messages are translated into OpenWire internally. Artemis implements only queues internally and reaches every messaging pattern by routing messages from addresses to queues. Anycast routing gives queue behaviour and multicast gives topic behaviour, for every protocol alike. JMS applications still see queues and topics; operators work with addresses.
• Storage and paging. KahaDB is a journal plus an index, because Classic re-reads messages from the store when its in-memory cursors run out of space. Artemis keeps its message journal in memory and dispatches from there; when memory fills, it pages messages to files on the way in, and reads the journal sequentially only at startup, so it needs no index. The two stores are not interchangeable, and moving messages between them uses a separate export tool.
• Networking. Classic offers several transport implementations, including a synchronous TCP transport and a non-blocking NIO one. Artemis uses Netty throughout, so every connection is non-blocking without configuration choices.

The practical consequences show up in operations. Classic's network of brokers is a store-and-forward topology; Artemis clusters and bridges solve the same problems differently. Classic's high availability relies on shared storage; Artemis can also replicate over the network between a primary and a backup, and can mirror asynchronously to another site for disaster recovery. Our Classic to Artemis migration guide covers what has to be redesigned and in what order.

ActiveMQ Classic vs Artemis performance

We do not publish benchmark figures, and you should be wary of anyone else's, because message size, persistence, acknowledgement mode, transactions and paging change results more than the broker does. The design differences point in a clear direction. Artemis describes its architecture as high-performance and non-blocking, writes to an append-only journal that can use Linux asynchronous I/O, and avoids index lookups because it reads the journal only at startup. Classic's KahaDB keeps an index so it can re-read messages under memory pressure, and its tcp transport is synchronous. Under heavy persistent load, the Artemis design is built to do better. Under light load with plenty of memory, the difference may not matter to you at all. Benchmark the two on your own messages before using performance as the reason to migrate.

Should you stay on Classic or move to Artemis?

• Stay on Classic if you run 5.19.x or 6.3.x, your applications depend on network of brokers topologies, virtual destinations, advisory messages, custom plugins or Classic's JMX tree, and the broker is not a bottleneck. Both lines are actively maintained, and staying is the lowest-risk option.
• Move to Artemis for new deployments, when you need full Jakarta Messaging 3.1 or JMS 2.0, replication-based high availability without shared storage, cross-site mirroring, MQTT 5, or more headroom for persistent messaging.
• Close the patch gap first if you run 5.18 or earlier. A migration measured in quarters should not leave a broker unpatched for its whole duration; CVE-2023-46604, the OpenWire remote code execution flaw, was exploited against exactly that installed base.
• Look further afield only when the workload has changed shape. If you need replayable event streams for many consumers, that is a Kafka question; see ActiveMQ vs Kafka and RabbitMQ vs ActiveMQ.

Artemis accepts OpenWire, so existing Classic JMS clients can connect to it without being recompiled. That lets you move brokers first and clients later, or never.

Where OSSeva fits

OSSeva supports both brokers, so the decision can follow your applications rather than your support contract. OSSeva for ActiveMQ Classic backports security fixes to 5.15, 5.16, 5.17 and 5.18, the lines Apache no longer patches, and covers the maintained 5.19.x and 6.3.x lines, broker and client libraries together; see ActiveMQ Classic extended support. OSSeva for ActiveMQ Artemis provides patched 2.x builds and covers Classic and Artemis at the same time during a migration window. You keep the binaries you run today and change who supports them, under one contract priced per cluster. Book a discovery call for a quote. For other options, see ActiveMQ support providers.

Frequently asked questions

ActiveMQ vs Artemis: what is the difference?

They are two different message brokers. ActiveMQ Classic is the original broker, built around JMS and the OpenWire protocol with KahaDB storage. Artemis is a newer broker with a non-blocking architecture, its own journal, a protocol-agnostic address model and full Jakarta Messaging 3.1 support. Since November 2025 Artemis has been its own Apache project.

ActiveMQ Artemis vs Classic: which should I use?

For a new deployment, Artemis. For an existing Classic estate on 5.19.x or 6.3.x that works, staying on Classic is reasonable because both lines are actively maintained, and moving means redesigning network topologies, policies and monitoring. On 5.18 or earlier, get the broker patched first.

ActiveMQ Classic vs Artemis performance: is Artemis faster?

Artemis is designed for higher performance: non-blocking I/O, an append-only journal with optional Linux asynchronous I/O and no index lookups at runtime. How much that matters depends on your load, persistence and paging, so benchmark with your own messages.

What is Artemis MQ?

Artemis MQ is a common name for Apache Artemis, the multi-protocol message broker formerly published as ActiveMQ Artemis. It supports AMQP 1.0, MQTT 3.1.1 and 5, STOMP, OpenWire and its own Core protocol, and it implements Jakarta Messaging 3.1, JMS 2.0 and JMS 1.1. It is Apache 2.0 licensed and requires Java 17 or later in its current release.

Is ActiveMQ Classic end of life?

No. Apache lists 6.3.x and 5.19.x as Active. Every other Classic line, including 5.18 and all of 6.0 to 6.2, is Inactive, which Apache defines as end of life with no further updates.

Can ActiveMQ Classic clients connect to Artemis?

Yes. Artemis accepts the OpenWire protocol, so existing Classic JMS clients can connect without being recompiled. Connecting is the easy part; destinations, redelivery, virtual topics and monitoring still need testing, as our migration guide explains.