Today I present results from the first step towards enabling temporary tables in PostgreSQL parallel query execution: benchmarking sequential writes and reads of temp buffers. I added functions to the PostgreSQL system catalog to measure buffer flush operations and ran a set of tests. For the planner, I estimated the cost coefficient of flushing a temporary table buffer page to disk relative to the existing DEFAULT_SEQ_PAGE_COST. I also estimated the cost of a simple scan of temp buffers (a dry-run). Measurements show that sequential writes are about 30% slower than reads. Based on these results, I propose a cost formula. I also ran a limited “dry-run” style estimate and measured write speed when table blocks are distributed across memory pages randomly.

There’s a dangerous illusion that “vanilla” open source is a silver bullet for enterprise systems. A real-world stress test of recent years has shown the opposite: when familiar giants like Oracle step aside, plain PostgreSQL often turns into a pumpkin under true enterprise workloads.

Mark Rivkin, Head of technical consulting at Postgres Professional, shares his personal perspective on why teams end up reinventing the wheel — adding millions of lines of code to the core — and why the future belongs to converged database systems.

Disclaimer: this article reflects the author’s independent expert opinion.

Мы продолжаем серию интервью с разработчиками Postgres Professional, которые получили медали за вклад в ванильный PostgreSQL. Почему полезен даже не принятый сообществом патч и при чём здесь везение, сегодня расскажет Александр Пыхалов.

In the IT crowd, it’s common to mock HR for their weird terminology and attempts to assess a “rich inner world” instead of clean code. But when a senior starts tearing juniors apart in code reviews to the point where they end up crying in the bathroom, nobody’s laughing anymore.

We pit two archetypes against each other: the “toxic genius” and the “human glue”. Which one is dead weight, and which one is the load-bearing structure of the project? You might not like the answer.

Your service has just published a message to RabbitMQ — and then, right at commit time, the database transaction rolls back. The classic distributed-systems nightmare: ghost data, broken consistency, and hours lost to debugging. Usually you fight this with tricky custom code, two-phase commits, or just… crossing your fingers. But what if a PostgreSQL rollback could automatically “roll back” the message too, putting it back into the queue without you writing a single extra line? Here’s how that works.

Когда речь заходит об оптимизации базы данных, разработчики обычно перечисляют привычный набор приёмов: слегка переписать запрос, накинуть индекс на колонку, денормализовать, сделать analyze, vacuum, cluster, и так по кругу. Классические техники, конечно, работают, но иногда креативный подход даёт гораздо больше.

В этой статье Haki Benita показывает нетипичные техники оптимизации в PostgreSQL.

Клиент, с проблемы которого всё началось, решил её сам — сменил фреймворк и даже не стал дожидаться патча. Но Алёна Рыбакина всё равно продолжила работу — ещё год. Теперь её OR-ANY Transformation — часть PostgreSQL, а сама она — обладательница медали сообщества. Интервью о том, как случайный клиентский баг превращается в вклад в мировой open source.

You’ve probably had this happen too: a service runs smoothly, keeps users happy with its stability and performance, and your monitoring stays reassuringly green. Then, the next moment — boom, it’s gone. You panic, dive into the error logs, and find either a vague segfault or nothing at all. What to do is unclear, and production needs saving, so you bring it back up — and everything works just like before. You try to investigate what happened, but over time you switch to other tasks, and the incident fades into the background or gets forgotten entirely.

That’s all fine when you’re on your own. But once you have many customers, sooner or later you start feeling that something isn’t right, and that you need to dig into these spikes of entropy to find the root cause of such incidents.

This article describes our year-long investigation. You’ll learn why PostgreSQL (and any other application) can crash because of a bug in the Linux kernel, what XFS has to do with it, and why memory reclamation might not be as helpful as you thought.

Asynchronous I/O, ML-based query plan optimization, and built-in connection pooling are among the key features of the new Postgres Pro Enterprise 18. This release brings together the capabilities of the vanilla PostgreSQL 18 core with Enterprise-grade tools for working with large-scale data. Today we will walk through the technical details, new index scanning strategies, and mechanisms for scaling write workloads.

Базы данных прибыльнее нефти? В 2025 году Ларри Эллисон стал самым богатым человеком в истории человечества, обойдя Рокфеллера. Тем временем на рынке M&A настоящий пожар: миллиардные сделки, банкротства и судебные иски MongoDB против конкурентов. Перевели подробный разбор того, кто выиграл, а кто проиграл в битве за данные в этом году.

Today we want to talk about choosing a DBMS for WMS not as a dry technical discussion, but as a strategic decision that determines the security, budget, and future flexibility of your business. This is not about "why PostgreSQL is technically better," but about why it has become the only safe, cost-effective, and future-proof solution for Russian warehouse systems in the new reality.

This is not just another database article. It is a roadmap for those who do not want to wake up one day with a paralyzed warehouse and multi-million fines due to a bad decision made yesterday. At INTEKEY we have gone this path deliberately, and today our WMS projects for the largest market players run on PostgreSQL. We know from experience where the pitfalls are and how to avoid them.

Bulk config rollouts, built-in OpenTelemetry, and two-click HA cluster control are all part of one goal: making PostgreSQL admin simpler and safer. PPEM 2.3 is a big step toward that — with user-defined presets, a reworked alerting system, and stronger RBAC — helping you bring order to messy configs and trust the system to warn you before things go sideways.

Some IT companies say they support open source. In practice, that often boils down to using other people’s code and a bit of PR. We believe real contribution means commits to the core. And to do that consistently, we opened an engineering center not in a glossy capital business park, but in a place where fundamental science is part of the cultural DNA. Here’s why we’re building the future of systems programming in Novosibirsk Akademgorodok.

Все любят безопасность, пока не приходится её настраивать. Первая версия нашего аудита напоминала пульт управления АЭС: бесконечно гибко, но без инструкции не взлетишь. Мы признали поражение, послушали стоны администраторов и сделали версию 2.0 — с классами событий и логикой, понятной человеку, а не только компилятору. История работы над ошибками, которая превратила «полочный» софт в рабочий инструмент, в нашей статье.

Hitting the 4-billion-row limit in a TOAST table or running into an OidGen lock during a massive document import is a PostgreSQL admin’s nightmare. Sure, architects will tell you to push files to S3 — but real life often means keeping them inside the database. In this post, application optimization lead Alexander Popov breaks down how the standard bytea and pg_largeobject mechanisms work, where their bottlenecks hide, and how Postgres Pro Enterprise helps you get around those limits.

Throughout their careers engineers build systems that protect data and guard it against corruption. But what if the right approach is the opposite: deliberately corrupting data, generating it out of thin air, and creating forgeries indistinguishable from the real thing?

Maksim Gramin, systems analyst at Postgres Professional, explains why creating fake data is a critical skill for testing, security, and development — and how to do it properly without turning your database into a junkyard of “John Smith” entries.

Technical support comes in many shapes. Sometimes it’s "try rebooting" or "check the cable." And sometimes it’s deep engineering work you wouldn’t mind dedicating your whole life to. Which version lives inside Postgres Professional, and what’s more important in this field — people or tech? We dig into this with Kamil Karimov, Senior technical support engineer at Postgres Professional.

For businesses running 1C:Enterprise, database stability and speed aren't nice-to-haves—they're make-or-break. At Postgres Professional, we're constantly working on the DBMS core, eliminating architectural bottlenecks that show up under the heavy loads typical of 1C deployments.

We've just released Postgres Pro Enterprise 17.6 with a fresh batch of improvements specifically for 1C users.

Everyone knows great documentation makes or breaks a tech product — but few realize how much work goes into it. At Postgres Professional, the docs are written with the same discipline as the code. What’s even more impressive, all of it is done by a team of just ten people. We talked to senior technical writer Ekaterina Gololobova to see how it really works — from the first task to the final commit.

One of the open challenges in the database world is keeping a database consistent across multiple DBMS instances (nodes) that independently handle client connections. The crux of the issue is ensuring that if one node fails, the others keep running smoothly — accepting connections, committing transactions, and maintaining consistency without a hitch. Think of it like a single DBMS instance staying operational despite a faulty RAM stick or intermittent access to multiple CPU cores.

My name is Andrey Lepikhov, and I’d like to kick off a discussion about the multi-master concept in PostgreSQL: its practical value, feasibility, and the tech stack needed to make it happen. By framing the problem more narrowly, we might find a solution that’s genuinely useful for the industry.