Soft Delete vs Hard Delete: Strategi Penghapusan Data dalam Aplikasi

Soft delete vs hard delete adalah keputusan yang terlihat sepele sampai ada data penting yang hilang. Suatu hari seorang admin salah menekan tombol hapus pada data pelanggan. Riwayat transaksi ikut rusak, laporan penjualan berubah, dan tim tidak punya cara untuk mengembalikannya. Di sisi lain, ada aplikasi yang menyimpan data pengguna selamanya padahal pengguna sudah meminta akunnya dihapus.

Dua kasus itu menunjukkan bahwa tidak ada pilihan yang selalu benar. Soft delete menyimpan data dengan tanda terhapus, sedangkan hard delete menghapusnya dari database secara permanen. Keduanya punya kelebihan dan risiko yang berbeda. Karena itu, Anda perlu memilih berdasarkan kebutuhan aplikasi, bukan kebiasaan.

Artikel ini membahas cara kerja keduanya, kelebihan dan kekurangannya, lima pertimbangan untuk memilih, hingga strategi gabungan yang banyak dipakai. Selain itu, Anda akan menemukan contoh SQL dan kode Node.js yang bisa langsung dicoba.

Daftar Isi

• Apa itu soft delete dan hard delete
• Cara kerja soft delete di database
• Kelebihan dan kekurangan soft delete
• Kelebihan dan kekurangan hard delete
• 5 pertimbangan memilih soft delete atau hard delete
• Strategi gabungan
• Praktik terbaik soft delete
• Kesalahan umum
• Kesimpulan

Apa Itu Soft Delete dan Hard Delete?

Hard delete berarti baris data dihapus dari tabel dengan perintah DELETE. Setelah perintah berjalan, data tidak lagi ada di tabel. Satu-satunya jalan untuk mengembalikannya adalah backup atau fitur pemulihan milik database.

Soft delete bekerja berbeda. Aplikasi tidak menghapus baris, tetapi menandainya. Penandanya biasanya kolom deleted_at bertipe timestamp, atau kolom boolean seperti is_deleted. Selama kolom itu terisi, aplikasi menganggap data tersebut sudah terhapus, meski barisnya masih tersimpan.

Sederhananya, hard delete seperti membuang kertas ke mesin penghancur. Sebaliknya, soft delete seperti memindahkan kertas ke kotak arsip.

Cara Kerja Soft Delete di Database

Berikut contoh sederhana memakai PostgreSQL. Contoh ini menunjukkan perbedaan hard delete dan soft delete pada tabel yang sama.

-- Tabel dengan kolom penanda penghapusan
CREATE TABLE users (
  id          SERIAL PRIMARY KEY,
  name        TEXT NOT NULL,
  email       TEXT NOT NULL,
  deleted_at  TIMESTAMPTZ,
  deleted_by  INTEGER
);

-- Hard delete: baris hilang permanen
DELETE FROM users WHERE id = 42;

-- Soft delete: baris tetap ada, hanya ditandai
UPDATE users
SET deleted_at = NOW(), deleted_by = 1
WHERE id = 42 AND deleted_at IS NULL;

-- Ambil hanya data yang masih aktif
SELECT id, name, email FROM users WHERE deleted_at IS NULL;

-- Pulihkan data yang terhapus
UPDATE users
SET deleted_at = NULL, deleted_by = NULL
WHERE id = 42;

Perhatikan kondisi deleted_at IS NULL pada query pembacaan. Kondisi inilah yang membuat data yang ditandai terhapus tidak muncul di aplikasi. Jika Anda lupa menambahkannya, data yang seharusnya tersembunyi akan ikut tampil.

Kolom deleted_by bersifat opsional. Namun, kolom ini berguna untuk audit, karena Anda bisa tahu siapa yang menghapus sebuah data.

Kelebihan dan Kekurangan Soft Delete

Soft delete populer karena memberi rasa aman. Meski begitu, pendekatan ini membawa biaya tersendiri.

Kelebihan soft delete:

• Data bisa dipulihkan. Kesalahan manusia mudah diperbaiki dengan satu perintah.
• Riwayat tetap terjaga. Transaksi lama masih bisa merujuk ke data yang sudah dihapus.
• Mendukung audit. Anda bisa melacak kapan dan oleh siapa data dihapus.
• Lebih aman terhadap relasi. Foreign key tidak putus karena baris induk masih ada.

Kekurangan soft delete:

• Setiap query harus menyaring data. Satu query yang lupa filter bisa menampilkan data yang seharusnya tersembunyi.
• Constraint unik bisa bentrok. Pengguna baru dengan email yang sama dengan akun yang sudah ditandai terhapus akan ditolak, kecuali Anda memakai indeks khusus.
• Data menumpuk. Tabel membesar dan query bisa melambat seiring waktu.
• Risiko privasi. Data pribadi yang seharusnya hilang masih tersimpan.
• Logika lebih rumit. Penghapusan berantai pada tabel berelasi harus Anda atur sendiri.

Kelebihan dan Kekurangan Hard Delete

Hard delete lebih sederhana dan bersih. Namun, kesederhanaan itu menuntut kehati-hatian.

Dari sisi kelebihan, hard delete mengosongkan ruang penyimpanan dan menjaga tabel tetap ramping. Query tidak perlu filter tambahan, sehingga kodenya lebih ringkas. Selain itu, hard delete memenuhi permintaan penghapusan data yang benar-benar permanen.

Dari sisi kekurangan, data tidak bisa dikembalikan tanpa backup. Foreign key bisa menolak penghapusan, atau justru menghapus data terkait secara berantai jika Anda memakai ON DELETE CASCADE. Akibatnya, satu perintah kecil bisa menghapus banyak baris sekaligus.

Aspek	Soft Delete	Hard Delete
Data setelah dihapus	Masih tersimpan, hanya ditandai	Hilang dari tabel
Pemulihan	Mudah	Perlu backup
Kompleksitas query	Lebih tinggi, perlu filter	Lebih sederhana
Ukuran tabel	Terus bertambah	Lebih terkendali
Audit dan riwayat	Terjaga	Perlu mekanisme terpisah
Kesesuaian dengan hak hapus data	Perlu tambahan penghapusan permanen	Langsung sesuai

5 Pertimbangan Memilih antara Soft Delete dan Hard Delete

Gunakan lima pertanyaan berikut sebelum menentukan strategi untuk setiap tabel. Jawabannya bisa berbeda antartabel dalam satu aplikasi.

1. Apakah Data Perlu Dipulihkan?

Jika pengguna atau admin sering salah hapus, soft delete memberi jaring pengaman. Contohnya data produk, artikel, atau pesanan. Sebaliknya, untuk data sementara seperti token sesi atau cache, hard delete lebih masuk akal karena tidak ada alasan memulihkannya.

2. Apakah Ada Riwayat atau Relasi yang Harus Dijaga?

Bayangkan toko online yang menghapus sebuah produk. Pesanan lama masih merujuk ke produk itu. Jika produk dihapus permanen, riwayat pesanan kehilangan konteks atau malah error. Dalam kasus seperti ini, soft delete menjaga laporan dan faktur lama tetap utuh.

3. Bagaimana dengan Privasi dan Kewajiban Hukum?

Data pribadi menuntut pertimbangan ekstra. Regulasi perlindungan data, termasuk UU Pelindungan Data Pribadi di Indonesia, memberi subjek data hak tertentu atas data mereka, termasuk permintaan penghapusan. Karena itu, menyimpan data pribadi tanpa batas waktu setelah pengguna meminta penghapusan bisa menimbulkan masalah. Catatan ini bukan nasihat hukum, jadi konsultasikan kebutuhan spesifik Anda dengan ahli yang berwenang.

Salah satu pendekatan yang umum adalah soft delete untuk masa tenggang, lalu hard delete atau anonimisasi setelahnya.

4. Bagaimana Dampaknya pada Performa dan Ukuran Data?

Soft delete membuat tabel terus bertambah. Pada tabel besar, query yang selalu menyaring deleted_at IS NULL perlu indeks yang tepat. Di PostgreSQL, Anda dapat memakai partial index, yaitu indeks yang hanya mencakup baris yang memenuhi kondisi tertentu. Penjelasannya tersedia di tutorial partial index PostgreSQL dari Neon.

Dengan indeks seperti itu, data aktif tetap cepat dicari walaupun jumlah data terhapus terus bertambah.

5. Seberapa Besar Risiko Salah Hapus?

Ukur dampak kesalahan. Menghapus satu komentar jarang menimbulkan kerugian besar, sedangkan menghapus data keuangan bisa fatal. Semakin besar dampak salah hapus, semakin kuat alasan memakai soft delete atau minimal menyediakan backup yang teruji.

Strategi Gabungan: Soft Delete Dulu, Hard Delete Terjadwal

Dalam praktik, banyak tim tidak memilih salah satunya. Mereka memakai soft delete untuk memberi masa tenggang, lalu menjalankan hard delete terjadwal untuk membersihkan data yang sudah lama. Pola ini menyeimbangkan keamanan data dan kebersihan database.

Contohnya, pengguna menghapus akun. Aplikasi menandai akun itu sebagai terhapus dan menyembunyikannya. Selama 30 hari, pengguna masih bisa membatalkan. Setelah itu, sebuah job terjadwal menghapus datanya secara permanen.

-- Email harus unik hanya untuk pengguna yang masih aktif
CREATE UNIQUE INDEX users_email_active_unique
ON users (email)
WHERE deleted_at IS NULL;

-- Hapus permanen data yang sudah melewati masa simpan 30 hari
DELETE FROM users
WHERE deleted_at IS NOT NULL
  AND deleted_at < NOW() - INTERVAL '30 days';

Indeks unik parsial pada contoh di atas menyelesaikan masalah email yang bentrok. Email dari akun yang sudah ditandai terhapus tidak lagi menghalangi pendaftaran baru.

Jangan menulis angka masa simpan secara mati di dalam kode. Simpan sebagai konfigurasi, misalnya lewat file .env, sehingga Anda bisa mengubahnya tanpa memodifikasi kode. Cara memakainya ada di Environment Variable: Cara Pakai .env di Node.js.

Untuk data pribadi, pertimbangkan juga anonimisasi. Alih-alih menghapus seluruh baris, Anda mengganti nama dan email dengan nilai netral. Cara ini menjaga statistik dan relasi, tetapi identitas orangnya tidak lagi bisa dikenali.

Praktik Terbaik Menerapkan Soft Delete

Agar soft delete tidak berubah menjadi sumber bug, terapkan kebiasaan berikut:

• Pusatkan logika penyaringan. Gunakan fungsi repository, view database, atau global scope di ORM, sehingga filter tidak ditulis ulang di setiap query.
• Catat siapa dan kapan. Simpan deleted_at dan deleted_by untuk kebutuhan audit.
• Gunakan indeks unik parsial. Cegah bentrok pada kolom seperti email atau username.
• Atur penghapusan berantai secara eksplisit. Putuskan tabel anak mana yang ikut ditandai terhapus.
• Batasi siapa yang boleh memulihkan. Pemulihan data harus memiliki otorisasi yang jelas.
• Jadwalkan pembersihan. Tentukan kapan data yang ditandai terhapus dihapus permanen.

Berikut contoh sederhana di Node.js dengan library pg. Fungsi-fungsi ini memusatkan logika soft delete di satu tempat.

// Menandai pengguna sebagai terhapus
async function softDeleteUser(db, id, adminId) {
  const { rowCount } = await db.query(
    `UPDATE users
     SET deleted_at = NOW(), deleted_by = $1
     WHERE id = $2 AND deleted_at IS NULL`,
    [adminId, id]
  );
  return rowCount === 1;
}

// Hanya mengambil pengguna yang masih aktif
async function findActiveUsers(db) {
  const { rows } = await db.query(
    `SELECT id, name, email
     FROM users
     WHERE deleted_at IS NULL
     ORDER BY id`
  );
  return rows;
}

// Endpoint Express untuk soft delete
app.delete('/api/users/:id', requireAdmin, async (req, res) => {
  const ok = await softDeleteUser(db, req.params.id, req.user.id);

  if (!ok) {
    return res.status(404).json({ error: 'Pengguna tidak ditemukan' });
  }

  res.status(204).end();
});

Perhatikan bahwa query memakai parameter ($1, $2) agar aman dari SQL injection. Nama fungsi yang jelas juga membuat kode lebih mudah dibaca beberapa bulan kemudian, seperti dibahas di Kode Sulit Dipahami Setelah Beberapa Bulan? Kenali Pentingnya Code Readability.

Endpoint yang menghapus data juga layak mendapat perlindungan ekstra. Batasi frekuensinya agar tidak disalahgunakan, seperti pada Rate Limiting API: 4 Algoritma dan Cara Pakainya di Express. Jika Anda merancang API yang menyediakan operasi hapus dan pulihkan, pertimbangan desainnya ada di REST API vs GraphQL: Mana yang Lebih Cocok untuk Proyek Web Modern?.

Kesalahan Umum saat Memakai Soft Delete

• Lupa menyaring data terhapus. Akibatnya, data yang seharusnya tersembunyi muncul di halaman atau laporan.
• Mengabaikan constraint unik. Pendaftaran ulang dengan email lama gagal tanpa alasan jelas.
• Menyimpan data pribadi selamanya. Tidak ada jadwal penghapusan permanen sama sekali.
• Tidak menguji pemulihan. Fitur restore baru dicoba saat keadaan darurat.
• Memakai boolean tanpa waktu. Anda kehilangan informasi kapan data dihapus.
• Menyamakan soft delete dengan backup. Soft delete tidak melindungi dari kerusakan database atau penghapusan permanen.

Kesimpulan: Pilih Soft Delete atau Hard Delete Sesuai Jenis Data

Soft delete dan hard delete bukan pilihan benar atau salah. Soft delete cocok untuk data yang perlu dipulihkan, diaudit, atau dirujuk riwayatnya. Hard delete cocok untuk data sementara dan data yang harus benar-benar hilang. Banyak aplikasi akhirnya memakai keduanya dalam satu alur.

Mulailah dengan mengelompokkan tabel Anda. Tentukan mana yang butuh pemulihan, mana yang menyimpan data pribadi, dan mana yang hanya data sementara. Setelah itu, terapkan strategi yang sesuai, lengkapi dengan indeks yang tepat, dan jadwalkan penghapusan permanen. Dengan begitu, aplikasi Anda aman dari salah hapus tanpa menimbun data yang tidak perlu.

Artikel Lainnya di NgodingDaily

Lanjutkan belajar dengan topik lain yang saling melengkapi:

• Rate Limiting API: 4 Algoritma dan Cara Pakainya di Express
• REST API vs GraphQL: Mana yang Lebih Cocok untuk Proyek Web Modern?
• Environment Variable: Cara Pakai .env di Node.js
• Kode Sulit Dipahami Setelah Beberapa Bulan? Kenali Pentingnya Code Readability
• Git Bisect: Menemukan Commit Penyebab Bug Tanpa Memeriksa Kode Satu per Satu