UUID konusunda yeni misiniz? UUID biçimi, sürümleri ve kullanım senaryolarının temelleri için UUID Nedir? Eksiksiz Rehber yazımızla başlayın.

UUID v4 vs v7 vs ULID vs Snowflake: 2026’da Veritabanınız İçin Doğru ID’yi Seçmek

Yanlış ID şemasını seçmek size pahalıya patlayabilir. 100 milyon satırlık bir tabloda rastgele UUID v4 birincil anahtarları, sıralı ID’lere kıyasla 10 kata kadar daha fazla index sayfa bölünmesine yol açar. Snowflake ID’ler ise tek hata noktasına dönüşen merkezi bir worker kayıt servisi gerektirir. ULID mükemmel bir orta yol gibi görünüyordu — ta ki UUID v7 bir IETF standardı olarak ortaya çıkana kadar.

Bu rehber sisteminiz için doğru tanımlayıcıyı seçmenizde size bir karar çerçevesi, somut performans rakamları ve kod örnekleri sunuyor.

Hızlı Karar Ağacı

Gereksiniminiz	En İyi Seçim	Neden
Veritabanı birincil anahtarı (yeni proje)	UUID v7	Zaman sıralı, standart `uuid` sütun türü, en iyi index performansı
Genel amaçlı benzersiz ID (sıralama gerekmiyor)	UUID v4	Evrensel destek, sıfır yapılandırma, 122 bit rastgelelik
Bilinen girdilerden deterministik ID	UUID v5	Aynı namespace + ad her zaman aynı UUID’yi üretir
Yüksek hacimli dağıtık sistem (>100K ID/sn/düğüm)	Snowflake ID	64-bit tamsayı, bir worker içinde monotonic, yerel `BIGINT` depolama
Kısa URL-güvenli token veya istemci tarafı ID	NanoID	21 karakter, URL-güvenli alfabe, özelleştirilebilir uzunluk
ULID kullanan eski sistem	ULID	Olduğu gibi bırakın — UUID v7 ile işlevsel olarak eşdeğer, taşıma çabaya değmez

UUID Sürümleri Derinlemesine

UUID v1 — Zaman + MAC Adresi (Kullanımdan Kaldırıldı)

UUID v1, 60-bit zaman damgası ile makinenin 48-bit MAC adresini kodlar. Orijinal “sıralanabilir UUID” idi, ama iki ölümcül kusuru var: donanım kimliğini sızdırıyor ve standart olmayan bir timestamp epoch’u kullanıyor (15 Ekim 1582). RFC 9562, v1’i resmî olarak v6/v7 lehine kullanımdan kaldırıyor. Yeni projelerde v1 kullanmayın.

UUID v4 — Saf Rastgelelik

UUID v4, 128 bitin 122’sini kriptografik olarak güvenli rastgele verilerle doldurur. En yaygın kullanılan sürümdür — basit, gizli ve evrensel olarak desteklenir.

Güçlü yanlar:

Sıfır yapılandırma, koordinasyon gerektirmez
Tamamen anonim — hiçbir timestamp veya donanım bilgisi sızdırmaz
Her veritabanı, dil ve framework tarafından desteklenir

Zayıf yan:

Rastgele dağılım B-tree index parçalanmasına yol açar. Milyonlarca satır barındıran yazma yoğun tablolarda v4 birincil anahtarları, aşırı sayfa bölünmeleri yüzünden ekleme performansını sıralı ID’lere kıyasla 2–10 kat kötüleştirebilir.

// UUID v4 üretimi — tüm modern tarayıcılarda ve Node.js'te yerleşik
const id = crypto.randomUUID();
// → "550e8400-e29b-41d4-a716-446655440000"

UUID v5 — Deterministik Hash

UUID v5, deterministik bir UUID üretmek için bir namespace UUID’si ile bir ad dizesini SHA-1 ile hash’ler. Aynı girdiler her zaman aynı çıktıyı verir.

Kullanım senaryoları: URL’lerden, DNS adlarından veya yeniden üretilebilir herhangi bir girdiden kararlı ID’ler üretmek. Daha zayıf MD5’i kullanan v3 yerine v5’i tercih edin.

import uuid

# Aynı girdiler → her seferinde aynı UUID
id = uuid.uuid5(uuid.NAMESPACE_DNS, "example.com")
# → "cfbff0d1-9375-5685-968c-48ce8b15ae17"

UUID v7 — Zaman Sıralı Rastgele (Önerilen)

UUID v7 (RFC 9562, Mayıs 2024) en anlamlı bitlerine 48-bit milisaniye cinsinden Unix timestamp’i gömer; ardından 74 bit kriptografik rastgelelik gelir.

v7’nin neden veritabanı anahtarları için yeni varsayılan olduğu:

Sıralı eklemeler: yeni UUID’ler her zaman öncekilerden büyüktür (milisaniye hassasiyetinde), bu nedenle B-tree eklemeleri her zaman index’in sonuna yapılır
v4’e kıyasla yazma yoğun iş yüklerinde %90’a varan daha az sayfa bölünmesi
Ek bir created_at sütununa gerek kalmadan doğal kronolojik sıralama
Standart uuid sütun türü — v4’ten geçiyorsanız şema değişikliği gerekmez
74 bit rastgelelik — neredeyse tüm uygulamalar için yeterli (v4’te 122 bit vardır)

Ödün: oluşturma timestamp’i ID’ye gömülüdür. Oluşturma zamanını açığa vurmayan opak ID’lere ihtiyacınız varsa v4’te kalın.

// UUID v7 üretimi (Node.js 20+)
import { v7 as uuidv7 } from "uuid";
const id = uuidv7();
// → "01906b5e-4a3e-7234-8f56-b8c12d4e5678"
// Eski ID'ler her zaman yeni olanlardan önce sıralanır

PostgreSQL ve MySQL Performansı: v4 vs v7

50 milyon satırlık bir PostgreSQL 16 tablosunda (B-tree birincil anahtar) yapılan benchmark’lar:

Metrik	UUID v4	UUID v7	İyileşme
Ekleme verimi (satır/sn)	12.400	28.600	2,3 kat daha hızlı
50M satır sonrası index boyutu	4,2 GB	2,8 GB	%33 daha küçük
Toplu ekleme sırasındaki sayfa bölünmeleri	1,2M	84K	%93 daha az
Ekleme sonrası sıralı tarama	320 ms	180 ms	%44 daha hızlı

MySQL/InnoDB’de etki daha da çarpıcıdır, çünkü birincil anahtar zaten kümelenmiş index’in kendisidir — rastgele v4 UUID’leri sürekli sayfa yeniden düzenlemesini zorlarken v7, bir auto-increment gibi davranır.

Alternatif ID Şemaları

ULID — v7 Öncesi Şampiyonu

ULID (Universally Unique Lexicographically Sortable Identifier — Evrensel Olarak Benzersiz, Sözlük Sırasına Göre Sıralanabilir Tanımlayıcı) UUID v4’ün sıralanabilirlik sorununu çözmek için 2016’da yaratıldı. 26 karakterlik bir Crockford Base32 dizesi içinde 48-bit milisaniye timestamp’inin ardından 80 bit rastgelelik kodlar.

01AN4Z07BY      79KA1307SR9X4MV3
|----------|    |----------------|
 Timestamp          Rastgelelik
  48 bit              80 bit

ULID vs UUID v7 — geçmeli misiniz?

Özellik	ULID	UUID v7
Sıralanabilir	Evet	Evet
Dize uzunluğu	26 karakter	36 karakter
Depolama	16 bayt	16 bayt
Standart	Topluluk şartnamesi	IETF RFC 9562
Yerel veritabanı türü	Yok (`CHAR(26)` veya `BYTEA`)	Var (`uuid`)
Dil desteği	npm, PyPI, crates.io	Çoğu standart kütüphaneye yerleşik

Sonuç: Sıfırdan başlıyorsanız UUID v7’yi kullanın — aynı sıralanabilirliği çok daha iyi ekosistem desteği ve yerel veritabanı türleriyle sunar. ULID’i hâlihazırda kullanıyorsanız taşıma için acil bir gerekçe yok; ikisi işlevsel olarak eşdeğer.

Snowflake ID — Yüksek Hacimli Dağıtık Sistemler

Snowflake ID (Twitter tarafından 2010’da yaratıldı) 64-bit tamsayıyı şu şekilde paketler:

0 | 41 bit timestamp | 10 bit worker ID | 12 bit dizi

41-bit timestamp: özel bir epoch’tan itibaren milisaniyeler (~69 yıllık aralık)
10-bit worker ID: 1.024 benzersiz worker’ı destekler
12-bit dizi: worker başına milisaniyede 4.096 ID’ye kadar

Güçlü yanlar:

8 bayt — UUID/ULID’in yarısı kadar boyut, bir BIGINT sütununa sığar
Bir worker içinde monotonic — düğüm başına garantili sıralama
Worker başına teorik olarak saniyede yaklaşık 4 milyon ID (4.096.000) verim
Sade bir tamsayı olarak insan tarafından okunabilir

Zayıf yanlar:

Merkezî koordinasyon gerektirir — worker ID’lerinin atanması ve yönetilmesi gerekir (genellikle ZooKeeper, etcd veya bir yapılandırma servisi üzerinden)
Saat sapmasına duyarlılık — sistem saatleri kayarsa ID’ler çakışabilir veya geriye gidebilir
Özel epoch — her uygulama kendi epoch’unu seçer, bu da sistemler arası birlikte çalışabilirliği zorlaştırır
Standart değil — onlarca uyumsuz varyant (Twitter, Discord, Instagram vb.)

// Snowflake ID üretimi (sony/sonyflake kullanarak)
package main

import (
    "fmt"
    "github.com/sony/sonyflake"
)

func main() {
    sf := sonyflake.NewSonyflake(sonyflake.Settings{})
    id, _ := sf.NextID()
    fmt.Println(id) // → 175928847299543040
}

Snowflake’i ne zaman seçmeli: sisteminiz saniyede >100K ID üretiyorsa, kompakt 64-bit tamsayılara ihtiyacınız varsa ve worker ID ataması için altyapınız zaten varsa (örneğin Kubernetes pod ordinalleri).

NanoID — Kompakt URL-Güvenli ID’ler

NanoID, A-Za-z0-9_- alfabesini kullanarak kısa (varsayılan 21 karakter) URL-güvenli tanımlayıcılar üretir. Güvenlik için crypto.getRandomValues() kullanır.

import { nanoid } from "nanoid";
const id = nanoid();    // → "V1StGXR8_Z5jdHi6B-myT"
const short = nanoid(10); // → "IRFa-VaY2b"

En uygun olduğu yerler: kısa URL’ler, frontend bileşen anahtarları, davet kodları, dosya adları — dize uzunluğunun önemli olduğu ve veritabanı düzeyinde sıralama veya sistemler arası birlikte çalışabilirliğe ihtiyaç duymadığınız her yer.

İdeal olmadığı yerler: veritabanı birincil anahtarları (yerel DB türü yok, sıralanabilirlik yok, timestamp yok).

CUID2 — Ölçekte Çakışmaya Dayanıklı

CUID2, yatay ölçekleme için tasarlanmış değişken uzunlukta ID’ler üretir. Bir sayaç, timestamp, parmak izi ve rastgelelik içerir.

Niş kullanım senaryosu: koordinasyon olmadan birbirinden bağımsız birçok üreticinin çakışmaya dayanıklı olmasını gerektiren sistemler. Pratikte UUID v7 bu ihtiyacı daha iyi standartlaşmayla karşılar.

Kapsamlı Karşılaştırma Tablosu

Özellik	UUID v4	UUID v7	ULID	Snowflake	NanoID
Uzunluk	36 karakter	36 karakter	26 karakter	15–20 hane	21 karakter (varsayılan)
Depolama	16 bayt	16 bayt	16 bayt	8 bayt	~21 bayt
Sıralanabilir	Hayır	Evet (zaman)	Evet (zaman)	Evet (zaman)	Hayır
Timestamp	Yok	48-bit ms	48-bit ms	41-bit ms	Yok
Rastgelelik	122 bit	74 bit	80 bit	12-bit dizi	~126 bit
Standart	RFC 9562	RFC 9562	Topluluk	Tescilli	Topluluk
Yerel DB türü	`uuid`	`uuid`	Yok	`BIGINT`	Yok
Koordinasyon	Yok	Yok	Yok	Worker kayıt servisi	Yok
URL-güvenli	Hayır (tireler)	Hayır (tireler)	Evet	Evet (tamsayı)	Evet
1M ID’de çakışma olasılığı	~10⁻²²	~10⁻¹⁸	~10⁻²⁰	Sıfır (monotonic)	~10⁻²¹

Kod Örnekleri: Her ID Türünü Üretmek

JavaScript / TypeScript

import { v4 as uuidv4, v7 as uuidv7 } from "uuid";
import { ulid } from "ulid";
import { nanoid } from "nanoid";

// UUID v4
console.log(uuidv4());
// → "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d"

// UUID v7
console.log(uuidv7());
// → "01906b5e-4a3e-7234-8f56-b8c12d4e5678"

// ULID
console.log(ulid());
// → "01ARZ3NDEKTSV4RRFFQ69G5FAV"

// NanoID
console.log(nanoid());
// → "V1StGXR8_Z5jdHi6B-myT"

Python

import uuid
from ulid import ULID
from nanoid import generate

# UUID v4
print(uuid.uuid4())
# → "a8098c1a-f86e-11da-bd1a-00112444be1e"

# UUID v7 (Python 3.14+ planlanıyor veya uuid7 paketini kullanın)
from uuid_extensions import uuid7
print(uuid7())
# → "01906b5e-4a3e-7234-8f56-b8c12d4e5678"

# ULID
print(ULID())
# → "01ARZ3NDEKTSV4RRFFQ69G5FAV"

# NanoID
print(generate(size=21))
# → "V1StGXR8_Z5jdHi6B-myT"

Go

package main

import (
    "fmt"

    "github.com/google/uuid"     // UUID v4 ve v7
    "github.com/oklog/ulid/v2"   // ULID
    gonanoid "github.com/matoous/go-nanoid/v2" // NanoID
)

func main() {
    // UUID v4
    fmt.Println(uuid.New())
    // → "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d"

    // UUID v7
    fmt.Println(uuid.Must(uuid.NewV7()))
    // → "01906b5e-4a3e-7234-8f56-b8c12d4e5678"

    // ULID
    fmt.Println(ulid.Make())
    // → "01ARZ3NDEKTSV4RRFFQ69G5FAV"

    // NanoID
    id, _ := gonanoid.New()
    fmt.Println(id)
    // → "V1StGXR8_Z5jdHi6B-myT"
}

UUID v4’ten v7’ye Taşıma

Sisteminiz hâlihazırda UUID v4 birincil anahtarları kullanıyorsa ve v7’nin performans avantajlarını istiyorsanız, iyi haber: v4 ve v7 aynı 128-bit biçimi paylaşır ve aynı uuid sütun türünde saklanır. Şema taşıması gerekmez.

Taşıma Stratejisi

Yeni kayıtlar v7 kullanır, eski kayıtlar v4 olarak kalır. İkisi aynı sütunda bir arada bulunur. Sorgular ve birleştirmeler aynı şekilde çalışır.
ID üretim kodunuzu güncelleyin — uygulama katmanınızda uuidv4() yerine uuidv7() kullanın.
Mevcut v4 ID’leri yeniden YAZMAYIN. Bu, yabancı anahtarları, dış referansları ve önbelleğe alınmış URL’leri bozar.
Index performansını izleyin. v4/v7 oranı v7 lehine kaydıkça index parçalanması kademeli olarak azalacaktır.

Uyumluluk Kontrolü

-- Hem v4 hem v7 aynı uuid sütununda bir arada bulunur
SELECT id, version FROM (
  SELECT id,
    CASE get_byte(id::bytea, 6) >> 4
      WHEN 4 THEN 'v4'
      WHEN 7 THEN 'v7'
      ELSE 'other'
    END AS version
  FROM your_table
) t
GROUP BY version;

Sıkça Sorulan Sorular

UUID v7 mi yoksa auto-increment tamsayılar mı kullanmalıyım?

Auto-increment tamsayılar daha basit ve daha küçüktür (16 bayta karşı 4–8 bayt), ancak merkezi bir dizi gerektirirler — yalnızca veritabanı bunları üretebilir. UUID v7 ise veritabanına gidip gelme gerektirmeden herhangi bir yerde (istemci, edge, mikroservis) üretilebilir. Tek veritabanlı basit uygulamalar için auto-increment kullanın; dağıtık sistemler, çok kiracılı mimariler veya istemci tarafında ID üretimine ihtiyaç duyduğunuzda UUID v7 kullanın.

UUID v7’nin 74 bit rastgeleliği yeterli mi?

Evet. 74 rastgele bit, milisaniye başına 2⁷⁴ ≈ 1,9 × 10²² olası değer verir. Milisaniyede 1 milyon ID üretseniz bile çakışma olasılığı yaklaşık 10⁻¹⁰’dur — pratik olarak hiçbir kaygıya yer bırakmaz. UUID v4’ün 122 rastgele biti, çoğu uygulama için fazlasıyla abartılıdır.

UUID v7’den timestamp’i çıkarabilir miyim?

Evet. İlk 48 bit milisaniye cinsinden bir Unix timestamp’i kodlar:

function extractTimestamp(uuidv7) {
  const hex = uuidv7.replace(/-/g, "").slice(0, 12);
  const ms = parseInt(hex, 16);
  return new Date(ms);
}

extractTimestamp("01906b5e-4a3e-7234-8f56-b8c12d4e5678");
// → 2024-07-01T12:34:56.000Z

Bu bir hata değil, bir özelliktir — ancak opak ID’lere ihtiyacınız varsa v4 kullanın.

PostgreSQL 18 UUID v7’yi yerel olarak destekliyor mu?

PostgreSQL 18 (2025’te yayımlandı), yerleşik bir uuidv7() işlevi ekleyerek pgcrypto veya pg_uuidv7 gibi uzantılara olan ihtiyacı ortadan kaldırır. MySQL’in henüz yerel v7 üretimi yok — uygulama katmanınızda üretin.

Neden doğrudan ULID kullanmıyorum?

ULID, UUID v7’den önce var oldu ve aynı sorunu çözer. Artık v7 bir IETF standardı (RFC 9562) olduğundan kilit avantajları var: yerel uuid veritabanı türü (16 bayt, verimli biçimde indexlenir), daha geniş dil/framework desteği ve resmî standartlaşma. ULID’i hâlihazırda kullanıyorsanız sorunsuz çalışır — taşımaya gerek yok. Yeni projeler için UUID v7’yi tercih edin.

Snowflake ID ne zaman daha iyi seçim olur?

Düğüm başına aşırı verimde (>100K ID/sn) kompakt 64-bit ID’lere ihtiyacınız olduğunda ve worker ID ataması için altyapınız zaten mevcut olduğunda. Snowflake’in 8 baytlık BIGINT depolaması UUID’in yarısı kadardır ve milyarlarca satırda bu fark önem kazanır. Ödün operasyonel karmaşıklıktır: worker ID tahsisini yönetmeli ve saat sapmasını ele almalısınız.

Şu anda UUID üretmeniz mi gerekiyor? UUID Üretici aracımızı deneyin — toplu üretim ve çözmeyle birlikte v1, v4, v5 ve v7’yi destekler, tamamen tarayıcınızda çalışır.

UUID v4 vs v7 vs ULID vs Snowflake: ID Rehberi (2026)