The world's best
PostgreSQL database.
News, articles, customer success stories, and tutorials on PostgreSQL, open source, Redrock Postgres, and more.
As applications grow, PostgreSQL tables inevitably scale from thousands of records to hundreds of millions or even billions. Performance degradation for large tables is rarely sudden; instead, it happens through a process of silent degradation over time.
Scaling Postgres’s high-concurrency handling capability can never rely on simply throwing more hardware at the problem. Each database connection incurs a hidden system tax, including Linux-level memory and CPU overhead, as well as Postgres-level MVCC (Multi-Version Concurrency Control) and locking constraints. To handle high-performance workloads, we need to stop guessing and start precisely tuning our systems by deeply understanding these underlying limitations.
Summary: In this article, we will explore the impact of long transactions on the performance of hot row updates in PostgreSQL.
Summary: In this article, we’ll look into the performance degradation caused by repeatedly updating table rows in a PostgreSQL transaction, and the principles behind it.
Copyright (c) 2017 - 2025, Redrock Data Services, Inc. All rights reserved.
