The article critiques the common argument that "Postgres is enough" for most use cases, particularly when it comes to replacing Kafka. It points out that Postgres and Kafka serve fundamentally different purposes. While some argue that Kafka's complexity and cost make it unnecessary for smaller applications, the author believes this oversimplifies the issue and can lead to poorly designed systems. Postgres is a relational database, while Kafka is an event streaming platform, and using them interchangeably can result in significant challenges. The author highlights specific features of Kafka that make it beneficial for certain applications. Kafka's log semantics allow for persistent, ordered event logs that can be replayed and processed with exactly-once semantics. This is crucial for use cases like fraud detection and real-time data processing, where low latency and reliability are key. The fault tolerance and high availability of Kafka are also emphasized. Unlike Postgres, where all writes go to a single node, Kafka's distributed architecture allows for seamless failover and load balancing among multiple consumers. The piece also addresses the complexities of using Postgres for queuing tasks, noting that while it can be done, it often leads to issues like MVCC bloat and WAL pile-up. The author encourages readers to consider the specific problems they want to solve before deciding on a tool. For applications requiring high scalability, low latency, and reliable message processing, Kafka remains a better fit, even at smaller scales.