LaserData and Apache Iggy: Rust-Native Data Streaming for Real-Time & AI Era

LaserData: Rust-Native Event Infrastructure for the Real-Time and AI Era.

Apache Iggy is the open Rust engine for persistent, low-latency message streaming. LaserData is the production platform around it for real-time, agentic, and enterprise data workloads.

To power the real-time AI era, LaserData is building around a direct premise: keep the append-only log as the abstraction, but rebuild the engine underneath it for hardware that did not exist when the abstraction was invented. The open-source core is Apache Iggy, a Rust-native message streaming platform designed around thread-per-core execution, io_uring, and zero-copy serialization.

That is a sharper claim than "faster Kafka." The log is not only a storage format; it is an ecosystem contract. Producers, consumers, offsets, partitions, consumer groups, replay semantics, and a decade of operational muscle memory all sit above the runtime. Iggy's bet is that teams can keep that contract while moving execution onto an engine designed for modern hardware like NVMe, 128-core, and completion-based I/O.

What Apache Iggy Is

Iggy is an open source (Apache 2.0 license) project undergoing incubation at the Apache Software Foundation. It is a persistent message streaming platform — an append-only log with streams, topics, partitions, and segments — written in Rust and shipped as a single binary with no external dependencies. No ZooKeeper. No JVM. No sidecar coordination service.

The compatibility choice is not a wire protocol; it is a set of concepts. If you have modeled a system on Kafka's dumb-pipes-and-smart-endpoints pattern, the mental model transfers directly: consumers own their offsets, one log serves many independent readers, and replay is a first-class operation rather than a recovery hack.

What is different is everything below that line. Iggy speaks TCP, QUIC, and WebSocket over a custom binary specification, plus HTTP as a regular REST API, with TLS available on all four. Client SDKs ship for Rust, C#, Java, Python, Node.js, and Go, with C++ in progress.

The Apache Iggy community is developing a Kafka Proxy to help current Kafka users transition seamlessly to Iggy.

Figure: The Iggy hierarchy: Stream → Topic → Partition → Segment, with each partition owned by exactly one CPU-pinned shard.

use futures_util::StreamExt;
use iggy::prelude::*;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client= IggyClient::from_connection_string("iggy://iggy:iggy@localhost:8090")?;
    client.connect().await?;

    let producer = client
        .producer("my-stream", "my-topic")?
        .partitioning(Partitioning::balanced())
        .create_topic_if_not_exists(
            2,
            None,
            IggyExpiry::NeverExpire,
            MaxTopicSize::ServerDefault,
        )
        .build();

    // Initializes the producer and creates the stream/topic when missing.
    producer.init().await?;

    let mut consumer = client
        .consumer_group("my-consumer-group", "my-stream", "my-topic")?
        .batch_length(10)
        .build();

    consumer.init().await?;

    producer
        .send_one(IggyMessage::from("hello world"))
        .await?;

    if let Some(received) = consumer.next().await.transpose()? {
        let payload = std::str::from_utf8(&received.message.payload)?;

        println!(
            "Partition: {}, Offset: {}, Payload: {}",
            received.partition_id,
            received.message.header.offset,
            payload,
        );
    }

    consumer.shutdown().await?;
    producer.shutdown().await;
    client.shutdown().await?;
    Ok(())
}

Why Rebuild the Log

The dominant streaming platforms were architected against a specific hardware profile: spinning disks or early SSDs behind the page cache, four to eight cores per machine, epoll readiness-based I/O, and a JVM with a garbage collector. Two of those have inverted outright, and the other two have been superseded.

Storage moved to NVMe. The seek penalty that forced the log to be sequential is gone, and the device now wants many operations in flight rather than one large one — parallelism a single-writer-per-disk path cannot supply. Core counts went up roughly twenty-fold. Linux shipped io_uring, a completion-based interface with lock-free submission and completion rings shared between user space and the kernel. And Rust made memory safety a compile-time property rather than something a collector pays for at runtime. The cost that matters is not pause length - modern collectors have largely closed that gap - but allocation pressure, object headers, pointer chasing, and no control over layout or copies.

Iggy takes the replacement path rather than the acceleration path. Hardware changing does not by itself argue for a rebuild — it argues for tuning. The rebuild argument is about coordination. What costs a modern streaming server is not the write; it is the cross-core traffic around it: shared queues, work-stealing handoffs, lock contention on metadata, and buffers that move between the thread that reads them and the thread that writes them. This matters for the same reason it matters in query engines: bolting native code onto a JVM runtime speeds up individual operators, but it does not remove the serialization boundaries, allocation churn, and GC pressure that surround them. Iggy has no JVM to accelerate.

Figure: Four hardware inversions, and the design decision each one forces.

If you’d like to dive deeper into the implementation details, we’ve published dedicated engineering deep dives on these topics:

Tail Latency Is the AI-Era Metric

Here is why the tail obsession is not audiophile engineering.

In a request-response system, a P99 spike affects one user. In a multi-agent chain, it affects the whole run. A planner hands to a router, which hands to an executor, which hands to a validator. Latency across that chain is not additive in the way intuition suggests — a P99 event at step two becomes the floor for every step after it, and the probability that some step hits its tail rises with chain length. Averages hide this completely.

The same shape appears in real-time RAG (stale retrieval means stale answers), online feature stores (sub-millisecond freshness or the model scores on approximations), continuous embedding pipelines (head-of-line blocking corrupts throughput), and multi-model inference routing (variance breaks ensemble reasoning).

This is what shifts the metric that matters from throughput to predictability. Throughput scales a system. Predictability is what lets agents coordinate without cascade failure. A thread-per-core, shared-nothing, GC-free engine is not a performance flourish in that setting; it is the property the workload depends on.

Figure: A single P99 event at step two becomes the floor for every step after it. Averages hide this completely.

Benchmarks

Iggy publishes reproducible benchmark runs with open methodology at benchmarks.iggy.apache.org, with permalinks to individual runs.

On an AWS i3en.3xlarge (Intel Xeon 8259CL @ 2.50 GHz), a 40-million-message run reports over 1M messages/second, more than 1 GB/s producer throughput, more than 3 GB/s consumer throughput, 1.01 ms average write latency, and 2.05 ms P99 write latency.

On an AWS i4i.4xlarge, LaserData's published run over the same 40-million-message workload reports consumer P99 of 0.495 ms (0.357 ms average) and producer P99 of 0.976 ms (0.466 ms average), at 1 GB/s write and 2 GB/s read, with over 2M messages/second single-node throughput.

The numbers to weigh are not the throughput figures — plenty of systems post large throughput numbers. They are the gap between average and P99, and the Tokio-to-thread-per-core deltas at P99.99. Those measure predictability, which is the claim the architecture actually makes.

Apache Iggy delivered ~3× higher throughput with ~30× lower tail latency, saturating the instance network ~5M messages/sec while maintaining consistent single-digit-millisecond tail latency, reinforcing Iggy’s architectural advantage for predictable, ultra-low-latency streaming. - VeloDB Engineering

One Log, Many Readers

Iggy is the engine. The Laser SDK is LaserData's typed client on top of it, and it makes an architectural argument worth stating plainly: point-to-point wiring turns agent logic into integration logic.

Wire N systems to M consumers directly and every new reader changes the writer. Publish once to a durable, ordered, replayable log and readers subscribe independently at their own pace — N + M instead of N × M. The log is the source of truth; queries, projections, key-value state, knowledge graphs, and agent coordination are all read models over it, never a second system to keep in sync.

Figure: Publish once to an ordered, replayable history and every reader subscribes at its own pace. Add a reader without changing the writer.

The SDK exposes eight primitives under one grammar — object.verb(input).await:

laser.topic() — publish, consume, replay by offset, batch
laser.graph() — link entities, traverse, find neighbors and nearest vectors
laser.memory() — remember, recall (semantic, keyword, hybrid), consolidate
laser.context() — assemble one conversation's record and scope memory to it
laser.query() — filter, aggregate, page, and vector-search declared projections
laser.watch() — await a view's advance instead of polling it
laser.kv() / .fork() — point reads and writes, CAS, leases, copy-on-write branches
laser.agent() / .workflow() — directed asks, deadline contracts, ordered workflows

The open/managed split is explicit rather than implied. Publish, consume, the agent runtime, provenance, and log-backed memory run against raw Apache Iggy. Query, projections, KV, forks, and the knowledge graph run against LaserData Cloud. The Laser SDK never hides the layer below — laser.iggy_producer, laser.iggy_consumer, and laser.client() expose the full Iggy client directly.

On top of that sits AGDX, the Agent Data Exchange Protocol: a typed, versioned, fixture-pinned envelope for agent messaging on the log, with token streams that resume from offsets and deterministic reassembly. A2A, MCP, and AG-UI are treated as edge protocols that map onto AGDX and ride the durable log rather than a separate SSE channel. The wire contract lives in a standalone, runtime-free, wasm-portable laser-wire crate, pinned byte-for-byte by a cross-language conformance suite.

The SDK is Apache-2.0 and honest about its status: pre-1.0 and shipping release candidates, with the wire contract, the AGDX spec, and the public API all subject to change in any release. Pin an exact version.

The LaserData Platform

Apache Iggy is the engine. LaserData Cloud is the managed product built around it, with a free tier available on AWS and GCP.

The system is four components with one deliberate constraint: the control plane never connects inbound to your infrastructure. A lightweight Warden agent runs on every node alongside the Iggy Server and pulls configuration, tasks, connectors, and certificates outbound over HTTPS, reporting telemetry back the same way. No inbound ports. Firewall-friendly, and it works air-gapped.

Above those sit the Console UI for deployments, networking, connectors, and access, and the Platform API at api.laserdata.cloud for tenants, environments, API keys, and provisioning. Every Console action is available via API across two layers — a main API for org management and a supervisor API for deployment ops — which is what makes CI/CD pipelines and Terraform providers feasible.

Apache Iggy also ships an MCP server built on the rmcp crate, exposing 40+ tools across streams, topics, partitions, messages, consumer groups, and users over both stdio and HTTP — so an LLM client can inspect and manage streaming infrastructure directly, with a permissions layer that can pin it to read-only.

There are three ways to run:

Apache Iggy OSS — self-host the Apache 2.0 engine with community support and full control.
LaserData Cloud (Managed or BYOC) — LaserData operates the platform in its own AWS/GCP, or in your account where the VPC, storage, and data perimeter stay yours. Private preview; BYOC on Pro and Enterprise.
On-Premise (Enterprise) — your servers, private cloud, or air-gapped environment, with the same Console and APIs.

The separation is clean: open source for teams that want the engine, platform for teams that want sub-millisecond tails without owning shard placement, NUMA topology, certificate rotation, and connector lifecycle themselves. Read more on LaserData Cloud Documentation

What's Still Being Built

Worth stating plainly, because the honest version is more useful than the marketing version.

Clustering is not production-ready. Iggy is implementing Viewstamped Replication — a consensus protocol similar in purpose to Raft or Paxos, chosen for its simplicity and its track record in high-performance systems — and the building blocks are in the core/consensus/ crate: the consensus protocol, view change, quorum tracking via BitSet, deterministic tick-based timeouts at 10 ms per tick with jittered exponential backoff, a 256-byte zero-copy consensus header via bytemuck, and shard-level plane multiplexing. A deterministic network simulator replays exact failure scenarios — delays, drops, partitions. Today, every LaserData deployment ships standalone, with cluster mode in private preview. Tiered storage is also on the roadmap.

Takeaway

Apache Iggy is best understood as a from-scratch rebuild of the append-only log for hardware that inverted every assumption the original design was built on—NVMe instead of page-cache gambles, 128 cores instead of eight, completion-based I/O instead of readiness polling, and compile-time memory safety instead of a garbage collector. The consequence of that rebuild is a tight tail, and the tail is the metric that matters now. Agent chains, real-time RAG, and inference routing all fail on variance rather than on average throughput.

But a fast log is only the foundation; the payoff is architectural. With the Laser SDK, developers get various data primitives to seamlessly build around that log. It places one durable, ordered, replayable history in the middle, while you deploy protocols, state stores, and readers at the edge. Services and AI agents built with the SDK inherit the same durability and ordering without having to bolt on their own custom logic.

For teams running streaming infrastructure today, the final piece is operational. LaserData Cloud delivers this entire stack as a fully managed platform with embedded data backends beyond streams. The appeal is a familiar one: change the engine before you change the codebase. The log stays the log, but by moving to LaserData Cloud, the infrastructure running underneath it finally matches the demands of the real-time and AI era—without the product teams having to manage the infrastructure.

Sources

Apache, Apache Iggy, and the feather logo are trademarks of the Apache Software Foundation. Use of these marks does not imply endorsement by the ASF.