Repository navigation
Remove multiplexing #6449
Description
Activity
Hi @roji,
I've been following the multiplexing feature for a long time and was hoping to see it mature. Is there a specific reason it was removed? Also, are there any alternatives you'd recommend for this kind of performance optimization? I was quite impressed by the benchmarks:
The multiplexing feature - in its current form - does not scale with the number of cores, mainly because all cores produce traffic, but only one core actually aggregates that traffic and sends packets to PostgreSQL; this causes a single bottleneck that becomes more severe as you add more cores. In the TechEmpower scenarios with recent multi-core machines, multiplexing was found to reduce performance rather than improve it.
There are also various other issues with the implementation. For example, since it was implemented before NpgsqlDataSource was introduced, it uses a pretty complex model where an NpgsqlConnection can be in multiplexing, in which case it doesn't represent a connection at all; this adds lots of complexity to the codebase. Today we'd implement this differently, using NpgsqlDataSource only.
Did you personally actually use this and measure a significant improvement? Because otherwise blog posts and synthetic benchmarks don't necessarily point at a feature working well in the real world.
Thank you for the swift response! To answer your question: yes, I actually used it in production, and it solved a critical issue.
I was tasked with addressing a performance bottleneck in an API where Postgres was the limiting factor. The API had multiple instances and was responsible for simple data lookups. The responsible team had a Redis cache in front of it, but when a new campaign launched, the cache would start cold, resulting in a 'thundering herd' of lookups hitting Postgres all at once.
The team's initial solution was to increase the Postgres connection pool size that already hit 400 connections, and they were considering bumping it to 800 because they were still seeing timeouts.
I was alarmed by the 400 connection count, and when I asked about reducing it, I was told 200 wasn't enough to prevent timeouts, so simply reducing the pool size wasn't an option. That’s when I started researching and found Npgsql multiplexing.
I convinced the team to turn on multiplexing and reduce the connection count back down to 200. It solved the timeouts. We then reduced the total pool size to 100; it still worked perfectly, though the team didn't see further performance improvements beyond the stability already gained. I suspect even 50 connections would have been sufficient, but the team lost interest in experimenting.
I personally think multiplexing is a major win for the .NET ecosystem because it removes the need to introduce external connection pooling (like PgBouncer). Given that you've already walked halfway there and learned so much from this initial implementation, I would love to see it redesigned using NpgsqlDataSource rather than being removed entirely.
In fact, I designed my EF Core performance defaults with multiplexing enabled by default:
https://github.com/duranserkan/DRN-Project/blob/master/DRN.Framework.EntityFramework/Attributes/DrnContextPerformanceDefaultsAttribute.cs- added 2 commits that reference this issue
on Feb 28, 2026 - added a commit that references this issue
on Feb 28, 2026