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.

When platform providers talk about autoscaling, they usually mean one thing: application autoscaling, adding or removing web instances based on traffic. The pattern is well understood. Define a metric, set a threshold, and let the platform act on it. Most platforms still leave database capacity as a separate, mostly manual problem. Teams either pre-provision for the worst hour of the worst day, upgrade plans on a calendar, or wire together their own scaling logic on Kubernetes or RDS.

Application autoscaling has existed for years. Database autoscaling has lagged behind. Today, that changes on Upsun. Managed PostgreSQL and MariaDB read replicas now autoscale, joining worker autoscaling in production since March 2026. Apps, workers, and managed databases all autoscalead replicas saturate first, connection pools max, someone getse on one platform - natively, without a third-party database engine or a Kubernetes layer to operate. Three operational headaches just disappeared.

Cardinality problems usually begin with a small change that looks harmless: you add a label, and suddenly one metric turns into thousands of unique series. Cardinality explosions are often caught only after performance degrades. And at that point, your observability stack may be degraded and painful to troubleshoot. vmestimator is a new project specifically designed to follow cardinality trends in real time and send you alerts before they turn into a real problem.

The numbers from the 2026 State of the Database Landscape: AI Edition are striking. 99% percent of respondents using AI report at least one measurable benefit for their database work. Automation is up, performance is improving, and three-quarters report significant cost savings. By almost any measure, AI is delivering. However, sitting alongside that near-universal positivity in the same dataset, security and privacy concerns have climbed to 64%. Regulatory compliance anxiety has risen to 40%.

In the first half of 2026, we shipped a wide range of improvements across metrics, logs, traces, cloud, and the Kubernetes operator. Our main focus across open-source components and enterprise solutions was on performance, stability, and making observability easier to adopt and operate day‑to‑day. This roundup brings together the most important changes to date, including a quick look back at key anomaly detection improvements from 2025 that are now paying off today.

This set of Redgate Monitor updates brings new AI-powered tooling into how teams work with their estate, alongside expanded coverage for Google Cloud SQL and Contained Availability Groups. Whether you're looking to get faster, insightful answers, plug Monitor into your own AI stack, extend monitoring to a new cloud platform, or keep job visibility intact through a failover, there's something here for you.

With PostgreSQL 19 on the horizon, query planning could get smarter thanks to new query tools and faster maintenance. The release is still a few months away, but Beta 1 already shows where PostgreSQL is headed. Released on June 4, 2026, PostgreSQL 19 Beta 1 previews most of what’s planned for the final release.

Many “LLM observability with OpenTelemetry” tutorials stop at a single chat.completions span. That works for a demo, but it leaves gaps once an agent fans out into 30 tool calls, two vector-DB queries, three handoffs, and a 90-second tail latency you need to attribute. This post wires the OpenLIT SDK (50+ instrumentations, OTel GenAI semantic conventions, one line of code) into the full VictoriaMetrics observability stack and shows query examples that turn agent telemetry into decisions.

“Deployment stress doesn’t just come from high-profile public outages. It often starts much earlier, when a fear of failure seeps into team culture.” Rob Richardson, Software Craftsman Rob certainly knows the stress and embarrassment of public deployment failures. "But overall" he reflects, "I’ve had more stress in my career from internal failures.