Sign in Subscribe
DeveloperTips

UUID vs ULID vs CUID: Pilih yang Mana Buat ID Unik?

UUID vs ULID vs CUID: Pilih yang Mana Buat ID Unik?

Kalau bikin aplikasi, pasti butuh yang namanya ID unik. Entah buat primary key di database, identifier di API, atau sekadar jadi kode di URL.
Nah, biasanya orang-orang pakai UUID v4, tapi sekarang mulai rame juga yang pake ULID atau CUID.

Di tulisan ini kita bakal bahas santai aja:

  • Apa sih bedanya UUID, ULID, dan CUID
  • Plus minusnya
  • Benchmark kecil-kecilan yang udah dicoba
  • Kapan enaknya pakai salah satu

UUID v4

UUID v4 itu standar banget. Isinya random 128-bit, biasanya keliatan kayak gini: 550e8400-e29b-41d4-a716-446655440000

Kelebihan

  • Sudah jadi standar internasional → hampir semua database & library support.
  • Unik banget → tabrakan hampir mustahil.
  • Lebih privat, karena nggak ada info waktu atau mesin.

Kekurangan

  • Karena isinya random, nggak berurutan → bikin index di DB gampang acak-acakan.
  • Agak panjang → 36 karakter kalau disimpan sebagai string.

ULID

ULID itu singkatan dari Universally Unique Lexicographically Sortable Identifier (panjang banget ya 😅).
Bedanya sama UUID, ULID ini berurutan berdasarkan waktu. Contoh: 01H9Z5B1X8P7YQ23V8J6D6R7QN

Kelebihan

  • Urut berdasarkan waktu → gampang sorting.
  • Insert di database lebih rapi & cepat.
  • Asik buat pagination (WHERE id > ... ORDER BY id).
  • Bentuknya URL-friendly.

Kekurangan

  • Masih lebih baru dibanding UUID, jadi belum semua sistem dukung langsung.
  • Ada info timestamp → bisa keliatan kapan ID dibuat.

CUID

CUID dibuat biar lebih manusiawi dan gampang dipakai. Dia juga urut kayak ULID.
Contoh: cklb9h8r70001k5s6z2ln5w5r

Kelebihan

  • Monotonik/urut → DB lebih happy.
  • Bentuknya lebih pendek dari UUID.
  • Dirancang biar tabrakan hampir mustahil.

Kekurangan

  • Belum sepopuler UUID.
  • Ada sedikit info tentang waktu & mesin.

Benchmark Santai

ini benchmark kecil pake SQLite (in-memory) dengan 40 ribu data per skema.
Tes yang dijalankan:

  • Insert 40 ribu row
  • Point lookup (SELECT by PK 5 ribu kali)
  • Range pagination (WHERE id > ? ORDER BY id LIMIT 100)
  • ORDER BY id DESC LIMIT 1000 (ambil yang terbaru)

Hasilnya singkatnya begini:

Skema Insert (40k) Lookup 5k Range Pages ORDER BY DESC
UUID v4 ~0.120s ~0.016s ~0.81ms 3.2ms
ULID ~0.082s ~0.015s ~0.75ms 0.35ms
CUID ~0.074s ~0.017s ~0.78ms 0.36ms

Visualisasi

Insert Time
Point Lookup
Range Pagination
Order By Desc

Jadi, kapan pakai yang mana?

  • UUID v4 cocok kalau:
    • Mau yang paling standar dan gampang diintegrasiin.
    • Data nggak terlalu besar (ribuan – ratusan ribu row).
    • Privasi penting (nggak mau keliatan kapan ID dibuat).
  • ULID cocok kalau:
    • Aplikasi sering ambil data berdasarkan urutan terbaru.
    • Skala data gede (jutaan row).
    • Mau ID yang bisa sortable by time.
  • CUID cocok kalau:
    • Pengen ID yang ramah URL dan lebih pendek.
    • Butuh tetap unik + efisien di DB.
    • Nggak masalah ada sedikit info waktu/host di ID.

Kesimpulan

  • UUID v4: aman, standar, udah terbukti.
  • ULID: paling enak buat aplikasi modern yang banyak main query “data terbaru”.
  • CUID: pilihan bagus kalau butuh ID unik yang simpel dan cocok dipajang di URL.

Kalau bikin sistem baru yang bakal besar skalanya, ULID atau CUID biasanya lebih ngasih keuntungan.
Tapi kalau project lama udah pakai UUID v4, nggak ada salahnya tetap stay di sana.

Referensi

Read next

Comments ()