Operations | Monitoring | ITSM | DevOps | Cloud

For years, PostgreSQL relied on synchronous I/O, meaning that when the database needed data from disk, each read operation was a blocking system call. The database process would therefore pause and wait for the data retrieval before moving to the next task. Synchronous I/O works well for local storage, but our database needs have changed drastically since then, resulting in this architecture creating significant bottlenecks when storage has higher latency.

Do you like working with time in your code? If yes, you’re likely one of the lucky ones who are blissfully unaware of how deep the rabbit hole goes. If you don’t like it, I have good news for you! Postgres can make working with time more enjoyable! The newly released temporal constraints let you easily maintain referential integrity across temporal relationships. That might seem simple, but it's kind of a big deal. Let’s explore it through an example.

Discover the Best Free Tools to Monitor, Manage, and Visualize Your Kafka Clusters in 2025.

Aiven for OpenSearch is a fully-managed service that provides an ideal way to run OpenSearch on Google Cloud. It is designed for companies looking to operate search applications without taking on the burden and complexity of self-managing the infrastructure in the cloud. Running on Google Cloud, the service is built upon core infrastructure like Google Compute Engine, Google Cloud Storage, and Private Service Connect.

Generated columns have existed in PostgreSQL since version 12. The idea was to allow people to make calculations based on other columns in the table and store them. It makes your life easier by ensuring data accuracy and preventing unauthorized manual modifications. But why, after 6 versions, is PostgreSQL making generated columns virtual and also making this new way the default? This is an example of the types of questions we had when exploring and playing around with this new feature.

Should you use UUIDs as the primary key in your database? You might have heard they are terrible for performance, which is often true for traditional UUIDv4. However, the introduction of UUIDv7 fixes many of the previous issues of UUIDv4. Let’s therefore explore what they are and why it might be a good idea to use them.

Kafka is too expensive and complex for 80% of users. Most Kafka usage is small-data - ~60% of clusters are sub-1 MB/s, yet teams pay big-data prices. Diskless (KIP-1150), Tiered, and Iceberg topics give Apache Kafka multiple storage classes, but they’re advanced storage primitives. They are powerful in the hands of seasoned platform teams but too complex for beginners.

In under a month, OpsHelm the continuous, enriched changelog for cloud infrastructure - migrated its streaming backbone from MSK and NATS to Aiven Diskless Kafka (BYOC on AWS). The switch eliminated cross-cloud networking fees, collapsed multiple storage layers into one, and cut total streaming costs by 5x (from >$50,000/year to <$10,000/year) while serving the team a single logical event bus that stretches across multiple regions and accounts.

The BigQuery Sink connector is a critical piece of Kafka infrastructure that allows you to offload your Kafka topic data into BigQuery in real time. It is the third most-used connector among Kafka users (after the Google Cloud Managed Service for Apache Kafka and the original WePay sink connector), but it's not without its fair share of plot twists. Here's the story of how this connector switched hands three times and we ultimately ended up helping to re-build it.

Aiven is proud to launch the newest version of PostgreSQL, version 18, alongside with the open source community as the first managed PostgreSQL provider to support the latest version. This year we had three Aiveners join in on contributing to this major release, a trend which we hope to only see increase. Congrats to Patrick Stählin, Ronan Dunklau, and Thomas Krennwallner for your contributions to the codebase.