Performa Cache Postgres vs Redis: Benchmark Menunjukkan Kecepatan 2/3 namun Memicu Perdebatan Soal Validitas Tes

Tim Komunitas BigGo
Performa Cache Postgres vs Redis: Benchmark Menunjukkan Kecepatan 2/3 namun Memicu Perdebatan Soal Validitas Tes

Sebuah benchmark terbaru yang membandingkan PostgreSQL dan Redis untuk caching telah memicu diskusi signifikan di komunitas developer, dengan hasil yang menunjukkan PostgreSQL mencapai sekitar dua pertiga performa Redis sambil menimbulkan pertanyaan tentang metodologi pengujian itu sendiri.

Studi asli menguji kedua database menggunakan kluster Kubernetes dengan batasan sumber daya spesifik, menemukan Redis secara konsisten mengungguli PostgreSQL di berbagai beban kerja. Namun, benchmark tersebut mendapat kritik tajam dari komunitas teknis atas pendekatan dan kesimpulannya.

Hasil Perbandingan Performa

Jenis Benchmark Redis (req/detik) PostgreSQL (req/detik) Keunggulan Redis
Operasi GET 2,327 1,686 38% lebih cepat
Operasi SET 2,586 1,453 78% lebih cepat
Beban kerja campuran 2,377 1,497 59% lebih cepat

Konfigurasi Pengujian:

  • Hardware: batas 20 core CPU, alokasi memori tinggi
  • Versi database: PostgreSQL 15, Redis 7
  • Dataset: 10 juta entri
  • Durasi pengujian: 1 menit per benchmark
  • Tingkat cache hit: 80% untuk operasi GET, tingkat update 10% untuk operasi SET

Metodologi Pengujian yang Cacat Merusak Hasil

Validitas benchmark tersebut mendapat sorotan ketat dari para developer yang menunjukkan masalah mendasar dengan pengaturan tes. Para kritikus menyoroti bahwa PostgreSQL terbatas CPU pada utilisasi 100% di core yang dialokasikan, sementara Redis terhambat oleh server HTTP bukan oleh database itu sendiri. Ini berarti perbandingan tersebut tidak mengukur potensi performa sebenarnya dari kedua sistem dalam kondisi yang adil.

Pendekatan pengujian juga gagal memanfaatkan teknik optimasi performa yang tersedia untuk kedua sistem. Untuk Redis, fitur seperti pipelining dan klien auto-pipelining berpotensi memberikan peningkatan performa 10x lipat. PostgreSQL juga mendukung query pipelining melalui pustaka klien populer, yang tidak dieksplorasi dalam benchmark.

Utilisasi Sumber Daya Selama Pengujian

Performa Redis:

  • Penggunaan CPU: ~1.200-1.280 mCPU (jauh di bawah batas 2.000 mCPU)
  • Penggunaan memori: 3.800-4.300 MB
  • Bottleneck: Server HTTP, bukan Redis itu sendiri

Performa PostgreSQL:

  • Penggunaan CPU: 100% dari alokasi 2 core (batas 2.000 mCPU)
  • Penggunaan memori: 5.000-6.000 MB
  • Bottleneck: Utilisasi CPU database

Temuan Utama: PostgreSQL terbatas oleh CPU sementara Redis dibatasi oleh server HTTP, membuat perbandingan performa berpotensi menyesatkan.

Pertanyaan Performa Dunia Nyata

Di luar kekhawatiran metodologis, perdebatan komunitas mengungkap pertanyaan yang lebih dalam tentang kebutuhan performa praktis. Benchmark menunjukkan PostgreSQL menangani sekitar 1.500 permintaan per detik, yang setara dengan lebih dari setengah miliar permintaan per hari. Untuk sebagian besar aplikasi, tingkat performa ini jauh melampaui kebutuhan aktual.

Banyak developer berargumen bahwa pilihan antara Redis dan PostgreSQL untuk caching seharusnya tidak berdasarkan angka performa mentah semata. Keputusan sering kali bermuara pada kompleksitas operasional, infrastruktur yang ada, dan apakah perbedaan performa benar-benar penting untuk kasus penggunaan spesifik.

Trade-off Operasional dan Dependensi

Diskusi telah menyoroti pertimbangan operasional signifikan yang terlewat oleh benchmark performa murni. Redis menawarkan fitur bawaan seperti ekspirasi kunci otomatis (TTL) yang penting untuk caching efektif. Mengimplementasikan fungsionalitas serupa di PostgreSQL memerlukan komponen tambahan seperti cron job dan logika ekspirasi kustom.

Memiliki kemampuan untuk mengatur TTL pada kunci cache adalah fitur kritis dari sebuah cache, bukan sesuatu yang bisa ditambahkan belakangan.

Namun, pendukung pendekatan PostgreSQL berargumen bahwa menghindari dependensi tambahan bisa berharga, terutama untuk proyek yang lebih kecil. Mereka menunjukkan bahwa sebagian besar aplikasi sudah memerlukan database, jadi menggunakan PostgreSQL untuk caching menghilangkan kebutuhan untuk mengelola layanan lain. Pertimbangan biaya juga mendukung pendekatan ini, karena instance PostgreSQL sering kurang dimanfaatkan dan dapat menangani beban kerja caching tambahan tanpa biaya ekstra.

Solusi Alternatif dan Arah Masa Depan

Perdebatan juga telah membawa perhatian pada solusi hibrid seperti Redka, yang menyediakan kompatibilitas API Redis yang didukung oleh SQLite atau PostgreSQL. Pendekatan ini mencoba menggabungkan antarmuka Redis yang familiar dengan kesederhanaan operasional database SQL.

Beberapa developer telah menyarankan bahwa PostgreSQL bisa mendapat manfaat dari fitur caching native, seperti kemampuan untuk menandai kolom timestamp sebagai kolom ekspirasi yang akan ditangani secara otomatis oleh proses vacuum database. Fitur seperti itu akan membuat PostgreSQL lebih kompetitif untuk kasus penggunaan caching tanpa memerlukan alat eksternal.

Kontroversi benchmark pada akhirnya mencerminkan ketegangan yang lebih luas dalam arsitektur perangkat lunak antara optimasi performa dan kesederhanaan operasional. Meskipun Redis jelas menawarkan performa mentah yang superior untuk beban kerja caching, keputusan dunia nyata melibatkan pertimbangan keuntungan tersebut terhadap faktor-faktor seperti kompleksitas infrastruktur, biaya, dan kebutuhan performa aktual. Untuk banyak aplikasi, performa yang cukup baik dari PostgreSQL mungkin lebih berharga daripada performa puncak Redis, terutama ketika mempertimbangkan total biaya kepemilikan dan overhead operasional.

Referensi: Redis is fast - I'll cache in Postgres