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: https://posetteconf.com
✅ Learn more:  watch more POSETTE talks: https://aka.ms/posette-playlist

📌 Let’s connect:  
LinkedIn: https://www.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

Microsoft Developer

A deep technical dive into the hidden costs of PostgreSQL connections at the Linux level. Covers multi-process vs thread architecture, virtual memory and page table overhead (why huge pages matter for shared buffers), NUMA architecture behavior and pinning policies, Linux CPU scheduler changes (CFS vs EEVDF in kernel 6.6+), practical connection-per-core guidelines, real work_mem behavior measured via smaps, and PostgreSQL-level bottlenecks including MVCC snapshot scaling and fast-path lock limits improved in Postgres 18.

Linux and PostgreSQL in the Multiverse of Connections | POSETTE: An Event for Postgres 2026