Operations | Monitoring | ITSM | DevOps | Cloud

PostgreSQL, widely regarded as the world’s most advanced open-source relational database, continues to set the standard for performance, scalability, and flexibility in modern data infrastructure. While it has always been a top contender, each new release of PostgreSQL introduces powerful features and enhancements that make it an even more compelling choice for developers, database administrators, and IT leaders alike.

PostgreSQL is by design lightweight and un-opinionated but its killer feature has long been its extensions ecosystem. The extensions ecosystem adapts and customizes PostgreSQL data storage and manipulation use cases, making it suitable for AI, analytics, document data stores and more. This flexibility keeps PostgreSQL viable as an option for any business or startup, as it’s hard to ‘outgrow’ PostgreSQL.

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.