Apache Iggy: A Rust-Native Streaming Platform Built for Speed

Meet the small, fast message streaming platform that recently became an Apache top-level project.

If you've ever stood up a Kafka cluster, you know the feeling: ZooKeeper or KRaft, JVM heap tuning, GC pauses, and a pile of configuration before you've sent a single message. Now imagine a streaming platform that ships as one binary, starts with a tiny memory footprint, and is engineered from the ground up to squeeze every drop out of modern Linux and modern hardware.

That's the pitch behind Apache Iggy, and in 2026 it got a lot harder to ignore. The project graduated from the Apache Incubator in August 2026 to become a top-level project of the Apache Software Foundation, and its 0.9.0 release in September brought built-in replication. Let's look at what Iggy is, why it's fast, and where it fits.

What is Apache Iggy?

Iggy is a persistent message streaming platform written in Rust. Like Kafka, it stores messages in an append-only log, so consumers can read from the beginning, from a specific offset, from a timestamp, or from wherever they last left off. That means replay is a first-class feature rather than an afterthought.

The name, by the way, comes from the Italian Greyhound: small, yet extremely fast dogs. The project takes the metaphor seriously.

The core concepts

If you know Kafka, the data model will feel familiar:

• Streams are logical namespaces. Think of them as the top-level container, which also makes multi-tenancy straightforward.

• Topics live inside streams and hold related messages.

• Partitions split a topic into independent append-only logs, stored on disk as segment files.

• Consumer groups distribute partitions among consumers so you can scale reads horizontally.

• Offsets let each consumer track its own position independently, so one slow reader never affects another.

Iggy follows the "dumb pipes, smart endpoints" philosophy of streaming platforms: the server stores and serves the log, and consumers decide where to read from.

Why it's fast: thread-per-core and io_uring

The most interesting part of Iggy is its architecture. Early versions ran on Tokio's work-stealing async runtime, which is a great general-purpose choice but means tasks bounce between threads and file I/O often lands on a blocking thread pool. For a system chasing predictable tail latency, that was a ceiling.

Starting with version 0.6.0, the team migrated to a thread-per-core, shared-nothing design built on io_uring and the compio runtime:

• Each CPU core runs its own shard, with its own data and no shared mutable state on the hot path.

• Work is steered to the right core rather than stolen by whichever thread is free.

• io_uring is completion-based: you submit an I/O operation and get notified when it's done, which gives you genuinely asynchronous file and network I/O instead of a thread pool pretending to be one.

• Because the runtime isn't garbage collected, there are no GC pauses to show up in your p99.

The team has been refreshingly honest about the cost of this move. Their engineering write-up on the migration covers the tradeoffs of choosing between Rust's thread-per-core runtimes and the borrow-checker headaches of per-shard state, including runtime panics from RefCell borrows. It's well worth a read if you like systems engineering war stories.

A word of caution on numbers: the project advertises throughput in the millions of messages per second per node, but those figures depend heavily on hardware, message size, and configuration. Iggy ships a benchmarking tool (iggy-bench), so run your own workload before drawing conclusions.

Batteries included

Iggy is more than a server. Out of the box you get:

• Multiple transports: TCP (with a custom binary protocol), QUIC, WebSocket, and a regular HTTP REST API, so you can pick the right tradeoff for each client.

• Security: TLS on all transports, Argon2id password hashing, AES-256-GCM encryption, and role-based access control down to individual streams and topics.

• Observability: OpenTelemetry logs and traces, plus Prometheus metrics.

• Connectors: dynamically loaded Rust plugins for moving data in and out. Sources include PostgreSQL, Elasticsearch, and InfluxDB; sinks include MongoDB, ClickHouse, Apache Iceberg, Delta Lake, Quickwit, and S3, among others.

• Web UI and CLI: a dashboard for managing streams, topics, users, and browsing messages, plus a command-line tool for scripting.

• MCP server: a Model Context Protocol server with 40+ tools, letting LLM agents inspect and manage your streaming infrastructure.

• Client SDKs: Rust, Python, Node.js, Java, C#, Go, and C++, plus, new in 0.9.0, a native PHP extension that for now has to be built from source.

Getting started

The quickest way to try Iggy is Docker:

docker run --cap-add=SYS_NICE --security-opt seccomp=unconfined \
  --ulimit memlock=-1:-1 apache/iggy:latest

Those extra flags relax container restrictions that the io_uring-based runtime wants. Note that the Linux shard runtime needs io_uring features from kernel 5.19 or newer, so check your host kernel first.

From Rust, connecting and setting up a producer looks roughly like this:

use iggy::prelude::*;

let client = IggyClient::from_connection_string(
    "iggy://iggy:iggy@localhost:8090"
)?;
client.connect().await?;

let producer = client
    .producer("orders", "events")?
    .direct(DirectConfig::builder().batch_length(100).build())
    .partitioning(Partitioning::balanced())
    .build();

Here orders is the stream, events is the topic, and messages are batched in groups of 100 and balanced across partitions. This follows the example on the project homepage. The Rust SDK moved to 0.11.0 alongside the new wire protocol in 0.9.0, so double-check the exact API against the docs for your version.

What's new in 0.9.0

Released on September 21, 2026 as the first version since graduation, 0.9.0 is the biggest release yet:

• Built-in replication using Viewstamped Replication (VSR), bringing clustering into the standard server.

• A new binary wire protocol shared by all SDKs.

• The thread-per-core io_uring server is now the server, replacing the previous implementation while keeping all transports.

• Per-topic durability settings, replacing the old global fsync options.

• A native PHP SDK, new connectors, and early groundwork for a Kafka protocol gateway.

• Per press coverage of the release post: more than 600 merged pull requests from around 60 contributors.

The flip side is that this is a breaking upgrade. The on-disk format changed and 0.8 data directories can't be migrated. 0.8 clients and 0.9 servers can't talk to each other, so plan a coordinated cutover rather than a rolling upgrade. Several configuration options changed too, and if you bind a listener to a wildcard address like 0.0.0.0 (common in Docker), you now must also set an advertised address or the server won't start.

Where Iggy fits, and where it doesn't

A good fit if you:

• Need very low, predictable latency and high throughput on modest hardware.

• Want a simple, single-binary deployment for edge, on-prem, or small-cluster scenarios.

• Are building in Rust, or like having a Rust-native stack end to end.

• Value having multiple transports and SDKs without extra gateway layers.

Think twice if you:

• Depend on the vast Kafka ecosystem (Kafka Connect, Kafka Streams, ksqlDB, managed cloud offerings). Iggy's Kafka-compatible gateway is only at the early groundwork stage.

• Need battle-tested multi-node clustering today. Replication is brand new in 0.9.0, so evaluate it carefully before putting it under critical workloads.

• Run mainly on non-Linux hosts. The high-performance runtime is built around Linux io_uring, so check the docs for what other platforms get.

Final thoughts

Apache Iggy is a compelling example of what happens when you rebuild a familiar idea, the append-only log, with modern tools and a relentless focus on performance. It's young, it's moving fast, and its recent graduation to a top-level Apache project signals a healthy community and governance model. If you're building latency-sensitive pipelines or just curious about io_uring and thread-per-core design, spin up a container, run the benchmarks, and see how the greyhound runs on your hardware.

Useful links: the project website at iggy.apache.org, the source at github.com/apache/iggy, and the 0.9.0 release post and upgrade guide in the official docs.