I'm always a bit skeptical about benchmarks like this. There's quite a few knobs you want to adjust for a production PostgreSQL on bigger hardware. And the article doesn't provide any configuration details (like shared buffers, is huge pages enabled).

The effect is visible at 500 connections, not at 250. The CPU is a Threadripper with 64 cores and 128 GB memory, which seems like a bit of a mismatch to me. So I wonder how transferable these benchmarks are to different setups.

  # start server
  SHARED_BUFFER_SIZE=\`echo \"\$SYS_MEMORY * 0.25 / 1\" | bc\`
  SHARED_BUFFER_SIZE=\$(( \$SHARED_BUFFER_SIZE < 8192 ? \$SHARED_BUFFER_SIZE : 8192 ))
  echo \"Buffer size is \${SHARED_BUFFER_SIZE}MB\" > \$LOG_FILE
  pg_/bin/pg_ctl start -o \"-c max_connections=6000 -c  shared_buffers=\${SHARED_BUFFER_SIZE}MB\"
  # wait for server to start

I wonder how this behaves with VMs, does this help when the host uses this scheduling, but the VM not? Does both make sense? - the vm threads are probably not pinned to cores.

In an case, a great boost for containers on bare metal or maybe core-pinned VMs.

Beautiful generational leap here, so so so good!

I'm also excited to see what folks get up to with sched_ext, this year & ongoingly. Scheduling becoming BPF programmable hopefully shows some other neat wins too.