Apache Iggy: Rewriting the Message Stream Platform in Rust

Basic Positioning

Apache Iggy is a persistent message streaming platform written in Rust, currently in the Apache Incubator. Iggy aims to be a high-performance alternative to Kafka and RabbitMQ Streams, claiming to handle millions of messages per second with very low latency. The project started in 2023 as the founder's Rust learning side project and joined the Apache Incubator in February 2025.

Iggy is not an extension of existing infrastructure but a message stream log system built from scratch. It uses low-level I/O, thread-per-core shared-nothing design, io_uring, and the compio runtime to maximize speed and efficiency. The name comes from Italian Greyhound—small but extremely fast.

Iggy's main selling point is extreme performance. It claims millions of messages per second, microsecond-level latency, and predictable p99+ latency. Benchmarks show throughput exceeding 5000 MB/s (e.g., 5 million 1KB messages per second) with appropriate hardware and configuration. These numbers come from tuned test environments; real production behavior still needs verification.

Architecture Design

Iggy follows the classic message stream architecture but with aggressive optimizations in the implementation. The data model has four levels: Stream (namespace), Topic, Partition, and Segment.

Stream is a logical namespace for environments (dev, test, prod) or tenants. Each Stream has one or more Topics; Topic is the actual message categorization. Topics can have multiple Partitions for horizontal scaling and high availability. The physical storage of a Partition is Segment—a fixed-size binary file (e.g., 1GB) holding the actual records.

This structure aligns with Kafka, but Iggy's implementation is more aggressive. It uses an append-only log as the core data structure, optimized for appends. Messages are written in offset order; each has a unique offset. Reads locate messages by offset and support random access and sequential scan.

In 0.6.0, Iggy rewrote its core architecture, switching from Tokio's poll model to an io_uring-based completion model using compio as the async runtime. This was a major technical shift.

io_uring is Linux's next-gen async I/O interface. Traditional epoll/poll are polling models; the app keeps asking the kernel if I/O is done. io_uring uses a completion queue; the kernel notifies the app when I/O completes, reducing system calls and context switches. User and kernel space communicate via two lock-free ring buffers: the submission queue (SQ) for I/O requests and the completion queue (CQ) for results.

With io_uring, Iggy uses a thread-per-core shared-nothing design. Each CPU core runs its own event loop with exclusive resources. Data is sharded by core to minimize cross-thread sync and cache invalidation. This removes lock contention; each core handles requests independently.

The upside is making good use of modern multi-core CPUs while avoiding coordination overhead of traditional multi-threaded models. Each core is like a small independent server. The downside is higher implementation complexity and careful data sharding and load balancing.

Protocol Support

Iggy supports four transports: QUIC, TCP, WebSocket, and HTTP. Each has different characteristics and use cases.

TCP uses a custom binary protocol and offers the best performance. QUIC runs over UDP, gives TCP-like reliability with lower latency, especially on lossy networks. WebSocket fits browser clients and streaming dashboards. HTTP provides a standard REST API for integration and debugging.

All protocols support TLS. Iggy uses custom zero-copy serialization/deserialization, operating directly on binary data without extra allocations or copies.

In 0.6.0, Iggy added native WebSocket support over io_uring. This was tricky because common Rust WebSocket libraries (e.g., tungstenite) are poll-based and don’t fit the completion model. Iggy contributed compio-ws to the compio ecosystem for completion-based WebSocket.

Benchmarks show WebSocket latency about 0.8–1.0ms (30–40%) higher than TCP, but still around 9.48ms at P9999. This is with fsync-per-message persistence—quite solid.

Client SDKs

Iggy provides multi-language SDKs: Rust, C#, Java, Go, Python, Node.js officially; C++ and Elixir in development.

SDKs focus on usability. In Rust, for example, you connect via IggyClient, authenticate, then create Streams, Topics, Partitions, and send/receive messages. The API is async with async/await. Authentication is mandatory; apart from ping and login, all operations require proper permissions.

Iggy has a default root user (both username and password "iggy") with full permissions that cannot be deleted. In production you should create additional users with fine-grained permissions. 0.6.0 improves security: root password is auto-generated if unset, and Argon2 is used for hashing.

Tools and Ecosystem

Iggy provides a full toolchain for development and operations.

The CLI can be installed via cargo install iggy-cli, with an interactive interface to manage Streams, Topics, Partitions, browse messages, etc., for command-line users.

The Web UI is a graphical admin panel that covers most CLI features. It is still evolving but usable for basic tasks. Images are available via docker pull apache/iggy-web-ui.

Connectors Runtime is a high-performance modular runtime for loading and running connector plugins. Users implement Source or Sink traits to create custom Rust plugins for data pipelines—ingesting from external sources into Iggy or pulling from Iggy to external systems.

0.6.0 added several connectors: Iceberg Sink (S3-compatible and REST catalog, stream data into data lake), Elasticsearch Sink/Source, and Flink Processor for Apache Flink integration.

MCP Server implements Model Context Protocol for message stream infrastructure. MCP is a standard from Anthropic for providing context to LLMs. Iggy MCP Server lets LLMs access message stream data in real time for more accurate and relevant responses. This is part of Iggy's exploration of Agentic AI use cases.

Performance and Benchmarking

Iggy treats performance and benchmarks as first-class. The project provides iggy-bench for performance and regression tests. Results are published at benchmarks.iggy.apache.org; anyone can view and contribute.

Iggy emphasizes transparent and reproducible benchmarks. Test code is open source; environment and configuration are documented. Unlike projects that only show best-case numbers, Iggy encourages users to verify performance in their own settings.

Official benchmarks show millions of messages per second and throughput over 5000 MB/s. Latency is in the microsecond range at p99+. These numbers are from tuned setups with io_uring, huge pages, kernel tweaks, etc. Real production performance depends on hardware, network, and configuration.

Importantly, Iggy is still iterating. The 0.6.0 switch to io_uring and thread-per-core improved performance. More optimizations are planned: kTLS, DirectIO, NUMA, TCP connection sharding, etc.

Current Limits

Iggy is still early and has clear limitations. The biggest is single-node only—no clustering yet. The founder has mentioned clustering will use Viewstamped Replication, but it's still in planning.

Without clustering, Iggy cannot provide high availability. A single-node failure takes down the whole system. That's a serious issue for production. Users must implement external HA or accept single-point-of-failure risk.

Other gaps: feature set is incomplete. Advanced features like transactions, message compression, and more complex permission models are still under development. Docs are also evolving; some sections are sparse.

As a young project, production deployments are few. Incubator status aside, actual user count and scenarios are unclear. Stability and edge-case handling still need time to validate.

Community and Development

Iggy joined the Apache Incubator in February 2025, a significant milestone. Incubation means the project commits to open governance, a diverse community, and not being controlled by a single company.

The project uses a monorepo for server, SDKs, tools, and connectors, simplifying contribution and consistency. Code is on GitHub at apache/iggy; Discord is used for community discussion.

Iggy is listed on Thoughtworks' Technology Radar as worth experimenting with, which helps visibility. As an incubating project, it still needs broader community and contributor base to graduate to a top-level Apache project.

Long-term goals include: extending performance benchmarks and pushing ultra-low-latency limits; integrating with modern data infrastructure; and building an active developer ecosystem to make message streaming frictionless. Whether these goals are met depends on community participation.

Evaluation

Iggy's approach can be summarized as: reimplement Kafka's data model with Rust + io_uring + thread-per-core. Architecturally there is no fundamental innovation. The Stream/Topic/Partition/Segment structure mirrors Kafka, with implementation-level performance optimizations.

This "reimplementation" path has a core competitiveness issue. Iggy's main angle is extreme performance, but performance alone is common in the Rust ecosystem. Redpanda rewrote Kafka in C++ and claims significant performance gains. Other Rust message queues, including RobustMQ, can reach similar levels with io_uring, zero-copy, and efficient serialization. Pure performance is not a strong moat.

If the goal is extreme performance, NATS is the benchmark. NATS is a pure in-memory system with no persistence overhead and minimal design; a single node can handle tens of millions of messages per second. That’s true extreme performance. Iggy, as a persistent message stream system, is limited by disk I/O and durability; its performance ceiling is lower than NATS. On the performance dimension, Iggy can’t match NATS-style in-memory systems, nor does it offer enough differentiation to challenge Kafka.

More importantly, ecosystem. Iggy is a new system: no Kafka protocol compatibility, no connector ecosystem, no mature monitoring and ops tools. Migrating to Iggy means abandoning the Kafka ecosystem and rebuilding the tooling from scratch. That cost is huge, and the benefit is "possibly faster." In messaging, ecosystem value outweighs marginal performance gains.

The technical approach also has limits. io_uring requires Linux 5.1+; thread-per-core is complex; compio is niche. These choices optimize for performance but narrow applicability and raise the bar for adoption. And these optimizations are single-node; adding clustering and replication will inevitably reduce performance.

The lack of clustering is critical. The main value of a message queue is reliability and availability. A single node, no matter how fast, cannot deliver HA. Without clustering, it’s not suitable for production-critical workloads. Clustering is planned with Viewstamped Replication, but building distributed systems is hard; when it will be stable is unknown.

From an evolution perspective, Iggy feels more like a technical exercise in how to build a high-performance message queue with a modern stack. The io_uring and thread-per-core practices are instructive; contributions like compio-ws to the Rust ecosystem matter. But to be a competitive message queue, performance alone is insufficient.

Iggy’s transparent benchmarking is commendable and reflects technical honesty. However, transparency doesn’t change the lack of architectural innovation and almost nonexistent ecosystem. Incubator status shows some community interest, but many incubating projects do not graduate successfully.

For Rust message queue projects, Iggy’s value is mainly technical reference—zero-copy design, io_uring usage, performance tricks. Strategically, it illustrates a high-risk path: giving up ecosystem compatibility and betting on pure performance. So far, that bet looks unlikely to pay off.

Competition in messaging is no longer at single-node performance. Kafka’s performance is sufficient for most use cases; differentiation comes from cloud-native design (e.g., Pulsar’s storage-compute separation), cost optimization (e.g., Ursa’s lakehouse integration), and protocol compatibility (leveraging existing ecosystems). Iggy’s direction—extreme single-node performance plus a new ecosystem—is weak in the current market.