Apache Iggy: What Rewriting Message Streaming in Rust Actually Buys You

Do we really need another message broker?

Message streaming is Kafka's market, full stop. LinkedIn open-sourced it in 2011 and fifteen years later nothing has dislodged it. Every time queues or streaming came up on a financial-sector project — OpenAPI traffic, payment events — Kafka was the default first candidate. It's that solid. It's also that heavy.

So when I first saw the name Apache Iggy, I shrugged. Another broker. Great. Then I read that it was written from scratch in Rust and pushes millions of messages per second, and I had to go look.

Piotr Gankiewicz started the project in April 2023, and the origin story is one any developer will recognize. He wanted to learn Rust properly, and figured building something real was the fastest way to do it. He'd worked with RabbitMQ, ZeroMQ, Kafka, and Aeron, so he used that as capital and set out to write a message streaming platform. Using a tool and building one show you completely different things. Build it yourself and you learn from the inside where a broker leaks cost.

What started as a learning exercise now has nearly 4,000 GitHub stars, and in February 2025 it entered the Apache Incubator on a vote of 21 for, 0 against. Unanimous, which is worth pausing on. The name 'Iggy' is short for Italian Greyhound — Piotr owns two of them, and apparently they're small and absurdly fast. Small, light, fast. The name lands exactly where the project is aiming.

What Iggy actually is

Iggy isn't a message broker. It's a persistent message streaming platform, and that distinction matters. In character it sits much closer to Kafka than to RabbitMQ. It uses the same conceptual model — streams, topics, partitions, segments — so if you've run Kafka, you can carry your mental map over nearly intact.

The real difference is the internals. Iggy is written in Rust with a thread-per-core, shared-nothing architecture and io_uring for I/O. The terminology sounds heavier than the idea. Structurally, it removes the contention that comes from cores taking locks and sharing resources, and squeezes performance out of modern Linux kernel async I/O all the way down.

No garbage collector. No JVM. Resource usage far below Kafka's. Anyone who's operated Kafka remembers the hours spent on GC pauses, heap tuning, and sizing JVM memory. Not having that layer at all means something operationally. Early users have reported 20 million messages per second over TCP, which is a striking number for a project this young.

Version 0.6.0, released in December 2025, was the real inflection point. The team rewrote the server entirely, moving off the Tokio-based async runtime to a completion-based model using io_uring and compio. Swapping out a runtime model is never a light decision — you're pulling the heart out of something that already runs. The benchmarks justify the gamble: over 5,000 MB/s throughput and sub-millisecond P99 latency on suitable hardware.

The protocol flexibility is the interesting part

What caught my eye most was the transport layer. Iggy supports QUIC, TCP, WebSocket, and HTTP, all with TLS, and each has a clear job. TCP gives you peak performance over the custom binary protocol. QUIC helps cut latency on lossy networks. WebSocket is there when you need browser connections. HTTP exposes a standard REST API for integration and debugging.

Giving clients that many ways in is a bigger operational advantage than it sounds. Squeeze performance over TCP between internal services, take browser and external integrations over WebSocket and HTTP, poke at things with REST when you're debugging — all routed through one platform. Normally you'd stand up a gateway layer in front to reconcile all that. This removes a layer.

Iggy also uses zero-copy serialization: no enforced schema, binary data handled as-is. Cutting the overhead that leaks out of serialize/deserialize cycles is where a chunk of the performance comes from. It cuts both ways, though. No schema enforcement means the platform isn't guarding your data contracts, so format management lands on the application side. You get performance and you supply the discipline yourself.

Trying it out

Getting started is easier than expected. Pull the Docker image and run it, or install the CLI and start poking. cargo install iggy-cli, then just type iggy in your terminal.

The getting-started guide walks through building a producer and consumer in Rust step by step, and the docs are in decent shape. Default credentials are the root user: username iggy, password iggy, and root holds every permission. From there you can create additional users with finer-grained permissions. Obvious, but worth saying: that default account is for testing. Don't ship it to production.

A simple scenario makes the structure click. One "producer" sends a notification message, another "consumer" picks it up and does some work with it. Five minutes with nothing but the CLI bundled in the Docker image gets you through the whole thing.

Step 1: Start the Iggy server

git clone https://github.com/apache/iggy.git 
cd iggy 
# simple default login
export IGGY_ROOT_USERNAME=iggy 
export IGGY_ROOT_PASSWORD=iggy   
# start the server in the background
docker compose up -d

Once it's up, data lands in the local_data folder, so it survives a reboot.

Step 2: Create a stream and topic

Open a new terminal and run:

docker exec -it iggy-server /iggy --username iggy --password iggy stream create notifications  
docker exec -it iggy-server /iggy --username iggy --password iggy topic create notifications alerts 1 none

Think of notifications as the whole mailbox (a series of messages) and alerts as a specific channel — the "topic" — inside it.

Step 3: Send a message

docker exec -it iggy-server /iggy --username iggy --password iggy message send --partition-id 1 notifications alerts "Hello from Iggy! User logged in at 8:06 PM."

Run it as many times as you like. Each run drops in a new message.

Step 4: Receive messages

In another terminal:

docker exec -it iggy-server /iggy --username iggy --password iggy message poll --consumer 1 --offset 0 --message-count 5 --auto-commit notifications alerts 1

The messages print immediately. A consumer can sit in a loop and keep "polling" for new ones.

That's a producer → streaming server → consumer pipeline in under ten commands. For checking the concepts by hand, that's about the right barrier to entry.

Here's what just happened. The data producer is anything pushing data in — an app, a sensor, another service. Streams and topics are the folders keeping messages from getting mixed together. The consumer is anything pulling data out: a dashboard, an email sender, an analytics tool. Messages stay on the server until you delete them. Retention is under your control.

SDKs and the developer ecosystem

There are SDKs for Rust, C#, Java, Go, Python, and Node.js, with C++ and Elixir in progress. Predictably, the Rust SDK is the most polished. The producer API is clean: configure the client, point at a stream and topic, set up batching and partitioning, start sending.

The consumer side follows the same pattern and supports consumer groups, which handle message ordering guarantees and horizontal scaling across connected clients. This part is conceptually near-identical to Kafka, so your existing operational instincts carry over. When you're evaluating a new platform, having a familiar model like that weighs more in the adoption decision than people expect. Whatever your team has to relearn from zero is the adoption cost.

A web UI for managing streams, topics, and partitions and browsing messages ships as a separate Docker image (apache/iggy-web-ui). Being able to see the data flow during development makes debugging noticeably less painful.

A connector framework landed recently too. You implement the Source or Sink trait in Rust to build custom data pipelines. 0.6.0 added connectors for Apache Iceberg, Elasticsearch, and Apache Flink, which reads as a signal that this isn't meant to be a platform that only talks to itself. Messaging infrastructure isn't judged only on how fast it can push bytes. It's judged on how cleanly it plugs into everything around it.

There's also an MCP (Model Context Protocol) server in there, for feeding context to LLMs. Not a core feature today, but it tells you where they're pointing.

Current limits and what's next

There's a weakness worth being blunt about: there's no clustering yet. Iggy runs single-node today, with Viewstamped Replication-based clustering planned for the future.

Don't wave that away. In production environments built around high availability — financial systems that won't tolerate a single point of failure, for one — single-node alone can knock it off the candidate list. The node dies, everything stops. The team knows it and it's on the roadmap, but it's a variable you have to price in before you sketch a deployment.

There's a positive signal on the other side. Iggy recently landed on the Thoughtworks Technology Radar as something worth assessing. The industry has decided it's worth watching.

And the project is growing an ecosystem: close to 20 repositories, a connector runtime, an MCP server, multiple SDKs, a CLI, a web UI. Look only at the missing clustering and it reads unfinished. Look at the surrounding tooling and it reads like someone laying a foundation for real operations, one piece at a time, not a toy project.

New room in message streaming

Line up Iggy, Redpanda, and WarpStream and you can see the pattern: attempts to rewrite message streaming infrastructure for modern hardware and cloud environments. Kafka still holds the throne and isn't losing it soon, but each of these projects is picking a different balance point between performance, resource efficiency, and operational simplicity.

Their strategies differ too. WarpStream made Kafka compatibility its weapon. Apache Iggy went the other way — its own protocol, its own API, betting everything on being the fastest and lightest thing from day one. Giving up compatibility bought design freedom. It also means you can't migrate off Kafka for free.

Which makes the decision criteria fairly clear. If throughput and latency are core to your business and you can live with the single-node constraint at this stage, Iggy is worth spending time validating. If high availability is non-negotiable, keep it in peripheral vision until the clustering roadmap lands. For me, the trajectory itself — a learning project that made it to the Apache Incubator — is reason enough to look again. Someone who ground through a broker's internals by hand has probably thought about the internals of operating one too.