Kafgres reaches 700 MB/s produce throughput inside Postgres after replacing a tick loop with socket readiness

Sources: primary, discussion
Summary: The post is a profiling walkthrough of Kafgres, a Postgres extension that embeds a Kafka-protocol broker as a background worker and writes topic bytes straight to disk, and on-CPU profiling put 40.7% of time in parse, analyse and plan for metadata statements alone. Caching SPI plans with SPI_keepplan, relaxing the offset commit behind a relaxed_produce_commit GUC, and a few smaller changes took 256 KiB record throughput from 113.3 MB/s to 197.3 MB/s, and replacing the 5 ms tick loop with Postgres's own WaitEventSet, so the worker blocks until a client socket is readable rather than until the next timer edge, took it to 703.4 MB/s and 600k events per second on a roughly 0.25 dollar per hour Hetzner i9 box. Moving topic data to a second NVMe held the impact on pgbench against the same database under 1% at 100 MB/s, and the author notes the tradeoff Kafgres does not close: it fails over like the Postgres instance does and cannot absorb a zonal outage the way a three-zone Kafka cluster can.
Why it matters: The numbers locate a background worker's cost in statement planning and timer latency rather than in disk, and both fixes are available to any Postgres extension that polls on a tick.