消息队列这摊水，Kafka泡了十几年。一个工程师偏不信，拿Postgres的表硬顶上，现在半年账单一出，社区吵翻了。

起因是维护噩梦。原博主管着一个小集群，ZooKeeper抽风、Broker宕机、消费组重平衡——半夜报警比闹钟还准时。「我只是想要一个能用的队列，不是一份全职工作。」他在博客里写道。

方案简单粗暴：一张表，三字段——id、payload、processed_at。生产者INSERT，消费者SELECT FOR UPDATE SKIP LOCKED，处理完UPDATE标记。没Broker，没分区，没消费者组协调，整本《Kafka权威指南》直接扔进垃圾桶。

半年跑下来，吞吐量撑到每秒3000条，延迟10毫秒级，账单从每月几百刀掉到Postgres实例的固定成本。代价也有：没原生回溯、没多消费组并行、表膨胀要靠手动VACUUM。但他算了笔账：省下的运维时间，够重写三遍业务代码。

Hacker News上两派打作一团。反对派搬出RabbitMQ、NATS、甚至SQLite，说"你这叫队列？这叫轮询数据库"。支持派甩出监控截图：我的场景就是单消费组、低延迟、不想养集群，有问题？

博主最后补了条备注：如果你的消息量超过每秒1万条，或者需要多个独立消费组，请关闭此页面，乖乖回去调Kafka。评论区最高赞是句大实话——"技术选型没有银弹，但确实有子弹更便宜的手枪"。