Kafka memang cepat — saya akan memakai Postgres

• Benchmark publish/subscribe (pub-sub) dan queue di Postgres menunjukkan kemungkinan menggantikan sistem messaging hanya dengan satu database
• Pada satu node 4vCPU, tercapai 5.036 write/detik dan 25.183 read/detik; pada lingkungan replikasi 3 node pun throughput tetap serupa, dengan latensi end-to-end 186ms (p99)
• Pada node besar 96vCPU, tercapai write 238MiB/s dan read 1.16GiB/s, dengan utilisasi CPU di bawah 10%, menunjukkan kapasitas pemrosesan yang masih longgar
• Dalam pengujian queue juga, satu node mampu menangani 2.885 transaksi/detik, dan pada lingkungan replikasi tetap bisa memproses 2.397 transaksi/detik, cukup untuk sebagian besar skala perusahaan
• Alih-alih sistem terdistribusi yang kompleks, hasil ini menunjukkan bahwa infrastruktur Postgres tunggal pun dapat menangani workload beberapa MB/s, sambil menekankan pendekatan praktis: “gunakan teknologi sederhana sampai benar-benar perlu yang lebih rumit”

---

Dua kubu dalam memilih teknologi

• Industri teknologi terbagi menjadi kubu yang berpusat pada jargon dan kubu yang berlandaskan akal sehat
  • Kubu pertama tertarik pada istilah pemasaran seperti “real-time”, “skalabilitas tanpa batas”, dan “berbasis AI”
  • Kubu kedua lebih mengutamakan kesederhanaan dan kepraktisan, serta menghindari kompleksitas yang tidak perlu
• Belakangan ini, dua arus yaitu Small Data dan renaisans Postgres memperkuat kubu kedua
  • Data makin kecil, sementara hardware makin kuat
  • Postgres dapat menggantikan berbagai solusi khusus tujuan sebagai satu sistem tunggal (jsonb, pgvector, tsvector, dll.)

Gambaran benchmark

• Tujuan: mengukur sejauh mana Postgres dapat diskalakan untuk messaging pub/sub dan pemrosesan queue
• Lingkungan pengujian: AWS EC2 c7i.xlarge (4vCPU) dan c7i.24xlarge (96vCPU)
• Perbandingan tiga konfigurasi
  • node tunggal
  • klaster replikasi 3 node
  • node tunggal berukuran besar

Hasil benchmark Pub/Sub

• Node tunggal 4vCPU
  • write 4.8MiB/s (5.036msg/s), read 24.6MiB/s (25.183msg/s), latensi 60ms (p99)
  • CPU terpakai 60%, disk write 46MiB/s
• Replikasi 3 node 4vCPU
  • write 4.9MiB/s, read 24.5MiB/s, latensi 186ms (p99)
  • throughput tetap terjaga, biaya tahunan sekitar $11.514
• Node tunggal 96vCPU
  • write 238MiB/s (243kmsg/s), read 1.16GiB/s (1.2Mmsg/s), latensi 853ms (p99)
  • CPU di bawah 10%, bottleneck ada pada kecepatan write per partisi
• Kesimpulan: cukup kompetitif dengan Kafka untuk workload kecil hingga menengah, dan dengan struktur sederhana pun mampu menangani puluhan MB/s

Hasil benchmark Queue

• Implementasi queue sederhana berbasis SELECT FOR UPDATE SKIP LOCKED
• Node tunggal 4vCPU
  • 2.81MiB/s (2.885msg/s), latensi 17.7ms (p99), CPU 60%
• Replikasi 3 node 4vCPU
  • 2.34MiB/s (2.397msg/s), latensi 920ms (p99), CPU 60%
• Node tunggal 96vCPU
  • 19.7MiB/s (20.144msg/s), latensi 930ms (p99), CPU 40~60%
• Bahkan dengan satu node saja, kebutuhan throughput queue di sebagian besar perusahaan dapat terpenuhi

Kapan memilih Postgres

• Dalam banyak kasus, menjadikan Postgres sebagai pilihan default adalah keputusan yang masuk akal
  • Pesan bisa di-debug, diubah, dan di-join langsung dengan SQL
  • Dibanding Kafka, operasional lebih sederhana dan perawatan lebih mudah
• Kafka dioptimalkan untuk performa tinggi, tetapi untuk workload kecil, itu sering menjadi pilihan yang berlebihan
• Mengutip peringatan Donald Knuth: “optimasi prematur adalah akar dari segala kejahatan”
  • Sampai level beberapa MB/s, Postgres sudah lebih dari cukup

Pendekatan MVI (Minimum Viable Infrastructure)

• Minimum Viable Infrastructure: membangun sistem seminimal mungkin dengan teknologi yang sudah akrab di organisasi
  • Postgres diadopsi luas dan relatif mudah mencari tenaga yang menguasainya
  • Semakin sedikit komponen, semakin kecil beban gangguan dan operasional
• Adopsi teknologi yang tidak perlu akan menimbulkan overhead organisasional
  • Biaya belajar, monitoring, deployment, dan operasional meningkat

Pembahasan skalabilitas

• Postgres pada praktiknya memang bisa diskalakan
  • OpenAI sampai sekarang masih menggunakan Postgres berbasis single write instance
  • Tetap berjalan stabil bahkan pada skala ratusan juta pengguna
• Sebagian besar perusahaan tumbuh secara bertahap, sehingga masih ada jeda beberapa tahun sebelum perlu mengganti teknologi
• “Merancang untuk mengantisipasi viral” adalah bentuk overdesign
  • Diibaratkan seperti “membeli ampli Marshall untuk tampil sebagai pembuka konser Coldplay”

Kesimpulan

• “Gunakan Postgres sampai benar-benar mentok”
  • Dengan teknologi sederhana pun, performa yang didapat bisa sangat tinggi
  • Mengadopsi sistem terdistribusi yang kompleks sebelum perlu justru tidak efisien
  • Dengan hardware modern, Postgres adalah pilihan praktis yang mampu menangani sebagian besar workload saat ini