Earlier quoted context omitted.
> Has this person actually benchmarked kafka? Is anyone actually reading the full article, or just reacting to the first unimpressive numbers you can find and then jumping on the first dismissive comment you can find here? Benchmarking Kafka isn't the point here. The author isn't claiming that Postgres outperforms Kafka. The argument is that Postgres can handle modest messaging workloads well enough for teams that do…
Then the author should have gone on to discuss not just the implementation they now have to maintain, but also all the client implementations they'll have to keep re-creating for their custom solution. Or they could talk about all the industry standard tools that work with kafka and not their custom implementation. Or they could have not mentioned kafka at all and just demonstrated their pub/sub implementation with P…
Client impl. can be re-created once in a library/extension and be done with.
The network effect of Kafka is the hardest to topple. The API is standard. If you need that connectivity, then use Kafka.
An alternative idea I did not mention is to use a Kafka API proxy on top of Postgres. Tansu is developing this (amongst other pluggable backends) - https://github.com/tansu-io/tansu; That solution would retain both the client implementations and tools (network effect). But it comes at extra complexity