Operations | Monitoring | ITSM | DevOps | Cloud

KIP‑1150 - Diskless Topics is live. KIP-1150 Diskless Topics ship in Aiven Kafka BYOC on AWS, GCP, and Azure. Data goes straight to object storage—no local replicas, up to 80% lower TCO.

In this article, we will be continuing our series of deep dives into KIP-405. Previously, we covered: Now, we turn our attention to the internals of the read and delete paths. Just like we did for the write and metadata, here we will also be focusing on Aiven’s battle-tested Apache-licensed KIP-405 plugin. What makes the read path particularly interesting is how it delivers latency comparable to local disk or memory systems despite leveraging external object storage—let's dive in!

With the introduction of Aiven for AlloyDB Omni, many of our customers have wondered what the difference is between AlloyDB Omni and its architectural source project, open source PostgreSQL. AlloyDB Omni is more than just a re-implementation of PostgreSQL, and understanding how it is similar – and how it differs – from open source PostgreSQL is a valuable exercise.

KIP-1150 isn’t a distant, strange planet; it just reroutes Kafka’s entire replication pathway from broker disks to cloud object storage. Flip one topic flag and your data bypasses local drives altogether: Because Diskless is built into Kafka (no client changes, no forks), we had to solve a 4D puzzle: How do you make a Diskless topic behave exactly like a Kafka one—inside the same cluster—without rewriting Kafka?

KIP-1150 proposes a new class of topics in Apache Kafka that delegates replication to object storage. With disks out of the hot path, the usual pains— cluster rebalancing, hot partitions and IOPS limits are gone, while cross‑zone network fees and pricey local disks drop by as much as 80%.

Aiven offers a seamless multi-service cross-cloud experience. When optimizing your infrastructure performance, understanding how services performance can change across clouds can help differentiate your business. This blog details the benchmarking of how PostgreSQL performs on each of our cloud offerings: AWS, GCP, OCI, and Azure.

The idea behind KIP-405 is to simply store most of the cluster’s data in another service. As we covered in detail in the last article - it’s a simple-sounding idea that goes a very long way. This other server where the data gets stored is pluggable. KIP-405 was designed in such a way to make Kafka seamlessly extensible to store its data in any kind of external store through a solid interface.

Over the past year, we’ve taken significant steps to strengthen our approach, from refining our policies to improving our data collection and aligning with evolving regulatory expectations. Here’s an overview of our progress and what’s ahead for 2025.