Administrating

Всем привет! Это вновь Илья Смирнов, архитектор решений из Cloud.ru. В прошлой статье мы рассмотрели традиционные подходы к масштабированию подов и узлов кластера Kubernetes. Но остался нерешенным вопрос — как масштабировать приложение по событиям из внешней системы? Ведь мы хотим, чтобы каждое новое сообщение в очереди RabbitMQ масштабировало нагрузку вверх, реализовать event-driven подход и масштабировать приложение не по метрикам утилизации ресурсов, а по факту появления новых событий от внешних систем. Так как же быть?

Я предлагаю использовать решение KEDA 😉

The story of the PostgreSQL logo was shared by Oleg Bartunov, CEO of Postgres Professional, who personally witnessed these events and preserved an archive of correspondence and visual design development for the database system.

Our iconic PostgreSQL logo — our beloved “Slonik” — has come a long way. Soon, it will turn thirty! Over the years, its story has gathered plenty of myths and speculation. As a veteran of the community, I decided it’s time to set the record straight, relying on the memories of those who were there. Who actually came up with it? Why an elephant? How did it end up in a diamond, and how did the Russian word “slonik” become a part of the global IT vocabulary?

During load testing of Tantor Postgres databases or other PostgreSQL-based databases using the standard tool pgbench, specialists often encounter non-representative results and the need for repeated tests due to the fact that details of the environment (such as DBMS configuration, server characteristics, PostgreSQL versions) are not recorded. In this article we are going to review author's pg_perfbench, which is designed to address this issue. It ensures that scenarios are repeatable, prevents the loss of important data, and streamlines result comparison by registering all parameters in a single template. It also automatically launches pgbench with TPC-B load generation, collects all metadata on the testing environment, and generates a structured report.

The repo of this script is https://gitlab.com/vitaly‑zdanevich/full‑backup/‑/blob/master/full‑backup.sh

Incremental with hard links means that if a file is not changed, on the next backup it will link to the same underlying data, like deduplication. Hard links — its usual files.

Also, this script ignores .gitignore of every folder.

Run this script from another system.

41 TB/day from Oracle to Postgres Pro without stopping the source system — not theory, but numbers from our latest tests. We broke the migration into three stages: fast initial load, CDC from redo logs, and validation, and wrapped them into ProGate. In this article, we’ll explain how the pipeline works, why we chose Go, and where the bottlenecks hide.

Now that pgpro-otel-collector has had its public release, I’m excited to start sharing more about the tool — and to kick things off, I’m launching a blog series focused entirely on the Collector.

The first post is an intro — a practical guide to installing, configuring, and launching the collector. We’ll also take our first look at what kind of data the collector exposes, starting with good old Postgres metrics.

Postgres Pro recently announced the release of Enterprise Manager 2, commonly known as PPEM.

In short, PPEM is an administration tool designed for managing and monitoring Postgres databases. Its primary goal is to assist DBAs in their daily tasks and automate routine operations. In this article, I'll take a closer look at what PPEM has to offer. My name is Alexey, and I'm part of the PPEM development team.

n8n is a powerful, extendable workflow automation tool that allows you to connect different applications and services. Running it on your local machine gives you complete control over your data and workflows, which can be done on Windows, Mac, or Linux systems. This tutorial covers the two primary methods for local installation: using Docker and using Node.js (npm). If you are interested, then read this article until the end. :)

pg_stat_statements is the standard PostgreSQL extension used to track query statistics: number of executions, total and average execution time, number of returned rows, and other metrics. This information allows to analyze query behavior over time, identify problem areas, and make informed optimization decisions. However, in systems with high contention, pg_stat_statements itself can become a bottleneck and cause performance drops. In this article, we will analyze in which scenarios the extension becomes a source of problems, how sampling is structured, and in which cases its application can reduce overhead.

Picture this: a mission-critical SQL query is crawling along. Not for an hour. Not for two. Fifteen hours. A full workday of the system slowly grinding through data while the business bleeds money and users teeter on the edge of a nervous breakdown. And then — cue the dramatic music — in walks the performance engineer.

After a few hours of intense analysis and a couple of pinpoint code tweaks, the same query that took 15 hours now completes in just… two minutes. Sounds like magic? Nope. This is the thrilling (and very real) world of performance engineering.

Today, I want to talk about one of those sneaky tricks that can help speed up query execution. Specifically, this is about reordering conditions in WHERE clauses, JOINs, HAVING clauses, and so on.

The idea is simple: if a condition in an AND chain turns out to be false, or if one in an OR chain turns out to be true, there's no need to evaluate the rest. That means saved CPU cycles — and sometimes, a lot of them. Let’s break this down.

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.