Nasıl Çalışır

UUID (Universally Unique Identifier), çakışma olasılığı pratik olarak sıfır olan 128-bit tanımlayıcıdır. Çeşitli sürümleri vardır; pratikte ikisi öne çıkar: v4 ve v7.

UUID v4

128 bitin 122’si rastgeledir — 4 bitlik sürüm ve 2 bitlik varyant alanları sabittir. crypto.randomUUID() ile üretilir.

123e4567-e89b-42d3-a456-426614174000
              ^
              version (4)

Avantajı: dağıtık bir sistemde koordinasyon olmadan benzersiz ID üretebilirsiniz.

Dezavantajı: zamansal sıra yoktur. Veritabanı primary key olarak kullanıldığında B-tree index’i sürekli farklı sayfalara yazılır — insert performansı bozulur, özellikle yüksek hacimli tablolarda.

UUID v7

RFC 9562 (2024). İlk 48 bit Unix milisaniye timestamp’i, kalan 80 bitin 74’ü rastgele. Hâlâ benzersiz, ama zaman sıralı.

01876d10-1b21-7000-8000-000000000000
^^^^^^^^^^^^^ ^
timestamp ms  version (7)

Veritabanı primary key için neden v7 daha iyi:

Tablodaki yeni satırlar B-tree’nin sonuna yazılır.
Index split’leri azalır.
Cache locality artar.
Tarih bazlı sorgular index’ten yararlanabilir.

Hangi durumda hangisi?

Durum	Tercih
Veritabanı primary key	v7
API’de üretilen genel kimlikler	v7 veya v4
Tahmin edilemezliğin kritik olduğu yerler (örn. session token)	v4
Eski bir sistemle uyum	v4 (her yer destekliyor)

v1, v3, v5 ne durumda?

v1: MAC adresi + timestamp. Gizlilik açığı (cihazı sızdırıyor). Kullanmayın.
v3, v5: bir namespace ile ad değerinin hash’i. Belirli bir use case için (örneğin deterministik ID lazımsa); aksi takdirde v4/v7’yi tercih edin.

Çakışma olasılığı

UUID v4 için: saniyede 1 milyar UUID üretseniz bile, çakışma görmek için yaklaşık 85 yıl geçmesi gerekir. v7 için zaman parçası iki UUID’nin aynı milisaniyede üretilmiş olmasını gerektirir — rastgele kısımdaki çakışma olasılığı yine ihmal edilebilir.

Gizlilik

UUID’ler tarayıcınızda Web Crypto API ile üretilir — v4 için crypto.randomUUID(), v7 için crypto.getRandomValues.