Kalau Anda pernah membangun aplikasi Flutter yang menyimpan lebih dari sekadar preferensi pengguna — misalnya cache data, riwayat aktivitas, atau koleksi item yang disimpan offline — Anda pasti pernah merasakan keterbatasan SharedPreferences.

Saya menggunakannya di hampir semua proyek awal saya. Mudah disetup, API-nya simpel, dan untuk kasus sederhana memang sudah cukup. Tapi ada titik di mana "cukup" tidak lagi cukup.

Artikel ini bukan tentang mana yang lebih baik secara absolut. Ini tentang memahami kapan masing-masing alat tepat digunakan — dan bagaimana migrasi yang bersih ketika sudah tiba saatnya berpindah.

---

Apa yang SharedPreferences Lakukan dengan Baik

SharedPreferences (atau di Flutter, package shared_preferences) menyimpan data sebagai key-value pairs dalam file XML di storage perangkat. Setiap operasi read/write langsung ke file tersebut.

Ini sangat cocok untuk:

• Pengaturan pengguna: tema gelap/terang, bahasa, notifikasi on/off
• Status login: menyimpan token atau flag "sudah login"
• Data boolean dan string sederhana yang jarang berubah
• Onboarding state: apakah pengguna sudah pernah buka aplikasi sebelumnya

Setupnya memang tidak lebih dari tiga baris:

final prefs = await SharedPreferences.getInstance();
await prefs.setBool('darkMode', true);

final isDark = prefs.getBool('darkMode') ?? false;

Tidak ada yang bisa menyaingi kesederhanaannya untuk kasus-kasus di atas.

---

Di Mana SharedPreferences Mulai Bermasalah

Masalah pertama yang saya rasakan: performa saat data mulai besar.

SharedPreferences memuat seluruh file XML ke memori saat getInstance() dipanggil. Kalau Anda menyimpan ratusan entri — misalnya cache hasil pencarian atau daftar item favorit yang bisa ratusan panjangnya — startup time aplikasi akan terasa lebih lambat, dan setiap operasi write lebih mahal dari yang seharusnya.

Masalah kedua: tidak ada type safety. Semua data disimpan sebagai primitive (String, int, bool, double, List). Untuk menyimpan object yang lebih kompleks, Anda harus serialisasi manual ke JSON string, lalu deserialisasi saat membacanya. Ini tidak hanya verbose, tapi juga rawan bug — terutama saat struktur data berubah.

Masalah ketiga: tidak ada query. Anda tidak bisa bertanya "ambil semua item favorit yang ditambahkan bulan ini". Anda hanya bisa membaca berdasarkan key yang sudah Anda tahu sebelumnya.

---

Mengapa Hive Menjadi Jawaban yang Tepat

Hive adalah database key-value yang ditulis murni dalam Dart — tidak ada dependency native, tidak ada JNI overhead. Datanya disimpan dalam format binary yang jauh lebih compact dari XML, dan akses read-nya sangat cepat karena menggunakan lazy loading.

Yang membuat Hive menonjol adalah dukungannya untuk menyimpan object Dart secara langsung via TypeAdapter:

// 1. Definisikan model
@HiveType(typeId: 0)

class Artikel extends HiveObject {

@HiveField(0)

late String judul;


@HiveField(1)

late String konten;


@HiveField(2)

late DateTime tanggalDisimpan;

}


// 2. Generate adapter (jalankan: flutter packages pub run build_runner build)


// 3. Registrasi dan gunakan

await Hive.initFlutter();

Hive.registerAdapter(ArtikelAdapter());

final box = await Hive.openBox<Artikel>('artikelFavorit');


// Simpan

final artikel = Artikel()

..judul = 'Judul Artikel'

..konten = 'Isi artikel...'

..tanggalDisimpan = DateTime.now();

await box.add(artikel);


// Baca semua

final semuaArtikel = box.values.toList();


// Hapus

await artikel.delete();

Tidak ada serialisasi manual, tidak ada parsing JSON, tidak ada casting yang rawan gagal. Object masuk, object keluar.

---

Benchmark Performa: Angka Nyata

Saya melakukan pengukuran sederhana di proyek yang sedang dikerjakan — menyimpan dan membaca 500 objek sederhana (5 field string dan satu field DateTime).

SharedPreferences (via JSON serialization):

• Write 500 objek: ~1.840 ms
• Read dan deserialize 500 objek: ~620 ms
• Ukuran file: ~185 KB (XML overhead signifikan)

Hive (via TypeAdapter):

• Write 500 objek: ~280 ms
• Read 500 objek: ~45 ms
• Ukuran file: ~62 KB (binary compact)

Perbedaannya ekstrem untuk kasus data yang lebih dari sekadar key-value sederhana. Read yang 14x lebih cepat dan storage yang 3x lebih kecil bukan angka yang bisa diabaikan begitu saja.

---

Kapan Harus Tetap di SharedPreferences

Setelah semua angka di atas, saya ingin jujur: SharedPreferences masih saya gunakan di setiap proyek. Berdampingan dengan Hive.

Untuk pengaturan aplikasi — preferensi tema, status notifikasi, data onboarding — SharedPreferences tetap pilihan pertama. Setup-nya sederhana, tidak ada overhead code generation, dan tidak ada TypeAdapter yang perlu ditulis.

Rule of thumb yang saya gunakan: kalau yang disimpan adalah konfigurasi aplikasi (data yang ditulis jarang, dibaca di startup), pakai SharedPreferences. Kalau yang disimpan adalah konten yang dikumpulkan dari aktivitas pengguna (favorit, riwayat, cache), pakai Hive.

---

Migrasi dari SharedPreferences ke Hive: Pendekatan yang Bersih

Kalau Anda sudah punya aplikasi yang menggunakan SharedPreferences dan ingin migrasi sebagian datanya ke Hive, pendekatan yang saya rekomendasikan adalah migrasi bertahap, bukan big bang replacement.

class DataMigrationService {
static Future<void> migrateIfNeeded() async {

final prefs = await SharedPreferences.getInstance();

final sudahMigrasi = prefs.getBool('_hive_migration_v1') ?? false;


if (sudahMigrasi) return;


// Baca data lama dari SharedPreferences

final favoritJson = prefs.getStringList('favorit_lama') ?? [];


// Parse dan simpan ke Hive

final box = await Hive.openBox<ArtikelFavorit>('favorit');

for (final json in favoritJson) {

final data = jsonDecode(json);

await box.add(ArtikelFavorit.fromMap(data));

}


// Tandai migrasi selesai

await prefs.setBool('_hive_migration_v1', true);


// Opsional: hapus data lama

await prefs.remove('favorit_lama');

}

}

Panggil DataMigrationService.migrateIfNeeded() di main() sebelum runApp(). Pengguna tidak akan merasakan apapun — migrasi terjadi transparan di background.

---

Hive vs Alternatif Lain: Ikhtisar Singkat

Dua alternatif yang sering dibandingkan dengan Hive:

SQLite via Drift (sebelumnya Moor): Pilihan terbaik untuk data relasional kompleks. Kalau Anda butuh JOIN, foreign key, atau query SQL yang sophisticated, Drift adalah jawabannya. Tapi overhead setupnya jauh lebih besar dari Hive, dan untuk data non-relasional Hive hampir selalu lebih cepat.

Isar: Database yang dibuat oleh developer yang sama dengan Hive, dirancang sebagai penggantinya. Lebih cepat, support query yang lebih kaya, dan type-safe secara lebih menyeluruh. Saya mulai menggunakannya di proyek baru. Satu-satunya keterbatasan: file binarynya lebih besar dan setup-nya lebih kompleks dari Hive.

---

Kesimpulan

Memilih solusi penyimpanan lokal adalah keputusan arsitektur yang dampaknya terasa sepanjang umur proyek. SharedPreferences dan Hive bukan pesaing — mereka adalah alat yang berbeda untuk masalah yang berbeda.

Pahami kebutuhannya dulu. Baru pilih alatnya.