Piotr Gankiewicz

Customers asked. We built. Two new capabilities are now live. At @laserdatainc, we spend a lot of time thinking about efficiency: how much data we move, how much CPU we burn, how much work happens on the critical path, how many milliseconds saved at P95+, and how much complexity we push onto developers. A lot of infrastructure performance comes down to a simple question: are we doing work that never needed to happen in the first place? #1 Consumer Filters ---- This customer request was around Change Data Capture (CDC) pipelines. A fraud service cares about payment events. A search indexer needs product updates. An AI agent is waiting for changes relevant to one customer. When each consumer needs only a slice of a shared feed, why make every consumer download the whole thing? Receiving, decoding, and discarding records is still work. It consumes bandwidth and CPU. Under load, it competes with the events your application actually needs to process. That led us to build "Consumer Filters". Filtering happens on the server, so each consumer group can receive only the records it actually needs based on message headers or payload fields. The underlying stream remains intact, but the downstream system avoids unnecessary data movement and client-side processing. #2 Laser SDK Plugins for Coding Agents ---- As Claude Code, Cursor, Codex, and other coding agents become part of everyday software development, teams want those agents to understand the infrastructure they are building against instead of repeatedly re-learning APIs, conventions, and architectural patterns. That led us to build a Laser SDK plugin for coding agents, giving them deeper context for building streaming applications and durable agent systems. These two features may look unrelated, but both came from real customer friction and both reflect the same engineering philosophy: eliminate unnecessary work wherever it shows up. In one case, that means fewer bytes over the network, fewer CPU cycles, and less processing in the hot path. In the other, it means less time spent by developers and coding agents figuring out how to use the infrastructure correctly. This is also why we care so much about tail latency. Once you start optimizing for p99 and p999, unnecessary work becomes very visible. Good infrastructure is not just about making one component faster. It is about making the whole path more efficient. Every millisecond counts. So does every byte, every CPU cycle, and every unnecessary step we can eliminate. Check out the blog posts below 👇 #DataStreaming #CDC #ResourceEfficiency #DistributedSystems #AIDataInfrastructure #DataStreams #AgentSessions #LaserData #Rust #P99

Fast is good. Predictably fast is what really matters! What does it really take to achieve predictable P99 latency at scale? At P99 CONF, our co-founder and CTO, @spetzu, shared the engineering decisions behind @ApacheIggy, a persistent streaming engine built from the ground up for ultra-low latency and high throughput. Rust. Thread-per-core architecture. io_uring. Zero-copy optimizations. And a relentless focus on eliminating inefficiencies in the hot path. The talk goes beyond benchmarks to explore how architectural choices translate into real-world performance. At @laserdatainc, we believe the next generation of data infrastructure should deliver more throughput, predictable tail latencies, and dramatically better infrastructure efficiency. That’s the philosophy behind Apache Iggy, and the foundation we’re building on. Every millisecond counts. So does every byte. youtube.com/watch?v=2j6BzKaO… #ApacheIggy #P99CONF #Rust #DistributedSystems #LaserData

Squeezing out what today's hardware is capable of requires designing around it from scratch. @laserdatainc's @spetzu explains how they did that in #Rustlang during a highly technical #P99CONF talk. Don't miss this one, it's free! ow.ly/zT6h50ZZ132 #ScyllaDB

We've been cooking. Multi-leader clustering is coming to Apache Iggy, with every node leading its own partitions. 3-node cluster at 800 MB/s: p999 down 93% replicated, 87% persisted, +42% producer throughput. github.com/apache/iggy #iggy #asf #rust #streaming #performance

Jordan Epstein: Ouch, you didn’t like my name? 🥲 I thought I had a pretty cool one! Iggy = Italian Greyhound. One of the fastest dogs in the world. 🐕⚡ Fast dog. Fast streaming engine. Now does the name make a little more sense? 😄 lnkd.in/p/gWw8x8Rc

This one made me smile. 🙂 Interesting to see @ApacheIggy contributors/engineers being approached to help “shape the future of Kafka.” Meanwhile, the Iggy community is busy refining what the future of message streaming engines should look like. Rust. Modern I/O. Predictable tail latency. Multi-protocol by design. Developer experience from day one. All respect to Kafka and everything it has done for distributed systems and data streaming. And inspiring us in many ways! Back to building! #ApacheIggy #Rust #Kafka #Streaming #OpenSource

Apache Iggy 0.9.0 is out, our first release as a Top-Level Project! ⚡ Clustering has landed. Powered by Viewstamped Replication Revisited (VSR). 600+ PRs. 60 contributors, 34 of them new. Message streaming at laser speed, now highly available. iggy.apache.org/blogs/2026/0… #iggy #asf

One more stream is here. 💚 Today marks the beginning of a new chapter for @laserdatainc We’re bringing together three worlds that have largely evolved independently: 1. Real-time message streaming. 2. Agent Data Fabric. 3. Real-time applications. One infrastructure. One durable foundation. Today we’re announcing major new capabilities across the stack, from VSR-based clustering in @ApacheIggy and Agent Data Exchange (AGDX) Protocol for agent-agent-system data exchange, to new LaserData Cloud plans (launch, scale, performance, and enterprise) and deployment options across AWS and GCP. All these capabilities are in PRIVATE BETA, will be GA on September 18, 2026. And we’re just getting started. We’ll continue shipping throughout the year. But once in a while, we’ll take a moment to bring together the biggest ideas we’ve been working on and share where we’re taking real-time and agent data infrastructure next. Welcome to the next chapter of LaserData. 🚀