Materialized View: Menangani Query Berat vs Data Realtime di PostgreSQL

Saat pertama kali menemui masalah performa di PostgreSQL, view terlihat seperti solusi yang rapi — bungkus query rumitnya, beri nama, lalu perlakukan seperti tabel. Masalahnya, view biasa hanyalah query yang disimpan. Setiap kali Anda mengaksesnya, PostgreSQL menjalankan ulang seluruh query dari awal.

Materialized view (MV) berbeda: ia adalah hasil query yang disimpan secara fisik di database. Datanya tersimpan di disk dan disajikan langsung, tanpa mengeksekusi ulang logika di baliknya. Perbedaan itu terlihat kecil di atas kertas, tapi sangat besar dalam praktik.

Kapan Materialized View Masuk Akal

Materialized view cocok ketika:

• Beban kerjanya berat di sisi baca — banyak baca, sedikit tulis
• Query di baliknya mahal: banyak join, agregasi, window function
• Datanya tidak harus realtime — hasil yang sedikit tertinggal masih bisa diterima
• Latensi query rendah adalah kebutuhan mutlak

Contoh praktis yang konsisten menguntungkan: papan peringkat, dashboard analitik, laporan ringkasan, dan metrik pra-agregasi apa pun yang sering diakses pengguna.

Membuat Materialized View

Sintaksnya sederhana:

CREATE MATERIALIZED VIEW sales_summary_2026
AS SELECT * FROM sales WHERE transaction_year = '2026';

PostgreSQL menjalankan query itu sekali saat pembuatan dan menyimpan hasilnya. Setelah itu, pembacaan terhadap sales_summary_2026 mengenai snapshot yang tersimpan, bukan tabel aslinya.

Menyegarkan Datanya

Snapshot yang tersimpan tidak memperbarui dirinya sendiri. Andalah yang bertanggung jawab menyegarkannya — terjadwal, atau dipicu oleh logika aplikasi.

REFRESH MATERIALIZED VIEW CONCURRENTLY sales_summary_2026;

REFRESH MATERIALIZED VIEW versi standar mengambil lock eksklusif dan memblokir semua pembacaan selama proses berlangsung. Untuk beban kerja produksi yang tidak boleh berhenti, CONCURRENTLY adalah jawabannya: ia membangun versi baru di latar belakang lalu menukarnya tanpa memblokir pembacaan.

Ada satu syarat untuk CONCURRENTLY: materialized view tersebut harus punya unique index. Tanpa itu, PostgreSQL tidak bisa melakukan penggabungan diferensial dan akan menolak perintahnya.

Hal yang Perlu Diwaspadai

Data usang adalah harga yang dibayar. Sebuah MV mencerminkan kondisi data Anda pada penyegaran terakhir. Kalau pengguna butuh kesegaran dalam hitungan detik, MV adalah alat yang salah — pakai view biasa atau query langsung ke tabelnya.

Biaya penyegaran menumpuk. Satu penyegaran itu murah. Menyegarkan sepuluh materialized view berat secara bersamaan saat beban tinggi tidak. Jadwalkan penyegaran secara bergiliran dan pantau waktu query di sekitar jendela penyegaran.

Tidak ada penyegaran otomatis. PostgreSQL tidak punya mekanisme bawaan untuk menyegarkan MV saat data di bawahnya berubah. Anda harus merangkainya sendiri — cron job, tugas pg_cron, atau trigger dari sisi aplikasi setelah penulisan massal.

Kapan Sebaiknya Tidak Dipakai

Kalau data Anda berubah setiap beberapa detik dan pengguna berharap melihat perubahan itu seketika, materialized view akan menimbulkan lebih banyak masalah daripada yang diselesaikannya. Hal yang sama berlaku untuk query bertrafik rendah yang query dasarnya sudah selesai dalam hitungan milidetik — MV hanya menambah beban operasional tanpa manfaat nyata.

Ringkasnya

Materialized view adalah alat yang spesifik. Dipakai di tempat yang tepat — berat di sisi baca, sensitif terhadap latensi, toleran terhadap data yang sedikit tertinggal — ia bisa memangkas waktu query secara drastis dengan perubahan minimal di sisi aplikasi. Dipakai sembarangan, ia menambah bug data usang dan beban penyegaran. Pahami pertukarannya, kelola strategi penyegarannya, dan ia akan sangat membantu.