Memilih Plugin Keamanan WordPress yang Tidak Bikin Database Membengkak

Keluhan 'wp-admin lambat' sering berujung di tempat yang tidak disangka, yaitu database yang ukurannya terus naik padahal jumlah post hampir tidak bertambah. Kalau dicek, tabel paling gemuk sering bukan wp_posts atau wp_postmeta. Yang paling besar justru tabel milik plugin keamanan, berisi catatan setiap request, setiap percobaan login, dan hasil scan file. Plugin keamanan tidak salah apa-apa di sini. Yang perlu kita pilih dengan sadar adalah cara dia menyimpan data, dan itu sebaiknya diputuskan sebelum plugin dipasang, bukan setelah database sudah membengkak.

Kenapa plugin keamanan bisa jadi penghuni terbesar database

Plugin WordPress berjalan di dalam PHP. Tempat penyimpanan permanen yang paling gampang ia akses adalah database yang sama dengan isi situs. Jadi waktu plugin ingin mencatat sesuatu, misalnya IP yang diblokir, username yang dicoba, atau request yang mencurigakan, cara termudahnya adalah menulis satu baris baru ke tabel. Untuk situs dengan sedikit pengunjung, ini tidak terasa. Masalah muncul karena trafik ke WordPress tidak hanya datang dari manusia. Serangan brute force dan credential stuffing (mencoba pasangan username dan password hasil bocoran dari situs lain) ke WordPress berjalan otomatis lewat botnet. Sebagian bahkan sengaja dibuat 'slow-and-low', yaitu pelan dan tersebar dari banyak IP supaya tidak memicu blokir. Kalau plugin mencatat setiap hit, setiap request bot berarti satu INSERT ke database. Situs yang sedang ramai diserang akhirnya sibuk menulis log, bukan melayani pengunjung. Ada beberapa efek lanjutan yang sering tidak disadari:

Query di halaman dashboard plugin (grafik serangan, daftar IP, dan sejenisnya) makin berat karena harus membaca tabel yang besar.
Backup dan migrasi jadi lebih lama, karena isi dump database didominasi log yang sebenarnya tidak penting untuk dipulihkan.
Di InnoDB, menghapus baris tidak otomatis mengecilkan file tabel di disk. Kuota disk bisa tetap terpakai walaupun log sudah dibersihkan.
Sebagian plugin menyimpan hasil scan atau konfigurasi besar di wp_options. Kalau opsi itu ditandai autoload (dimuat otomatis di setiap request), beban itu ikut terbawa ke setiap halaman, termasuk halaman depan.

Buat tim support, polanya cukup khas. Situs lambat di admin, CPU tidak terlalu tinggi, tapi proses MySQL sibuk dan ukuran database tidak sebanding dengan kontennya.

Tiga pendekatan yang biasanya jadi pilihan

Secara garis besar, ada tiga cara menyusun proteksi WordPress. Ketiganya bisa masuk akal, tergantung kondisi situs. Pertama, plugin all-in-one yang punya firewall di level aplikasi, live traffic, pembatasan login, dan scanner, dengan semua catatannya disimpan di database. Kelebihannya, semuanya ada di satu tempat dan mudah dibaca dari wp-admin. Kekurangannya, beban penyimpanannya paling besar kalau tidak dikonfigurasi. Kedua, plugin ringan yang fokus pada satu atau dua hal, misalnya pembatasan login dan 2FA (two-factor authentication), dengan log minimal atau cukup ringkasan. Bebannya kecil, tapi cakupannya juga terbatas. Kamu perlu tahu apa saja yang tidak dilindungi. Ketiga, proteksi utama ditaruh di level server atau edge (CDN/proxy di depan server), misalnya WAF seperti ModSecurity, tool keamanan dari panel hosting, Fail2ban, atau aturan di CDN. Plugin hanya dipakai untuk hal yang memang tidak bisa dilakukan server, seperti 2FA untuk akun admin. Log disimpan di file log server atau di dashboard layanan edge, bukan di database WordPress.

Pendekatan	Beban ke database	Skill yang dibutuhkan	Biasanya cocok untuk
Plugin all-in-one, log di DB	Tinggi jika log dan live traffic aktif tanpa batas retensi	Rendah, semua dari wp-admin	Situs kecil tanpa akses ke proteksi server, dengan pemilik yang rajin mengatur retensi
Plugin ringan dan fokus	Rendah	Rendah sampai sedang	Situs yang servernya sudah punya proteksi dasar, atau yang hanya butuh login aman
Proteksi di server/edge + plugin minimal	Paling rendah	Sedang sampai tinggi, atau bergantung pada fitur hosting	VPS, situs ramai, atau hosting yang sudah menyediakan WAF

Tabel ini bukan peringkat. Pendekatan ketiga paling hemat database, tapi tidak ada gunanya kalau kamu tidak punya akses atau kemampuan untuk mengaturnya.

Pertanyaan yang perlu dijawab sebelum memasang

Daripada membandingkan jumlah fitur, lebih berguna menjawab beberapa pertanyaan berikut. Jawabannya biasanya ada di dokumentasi plugin, halaman pengaturan, atau bisa dilihat langsung dari tabel yang dibuat setelah plugin diaktifkan di situs staging. Di mana log disimpan? Ada plugin yang menulis ke tabel sendiri, ada yang ke file di direktori wp-content, dan ada yang mengirim data ke dashboard layanan eksternal. Penyimpanan di file atau eksternal tidak membebani database, tapi punya konsekuensi lain. File log di dalam web root harus dilindungi agar tidak bisa diakses publik, dan pengiriman data ke pihak luar perlu kamu setujui dengan sadar. Apa saja yang dicatat? Mencatat setiap request (live traffic) jauh lebih berat daripada hanya mencatat request yang diblokir atau login yang gagal. Cek apakah fitur pencatatan lengkap bisa dimatikan tanpa mematikan proteksinya. Biasanya kamu tidak butuh rekaman semua pengunjung, cukup kejadian penting saja. Berapa lama data disimpan, dan apakah pembersihannya benar-benar jalan? Pengaturan retensi seperti 'hapus log lebih dari sekian hari' hanya berguna kalau job pembersihannya dieksekusi. Di banyak plugin, job itu bergantung pada WP-Cron, yang hanya terpicu saat ada kunjungan. Kalau WP-Cron dimatikan tanpa system cron pengganti, log bisa menumpuk terus walaupun pengaturannya terlihat benar. Hasil scan disimpan di mana? Scanner file biasanya menyimpan daftar file, hash, dan temuan. Kalau disimpan sebagai opsi autoload di wp_options, ukurannya ikut dimuat di setiap request. Apa yang terjadi saat plugin dihapus? Tidak semua plugin membersihkan tabelnya saat di-uninstall. Kalau sebelumnya sudah gonta-ganti plugin keamanan, sering ada tabel sisa yang masih memakan ruang. Apakah fungsi yang sama sudah ditangani di level server? Ini pertanyaan yang paling sering terlewat. Kalau server sudah punya WAF dan pembatasan brute force, firewall aplikasi di plugin sering hanya mengulang pekerjaan yang sama, ditambah biaya menulis log ke database. Cek di panel hosting atau tanyakan ke support apa saja yang sudah aktif.

Cara mengecek kondisi database yang sekarang

Sebelum memutuskan, lihat dulu kondisi sebenarnya. Query berikut hanya membaca metadata, aman dijalankan lewat phpMyAdmin atau klien MySQL. Ganti nama_database dengan nama database situsmu.

SQL

SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 1) AS size_mb,
       table_rows
FROM information_schema.tables
WHERE table_schema = 'nama_database'
ORDER BY (data_length + index_length) DESC
LIMIT 15;

Perhatikan nama tabel di urutan teratas. Tabel milik plugin biasanya punya awalan yang mirip nama pluginnya. Kalau tabel log jauh lebih besar dari tabel konten, itu tanda retensinya perlu diatur. Kolom table_rows di InnoDB hanya estimasi, jadi gunakan untuk melihat gambaran besar saja, bukan angka pasti. Untuk membersihkan, lakukan dari pengaturan plugin dulu, misalnya mematikan live traffic, menurunkan retensi, atau memakai tombol hapus log kalau tersedia. Peringatan: jangan langsung menjalankan DROP TABLE atau TRUNCATE pada tabel plugin yang masih aktif. Kedua perintah itu menghapus data secara permanen dan tidak bisa dibatalkan. Plugin juga bisa error kalau tabel yang ia butuhkan tiba-tiba hilang. Selalu buat backup database sebelum menghapus apa pun secara manual. Kalau setelah pembersihan ukuran file tabel di disk tidak turun, OPTIMIZE TABLE bisa membantu. Hasilnya tergantung konfigurasi MySQL. Perintah ini juga cukup berat untuk tabel besar, jadi sebaiknya dijalankan di jam sepi.

Memilih berdasarkan kondisi situsmu

Dari sisi workload, situs yang sering jadi sasaran bot login atau XML-RPC paling dirugikan oleh plugin yang mencatat setiap hit. Untuk situs seperti ini, menahan serangan sebelum sampai ke PHP biasanya lebih efektif. Perbandingan antara blokir di edge dan di plugin sudah dibahas di Memilih Blokir Bot Login di Level Cloudflare atau Plugin WordPress. Kalau belum yakin apakah bebannya datang dari login biasa atau dari XML-RPC, cara membacanya ada di Spotting XML-RPC Multicall Attacks in Web Server Access Logs. Dari sisi budget dan paket hosting, di shared hosting atau paket dengan batas resource ketat, setiap query tambahan ikut dihitung. Plugin ringan yang ditambah proteksi bawaan hosting biasanya lebih aman untuk resource dibanding plugin all-in-one dengan semua fitur aktif. Di VPS, kamu punya pilihan memasang proteksi di server sendiri. Konsekuensinya, kamu juga yang harus merawatnya. Dari sisi skill, kalau tidak ada yang mengurus server dan semua pengelolaan dilakukan dari wp-admin, plugin all-in-one masih masuk akal. Syaratnya, live traffic dimatikan, retensi dibuat pendek, dan ukuran tabelnya dicek sesekali. Kalau ada yang nyaman membaca log server dan mengatur WAF, geser proteksi ke server dan sisakan plugin untuk 2FA serta hal yang memang spesifik WordPress. Dari sisi risiko, jangan sampai demi hemat database kamu malah menghapus lapisan proteksi tanpa pengganti. Pastikan dulu fungsi yang mau dilepas dari plugin memang sudah ada di server atau edge, baru matikan di plugin. Memasang dua firewall aplikasi sekaligus juga tidak menambah keamanan secara berarti. Yang bertambah justru beban dan kemungkinan konflik. Prinsipnya, plugin keamanan sebaiknya mencatat kejadian penting, bukan semua trafik. Sebelum memasang, cek tiga hal: di mana log disimpan, berapa lama disimpan dan apakah pembersihannya jalan, serta apakah server sudah menangani hal yang sama. Setelah terpasang, jalankan query ukuran tabel di atas sesekali. Lima menit pengecekan itu biasanya cukup untuk tahu apakah plugin keamananmu masih membantu atau mulai jadi beban.