Operations | Monitoring | ITSM | DevOps | Cloud

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%.