Operations | Monitoring | ITSM | DevOps | Cloud

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.