Operations | Monitoring | ITSM | DevOps | Cloud

This month is a big one! We announced the latest major release of Redgate Flyway Enterprise, built to help teams move fast with AI without losing control of the database. Three key new capabilities also landed in preview: Flyway’s MCP server, advanced support for Databricks, and Oracle schema existence checks. And we're closing with a short, honest read on failure and what it takes to make deployments less stressful. Here's the round-up.

Versioning reference data in Git with Liquibase OSS changelogs enables consistent, auditable, and automated deployments across environments. Using loadUpdateData with versioned CSV files provides fast, reliable rollbacks and reduces production risk. Modern applications do not just depend on schema changes. They also depend on data that powers the application itself.

"Connection pool exhausted" is one of PostgreSQL's most misleading production errors. The database is often healthy, while your application waits behind full connection pools. In Kubernetes, every pod and replica maintains its own pool, amplifying issues like connection leaks and slow queries across the cluster.

I wanted a Postgres replica that falls behind its primary. Sounds easy. It wasn't. Every time I cut the replica off from the primary, its lag jumped for a moment and then dropped right back to zero. It just would not stay behind. Chasing down why turned into a fun little tour of how a Postgres standby keeps itself alive, and what CloudNativePG quietly sets up behind the scenes.

With a robust background in cloud technology and a passion for promoting its merits and potential, I am thrilled to spearhead conversations and actions that help shape the future of this industry. Kellyn has authored numerous technical books, white papers and solution repositories in GitHub on database, AI and engineering topics.

As AI agents accelerate software development and spin up applications at scale, visibility into what's happening behind the scenes, including query performance and database health, has never been more important. Gaining that level of insight requires observability that can keep pace.

Autovacuum is one of those Postgres background jobs that quietly keeps your database healthy. It cleans up the dead row versions that every UPDATE and DELETE leaves behind, and it keeps the database away from a hard transaction-ID limit that would take it offline. Most of the time you don't think about it, because it just works.

This post is a joint effort by the OpenLIT and VictoriaMetrics teams. OpenLIT brings the OTel-native GPU collector for NVIDIA, AMD, and Intel hardware, while VictoriaMetrics provides the storage and query layer for the resulting metrics. We wrote it together to show how the two projects fit into a single, self-hosted observability pipeline, and to share the queries and rules that worked well for us along the way.