Kafka memang cepat — saya akan memakai Postgres

 (topicpartition.io)
2 poin oleh GN⁺ 2025-10-31 | 1 komentar | Bagikan ke WhatsApp
  • 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
Iklan

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%
    Iklan
  • 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
    Iklan

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

Bacaan terkait

1 komentar

 
GN⁺ 2025-10-31
Pendapat Hacker News

  • Menerapkan prinsip Pareto ke semua situasi adalah interpretasi yang keliru
    Mengatakan bahwa Postgres menangani 80% use case Kafka dengan 20% usaha adalah klaim tanpa dasar
    Prinsip Pareto hanya bermakna dalam situasi di mana distribusi hukum pangkat muncul
    Cukup katakan saja bahwa Postgres mencakup cukup banyak use case, stabil, dan merupakan alat yang sudah teruji

    • Namun ada juga pendapat bahwa pemetaan antara use case dan fitur itu sendiri bisa jadi mengikuti distribusi hukum pangkat

  • Berdasarkan pengalaman menangani skala kecil (ratusan event per jam) hingga skala besar (triliunan event per jam), hal pertama yang harus dipertanyakan adalah apakah queue benar-benar diperlukan

    1. Bisa jadi polling DB sederhana sudah cukup
    2. Jika satu node masih mampu menanganinya, bisa diproses dengan serverless atau proses tunggal
    3. Jika tidak benar-benar butuh distributed queue, load balancing + REST API + retry asinkron juga sudah memadai
    4. Jika benar-benar butuh distributed queue, saya rasa lebih baik memakai solusi khusus seperti Kafka
    • Perlu ditegaskan bahwa Kafka sebenarnya bukan queue melainkan sistem log terdistribusi. Banyak yang salah paham menganggapnya pengganti MQ
    • Di startup, sering kali engineer cenderung memilih teknologi yang rumit dengan memikirkan karier berikutnya alih-alih proyek saat ini
    • Jika struktur kode dirancang agar bisa mendukung queue berbasis PostgreSQL maupun queue berbasis Kafka, migrasi nanti akan lebih mudah
    • PostgreSQL mudah menjadi bottleneck saat beban tulis membesar. Stream UPDATE terutama sangat menyakitkan
    • Sebagai developer Java, saya selalu membutuhkan queue. Polling DB adalah sumber pusing di lingkungan dengan banyak consumer/producer. consumer group dan partition Kafka sangat membantu dalam pengelolaan state

  • Pendekatan memakai Postgres untuk segala hal itu berisiko
    Lock dan level serialisasi tidak intuitif sehingga bisa menimbulkan bottleneck performa
    Saya sudah memakai Postgres selama puluhan tahun, tetapi desain tidak boleh dibuat berdasarkan keyakinan buta

    • Saat traffic melonjak, batas scale-up vertikal menjadi masalah. Kafka menyerap burst traffic, sedangkan Postgres mudah kewalahan
    • Akan bagus jika Postgres punya struktur queue yang berkelanjutan, tetapi scale melampaui level Redis akan sulit, dan LISTEN/NOTIFY tidak bisa diskalakan (tautan terkait)
    • Sebenarnya semua penyimpanan data mengharuskan kita memahami model konkurensi. Bahkan antar relational DB pun ada perbedaan besar
    • Postgres memang sulit diskalakan tanpa batas, tetapi dengan pemrosesan batch dan operasi per-baris tunggal, ia bisa menangani cukup banyak data
    • Secara pribadi, saya biasanya mulai dulu dengan Postgres, lalu jika muncul bottleneck baru beralih ke sistem lain

  • Saya rasa pendekatan tabel log event berbasis SQL itu efektif
    Namun kekurangannya adalah kurangnya alat di sisi klien. Di sinilah Kafka unggul karena ekosistem library-nya kaya
    Perusahaan kami menstandarkan pengiriman event antar-layanan dengan pendekatan berbasis SQL (feedapi-spec)
    Memang belum sematang Kafka, tetapi ada potensi berkembang menjadi stack library umum yang mendukung berbagai storage engine

    • Dengan berkembangnya alat generasi kode berbasis LLM, menutup kesenjangan klien seperti ini jadi lebih mudah
    • Dari sudut pandang orang yang tidak menyukai Kafka, pendekatan seperti ini terlihat jauh lebih menarik

  • Orang-orang belakangan ini terlalu cenderung tertarik pada teknologi baru
    Postgres memang luar biasa, tetapi kita harus memakai alat yang sesuai dengan masalahnya
    Postgres tidak dirancang untuk pub-sub, sementara Kafka dibuat untuk itu
    Kita perlu menghindari tren semua produk yang ingin “melakukan semuanya”. Menurut saya, alat yang sangat baik dalam satu hal itu lebih baik

  • Menerapkan “nomor offset yang meningkat secara monoton” adalah masalah yang rumit
    Sequence sederhana bisa menimbulkan masalah karena urutan transaksi dan waktu commit tidak selaras

    • Salah satu caranya adalah memakai tabel khusus counter dan menjamin urutan lewat lock di dalam transaksi yang sama (tautan referensi)
    • Kita juga bisa menjamin urutan di lingkungan terdistribusi dengan Lamport Clock atau Vector Clock (Lamport timestamp, Vector clock)
    • Daripada memaksakan urutan absolut, pendekatan yang lebih realistis adalah memberi nomor per batch, atau membiarkan proses terpisah memberikan urutan setelah commit
    • Ada juga cara menghindari pemrosesan ganda dengan memakai “SELECT FOR UPDATE SKIP LOCKED”

  • Saya meragukan apakah benchmark Kafka itu benar-benar dilakukan
    Hasil yang diperoleh di lingkungan 96 vCPU bisa dicapai bahkan dengan konfigurasi Kafka 4 vCPU
    Performa Postgres sangat tidak normal lambatnya
    Jika Kafka tidak diperlukan, jangan dipakai, tetapi membanggakan 5k msg/s dengan Postgres itu tidak berarti

    • Redpanda (implementasi kompatibel Kafka) menangani 250 ribu pesan per detik bahkan di laptop (tautan video)
    • Performa yang lebih rendah dari itu di lingkungan 288 vCPU adalah pemborosan
    • Jika alasan memakai Postgres hanya karena “sudah ada”, saya bisa mengerti, tetapi tetap perlu validasi sebelum menambah infrastruktur baru
    • Kafka bisa mencapai batas bandwidth jaringan bahkan dengan hardware yang sedikit
    • Menjalankannya di AWS dengan satu instance 24xlarge itu tidak efisien, dan dengan biaya sebesar itu Anda bisa mengoperasikan cluster Kafka besar

  • Ada dua ekstrem: “orang yang terobsesi dengan teknologi baru” dan “orang yang hanya ngotot pada yang sudah dipelajari”
    Engineer yang realistis membuat pilihan praktis di tengah-tengah keduanya

    • Saya termasuk golongan ketiga: tipe yang berpikir “semua yang ada sekarang kurang bagus, dan yang baru pun pada akhirnya juga akan begitu”
    • Pada akhirnya yang penting adalah memandang masalah secara rasional dan mencari solusi yang optimal
    • Misalnya, upaya mengganti Elasticsearch dengan Postgres mungkin saja dilakukan, tetapi kematangan fitur pencarian ES jauh lebih unggul

  • Fitur inti Kafka adalah kontrol offset per consumer
    Ini adalah fitur wajib di lingkungan di mana beberapa tim membaca topik yang sama
    Kemampuan menggeser offset maju-mundur telah beberapa kali menjadi penyelamat
    Saya penasaran apakah queue Postgres mendukung fitur seperti ini

    • Ada juga pendapat bahwa setiap consumer bisa saja mengelola offset-nya sendiri
    • Namun dalam kebanyakan kasus, jika throughput tinggi tidak diperlukan, pengelolaan offset Kafka yang rumit pun tidak dibutuhkan
    • Pada akhirnya ini adalah masalah keseimbangan antara kecepatan kebutuhan bisnis dan kompleksitas operasional

  • Kerangka berpikir “kubu pemburu buzzword vs kubu akal sehat” itu sendiri keliru
    Mencoba mengimplementasikan ulang Kafka dengan Postgres bukanlah akal sehat
    Jika benar-benar membutuhkan fitur setingkat Kafka, ya pakai saja Kafka

    • Pada kenyataannya, yang dibuat bukan keseluruhan Kafka, melainkan hanya dua query pub-sub sederhana