🗃️ “Kafka เร็วก็จริง…แต่ Postgres ก็พอแล้ว” — เมื่อระบบ Pub/Sub และ Queue ไม่จำเป็นต้องซับซ้อนเสมอไป บทความนี้ตั้งคำถามกับแนวโน้มในวงการเทคโนโลยีที่มักเลือกใช้เครื่องมือที่ “ล้ำ” เกินความจำเป็น เช่น Kafka สำหรับระบบ pub/sub หรือ queue ทั้งที่ในหลายกรณี PostgreSQL ก็สามารถตอบโจทย์ได้ดีพอ โดยเฉพาะในยุคที่ฮาร์ดแวร์มีประสิทธิภาพสูงขึ้นมาก ผู้เขียนได้ทำการ benchmark เปรียบเทียบประสิทธิภาพของ PostgreSQL ในการทำงานเป็นระบบ pub/sub และ queue โดยใช้แนวทางที่ได้รับแรงบันดาลใจจาก Kafka เช่น การใช้ตาราง log partition, offset, และ consumer group เพื่อจำลองพฤติกรรมของ Kafka 📊 ผลการทดสอบชี้ว่า PostgreSQL สามารถรองรับโหลดระดับหลายแสนข้อความต่อวินาทีได้ โดยเฉพาะในระบบ pub/sub ที่มีการอ่านแบบ fanout สูงถึง 5 เท่า และ latency ที่ยังอยู่ในระดับที่ยอมรับได้ ✅ แนวคิดหลัก ➡️ ไม่จำเป็นต้องใช้ Kafka เสมอไป โดยเฉพาะในระบบที่ไม่ได้มีโหลดระดับ “web-scale” ➡️ PostgreSQL เพียงตัวเดียวสามารถรองรับ use case ได้ถึง 80% ด้วย effort แค่ 20% ✅ ผลการทดสอบ Pub/Sub ➡️ บนเครื่อง 96 vCPU: เขียนได้ 243,000 msg/s, อ่านได้ 1.2 ล้าน msg/s ➡️ latency p99 อยู่ที่ 853ms, p95 ที่ 242ms ➡️ ใช้ CPU เพียง ~10% แสดงถึงศักยภาพที่ยังเหลืออีกมาก ✅ ผลการทดสอบ Queue ➡️ บนเครื่อง 96 vCPU: throughput 20,144 msg/s ➡️ latency p99 อยู่ที่ 930ms ➡️ bottleneck อยู่ที่ single-table design ไม่ใช่ที่ฮาร์ดแวร์ ✅ ข้อดีของการใช้ PostgreSQL ➡️ ใช้ SQL ธรรมดาในการ debug, แก้ไข, ลบ หรือ join ข้อมูล ➡️ ลดความซับซ้อนของระบบและค่าใช้จ่ายในการดูแล ➡️ เหมาะกับองค์กรที่ยังไม่ถึงระดับ scale ใหญ่ บทความนี้ไม่ได้บอกว่า PostgreSQL ดีกว่า Kafka เสมอไป — แต่ชี้ให้เห็นว่า “ความเรียบง่าย” อาจเป็นคำตอบที่ดีกว่าในหลายกรณี โดยเฉพาะเมื่อคุณยังไม่ได้มีปัญหาระดับ “Google-scale” https://topicpartition.io/blog/postgres-pubsub-queue-benchmarks