Administrating

Here I describe the results of developing a PostgreSQL extension I built just out of curiosity. Its purpose is to automatically manage extended column statistics. The idea came to me while finishing work on another "smart" query-driven product for improving PostgreSQL planning quality. I realized that the current architecture of PostgreSQL isn’t quite ready for fully autonomous operation — automatic detection of bad plans and adaptive optimizer tuning. So why not try the other way around and build an autonomous data-driven assistant?

How to compare the efficiency of SQL query plans? “Measure the execution time, of course!” — an experienced reader would say. And they would be absolutely right: from a practical perspective, the more efficient DBMS is the one that delivers higher TPS. However, sometimes we need to design a system that doesn't exist yet or predict behavior under loads that haven't occurred yet. In such cases, we need a characteristic that allows us to perform a qualitative analysis of a plan or compare two plans. This post is dedicated to one such characteristic — the number of data pages read.

For years, we’ve studied Oracle to make PostgreSQL a more migration-friendly option. We introduced tools similar to SQL profile and SQL plan baseline as AQO and sr_plan extensions. In some cases, PostgreSQL even outperforms Oracle, especially in automatic re-optimization.

Migrations from Oracle to PostgreSQL are usually smooth performance-wise, and we’ve even developed session variable extensions to make the transition easier. While many enterprise-only features exist, PostgreSQL often integrates popular solutions directly into the core.

Hi everyone, I’m Alexey. I’m a big fan of observability, and in this post, I want to share something I’ve been working on — the pgpro-otel-collector.

TL;DR: pgpro-otel-collector is an OpenTelemetry collector (aka monitoring agent) tailored for gathering Postgres metrics and logs — brought to you by PostgresPro.

Ashamed to admit, I still use Swarm in 2025. It's easy to explain, quick to set up, and simple to use. It's a starting point in the world of containers when full-blown Kubernetes is overkill. But Docker's evolution hasn't been the most straightforward. Over time, it began to lack a minimal dynamic proxy for Swarm - one that you run once, which configures traffic routing to microservices automatically - and forget about it. That's how Millau was born - an ingress-proxy and load balancer based on labels. It currently powers its own website and a few other projects.

If you've ever run multiple instances of PostgreSQL or other software on a single machine (whether virtual or physical), you've probably encountered the "noisy neighbor" effect — when instances disrupted each other. So, how do you make them get along? We’ve got the answer!

You may have already read in the news that on the eve of Cosmonautics Day, a new stable release of Angie 1.9.0 was released, an nginx fork that continues to be developed by the team of former nginx developers. Approximately every quarter, we try to release new stable versions and delight users with numerous improvements. This release is no exception, but it's one thing to read a dry changelog and quite another to get to know the functionality in more detail, to learn how and in which cases it can be applied.

The list of innovations that we will discuss in more detail:

— Saving shared memory zones with cache index to disk;
— Persistent switching to a backup group of proxied servers;
— 0-RTT in the stream module;
— New busy status for proxied servers in the built-in statistics API;
— Improvements to the ACME module, which allows automatic obtaining of Let's Encrypt TLS certificates and others;
— Caching TLS certificates when using variables.

If you work with PostgreSQL, you've likely run into performance issues at some point — especially as your database grows. Things may have been running smoothly at first, but as your client database expanded, queries started slowing down. Sound familiar? Here's a guide to help you identify and fix problematic queries, so you can get your PostgreSQL database running at peak performance again.

Imagine a familiar situation: it’s Monday morning, tasks are piling up, and you need to quickly spin up a new service using Postgres Pro. Or maybe you’ve just upgraded your database server over the weekend — added more CPUs, more RAM.

Here’s how to get your database tuned and ready to make the most of the new hardware and workload, without wasting time.

DBAs often struggle to identify the most resource-hungry processes that degrade system performance. Back in 2017, DBA — and now Postgres Professional engineer — Andrey Zubkov faced the same challenge. This led him to develop pg_profile for PostgreSQL, which has since evolved into pgpro_pwr.

In this article, we’ll dive into strategic database monitoring and show you how to pinpoint bottlenecks in your databases using our tools.

Setting up a v3 user on the server-side agent for the default Linux snmpd (net-snmp package). Out of scope: SNMP traps and read-write (rw) users.

SNMP version 3 allows packet transmission in encrypted form, making it safe to transfer telemetry over public networks without the risk of exposing either authentication information (analogous to a community string) or the data stream itself, which is encrypted using a symmetric algorithm with a shared key.