I work with a Windows-based COTS webapp that uses Postgres w/o any connection pooling. It's nearly excruciating to use because it spins-up new Postgres processes for each page load. If not for the fact that the Postgres install is "turnkey" with the app I'd just move Postgres over to a Linux machine.
We're really talking about X-per-client as the primary reason to move away from processes, right?
So if you can get most of the benefit via pooling... why inherit the pain of porting?
Presumably latency jitter would be a difficult problem with pools, but it seems easier (and safer) than porting processes -> threads.
Disclaimer: High performance / low latency DB code is pretty far outside my wheelhouse.
Could you point out, aside from the large numbers of clients I mentioned (and the development overhead of implementing multi-process memory management code), what the article mentions is a primary drawback of using processes over threads?
Many other things too. Like better sharing of caches. Lower overhead of thread instead of process. Etc. (read the thread)