Uploaded June 2026 | Updated September 2026, 2 weeks ago
Explore how connection handling behaves across systems and environments. Josef Machytka (credativ GmbH) discusses this in his talk “Linux and PostgreSQL in the Multiverse of Connections” at POSETTE: An Event for Postgres 2026. Abstract: PostgreSQL connections are expensive, their count is often the limiting factor for performance and stability. Connection pooling is a primary scaling tool for modern systems with microservices, short-lived clients, and bursty traffic. We all know it, but do we really understand why? This talk offers a deep dive into PostgreSQL and Linux architecture, explaining the concrete costs of “too many connections” in PostgreSQL’s process-per-connection model. We will discuss CPU overhead from context switching; kernel resources such as sockets and file descriptors; differences between the classic Completely Fair Scheduler (CFS) and its newer EEVDF-based scheduling approach; limitations of MVCC snapshot implementation across different PostgreSQL versions; accumulation of allocations in per-session memory contexts; and how much memory a query can allocate during execution. We will also look for guidance on “maximum active connections per CPU core” for OLTP vs. OLAP.
Key takeaways
* Pool when churn and burstiness dominate
* High connection counts amplify CPU context switching
* Idle sessions still consume memory
* Think in “active connections per core”
* Beware the thundering herd
* Version and platform choices influence limits
Josef Machytka (credativ GmbH) has 33+ years of production experience with different databases: PostgreSQL 13 years, BigQuery 7y, Oracle 15y, MySQL 12y, Elasticsearch 5y, MS SQL 5y, Sybase ASE, FoxPro. Josef also has 10+ years of experience with high volume and velocity data ingestion pipelines, Data Analysis, Data Warehouse and Data Lakehouse architecture plus 3+ years of practical experience with ML / LLMs, their usage, architecture and principles.
► Video chapters:
⏩ 00:00 – Music & Introduction
⏩ 00:39 – Speaker introduction: credativ and Postgres workloads
⏩ 01:31 – Postgres multi-process architecture overview
⏩ 03:15 – Inter-process communication and tmpfs
⏩ 04:31 – 64-Bit address space and page-table hierarchy
⏩ 05:48 – Postmaster forks, shared buffers, and the TLB
⏩ 07:04 – Why huge pages matter: the PTE blowup
⏩ 08:55 – NUMA architecture on a Phytium test server
⏩ 11:50 – NUMA binding policies and interleaved mode
⏩ 14:03 – Context switching and the EEVDF scheduler change
⏩ 18:49 – How many connections per CPU core?
⏩ 20:01 – Per-connection memory and the smaps interface
⏩ 21:42 – The work_mem mystery and heap allocation
⏩ 24:46 – MVCC snapshots and fast-path locking limits
📕 Everything you need to know about POSETTE: An Event for Postgres can be found at: posetteconf.com
✅ Learn more: watch more POSETTE talks: https://aka.ms/posette-playlist
📌 Let’s connect:
LinkedIn: linkedin.com/company/posetteconf
X – @PosetteConf, https://x.com/PosetteConf
Mastodon – @posetteconf, https://mastodon.social/@posetteconf
Bluesky – @posetteconf.com, https://aka.ms/posette-on-bluesky
#PosetteConf #PostgreSQL #database
Explore how connection handling behaves across systems and environments. Josef Machytka (credativ GmbH) discusses this in his talk “Linux and PostgreSQL in the Multiverse of Connections” at POSETTE: An Event for Postgres 2026. Abstract: PostgreSQL connections are expensive, their count is often the limiting factor for performance and stability. Connection pooling is a primary scaling tool for modern systems with microservices, short-lived clients, and bursty traffic. We all know it, but do we really understand why? This talk offers a deep dive into PostgreSQL and Linux architecture, explaining the concrete costs of “too many connections” in PostgreSQL’s process-per-connection model. We will discuss CPU overhead from context switching; kernel resources such as sockets and file descriptors; differences between the classic Completely Fair Scheduler (CFS) and its newer EEVDF-based scheduling approach; limitations of MVCC snapshot implementation across different PostgreSQL versions; accumulation of allocations in per-session memory contexts; and how much memory a query can allocate during execution. We will also look for guidance on “maximum active connections per CPU core” for OLTP vs. OLAP.
Key takeaways
* Pool when churn and burstiness dominate
* High connection counts amplify CPU context switching
* Idle sessions still consume memory
* Think in “active connections per core”
* Beware the thundering herd
* Version and platform choices influence limits
Josef Machytka (credativ GmbH) has 33+ years of production experience with different databases: PostgreSQL 13 years, BigQuery 7y, Oracle 15y, MySQL 12y, Elasticsearch 5y, MS SQL 5y, Sybase ASE, FoxPro. Josef also has 10+ years of experience with high volume and velocity data ingestion pipelines, Data Analysis, Data Warehouse and Data Lakehouse architecture plus 3+ years of practical experience with ML / LLMs, their usage, architecture and principles.
► Video chapters:
⏩ 00:00 – Music & Introduction
⏩ 00:39 – Speaker introduction: credativ and Postgres workloads
⏩ 01:31 – Postgres multi-process architecture overview
⏩ 03:15 – Inter-process communication and tmpfs
⏩ 04:31 – 64-Bit address space and page-table hierarchy
⏩ 05:48 – Postmaster forks, shared buffers, and the TLB
⏩ 07:04 – Why huge pages matter: the PTE blowup
⏩ 08:55 – NUMA architecture on a Phytium test server
⏩ 11:50 – NUMA binding policies and interleaved mode
⏩ 14:03 – Context switching and the EEVDF scheduler change
⏩ 18:49 – How many connections per CPU core?
⏩ 20:01 – Per-connection memory and the smaps interface
⏩ 21:42 – The work_mem mystery and heap allocation
⏩ 24:46 – MVCC snapshots and fast-path locking limits
📕 Everything you need to know about POSETTE: An Event for Postgres can be found at: posetteconf.com
✅ Learn more: watch more POSETTE talks: https://aka.ms/posette-playlist
📌 Let’s connect:
LinkedIn: linkedin.com/company/posetteconf
X – @PosetteConf, https://x.com/PosetteConf
Mastodon – @posetteconf, https://mastodon.social/@posetteconf
Bluesky – @posetteconf.com, https://aka.ms/posette-on-bluesky
#PosetteConf #PostgreSQL #database
