UUID birincil anahtarı, dışarıya (URL'de) göstermek güvenli mi?

Evet, hatta auto-increment'e göre daha güvenlidir. Sıralı bir sayısal ID (ör. /siparis/1042) rakiplere toplam sipariş sayınızı sızdırır ve bir sonraki/önceki kaydı tahmin etmeyi (IDOR saldırısı denemesi) kolaylaştırır. Rastgele bir UUID bu bilgiyi sızdırmaz.

Mimari Yayın: 17 Temmuz 2026 8 dk okuma

Veritabanında UUID Kullanımının Artı ve Eksileri

Q: UUID'i veritabanı birincil anahtarı yapmanın avantajı nedir?

UUID, birden fazla sunucu veya istemcinin merkezi bir sayaca danışmadan çakışmasız kayıt oluşturmasını sağlar. Bu, dağıtık sistemlerde, çevrimdışı senkronizasyonda ve veri birleştirmede (merge) auto-increment sütunların yaşadığı çakışma sorununu ortadan kaldırır. Ayrıca kayıt sayısını (ID'den tahmin edilebilecek iş hacmini) dışarıya sızdırmaz.

Q: UUID veritabanı performansını neden düşürebilir?

Tamamen rastgele UUID'ler (v4) sıralı olmadığından, B-tree indekslerine her ekleme rastgele bir konuma denk gelir. Bu, indeksin sürekli yeniden dengelenmesine (sayfa bölünmesi) yol açar, önbellek isabet oranını düşürür ve auto-increment'e göre yazma performansını kötüleştirebilir.

Q: UUID kaç bayt yer kaplar, bu önemli mi?

Bir UUID ham olarak 16 bayttır (metinsel sütunda saklanırsa 36 karakter/bayt). Buna karşılık bir BIGINT auto-increment yalnızca 8 bayttır. Milyonlarca satırlık tablolarda ve bu anahtara referans veren her yabancı anahtar sütununda bu fark, toplam depolama ve indeks boyutunu belirgin şekilde büyütebilir.

Q: UUID v7 veya ULID bu sorunu çözer mi?

Evet. v7 UUID ve ULID, ilk bitlerinde milisaniye zaman damgası taşıdığından art arda üretilen değerler sözlüksel olarak da artan sıradadır. Bu, B-tree indekslerine sıralı ekleme yapılmasını sağlar ve v4'e kıyasla indeks parçalanmasını büyük ölçüde azaltır — auto-increment'e yakın yazma performansı sunar.

Q: Hangi durumda auto-increment, hangi durumda UUID kullanmalıyım?

Tek sunuculu, basit uygulamalarda ve indeks performansı kritikse auto-increment (veya v7/ULID) tercih edin. Dağıtık sistemlerde, çevrimdışı senkronizasyon gerektiren istemcilerde, kayıt sayısının gizlenmesi gerektiği (tahmin edilebilir ID güvenlik riski oluşturduğu) senaryolarda UUID (tercihen v7) kullanın.

"Birincil anahtar için UUID mi, auto-increment mı?" sorusu her yeni şema tasarımında karşınıza çıkar ve doğru cevap "duruma göre değişir"dir. Bu rehberde UUID'i veritabanı birincil anahtarı yapmanın gerçek artılarını ve eksilerini karşılaştırma tablolarıyla ortaya koyuyoruz.

İçindekiler

Artı mı eksi mi ağır basar? (kısa cevap)
Artılar: UUID neden tercih edilir?
Eksiler: performans ve depolama maliyeti
Auto-increment vs v4 UUID vs v7/ULID
Hangi durumda hangisini kullanmalı?
Pratik öneriler
Sık sorulan sorular

UUID'i veritabanı birincil anahtarı yapmalı mıyım?

Kısa cevap Tek sunuculu, basit uygulamalarda auto-increment genelde en performanslı seçimdir. Ancak dağıtık sistemlerde, çevrimdışı senkronizasyonda veya kayıt sayısının gizlenmesi gerektiğinde UUID gerekli hale gelir. Klasik v4 UUID'in indeks performansı sorununu, zaman damgası taşıyan v7 UUID veya ULID büyük ölçüde çözer — bu yüzden 2024 sonrası projelerde v7/ULID öneriliyor.

Yani soru aslında "UUID mi auto-increment mı" değil, "hangi UUID versiyonu mu, yoksa auto-increment mi" şeklinde sorulmalı. Aşağıda her iki yaklaşımın da gerçek avantaj ve dezavantajlarını inceliyoruz; kendi UUID'lerinizi UUID Üretici'de deneyebilirsiniz.

Artılar: UUID neden tercih edilir?

Kısa cevap UUID'in en büyük avantajı, birden fazla sunucu veya istemcinin merkezi bir koordinasyon noktasına danışmadan çakışmasız kayıt oluşturabilmesidir. Buna ek olarak kayıt sayısını dışarıya sızdırmaz ve ID'yi tahmin edilemez kılarak güvenlik katmanı ekler.

Dağıtık üretim: Birden fazla sunucu, mikroservis veya çevrimdışı mobil istemci, birbirine danışmadan kayıt oluşturabilir; senkronizasyon anında ID çakışması yaşanmaz.
Merkezi koordinasyon gerekmez: Auto-increment'te "bir sonraki ID kaç" sorusunun tek bir doğru cevabı olmalıdır (bu bir darboğaz noktası olabilir); UUID'de böyle bir soru yoktur.
Bilgi sızdırmaz: Sıralı bir ID (/siparis/1042) toplam sipariş sayınızı ve büyüme hızınızı rakiplere açık eder; UUID bu bilgiyi gizler.
Tahmin edilemez, daha güvenli: Sıralı ID'ler bir sonraki/önceki kaydı deneyerek erişim (IDOR) saldırılarına açık kapı bırakır; rastgele UUID bunu pratik olarak imkânsız kılar.
Birleştirme (merge) kolaylığı: İki veritabanını (ör. şirket birleşmesi, çoklu bölge replikasyonu) birleştirirken auto-increment ID'ler çakışır; UUID'ler çakışmaz.

Eksiler: performans ve depolama maliyeti

Kısa cevap Tamamen rastgele UUID'ler (v4), B-tree indekslerine rastgele sırayla eklenir; bu, indeksin sürekli yeniden dengelenmesine (sayfa bölünmesi/fragmentation) yol açar ve yazma performansını düşürür. Ayrıca 16 bayt, bir BIGINT'in (8 bayt) iki katı yer kaplar — milyonlarca satır ve çok sayıda yabancı anahtarda bu fark birikir.

Bu problemin kökeni şudur: çoğu ilişkisel veritabanı motoru (MySQL/InnoDB, PostgreSQL, SQL Server) birincil anahtar indeksini B-tree yapısında tutar ve yeni satırların sıralı eklenmesini bekleyecek şekilde optimize edilmiştir. Auto-increment bu varsayıma uyar; her yeni satır indeksin sonuna eklenir. Tamamen rastgele bir v4 UUID ise indeksin rastgele bir noktasına düşer — bu da sayfa bölünmesine (page split) ve önbellek isabet oranının düşmesine yol açar.

Birincil anahtar seçiminin etkisi (genel eğilim, veritabanı motoruna göre değişir)
Etki alanı	Auto-increment (BIGINT)	v4 UUID (rastgele)
Anahtar boyutu	8 bayt	16 bayt
İndeks ekleme sırası	Sıralı (indeks sonuna)	Rastgele (indeksin her yerine)
Sayfa bölünmesi (fragmentation)	Minimal	Yüksek olabilir
Kayıt sayısını gizleme	Hayır (sızdırır)	Evet
Dağıtık/çevrimdışı üretim	Hayır (çakışma riski)	Evet (çakışmasız)

Not: Gerçek etki; veritabanı motoru, indeks türü ve donanıma (SSD/NVMe) göre değişir. NVMe SSD'lerde rastgele I/O maliyeti eski dönemlere göre belirgin şekilde azalmıştır.

Benzersiz içgörü "UUID yavaştır" genellemesi yanlıştır — doğrusu "tamamen rastgele (v4) UUID, sıralı olmayan indeks ekleme yüzünden yavaşlayabilir"dir. Sorun UUID'in kendisi değil, rastgeleliğin indeks üzerindeki etkisidir. Zaman damgası taşıyan bir UUID (v7) veya ULID kullanıldığında bu fark büyük ölçüde ortadan kalkar.

v7 UUID'i hemen deneyin

Zaman sıralı, veritabanı dostu v7 UUID üretimi — art arda üretilen değerler sözlüksel olarak da zaman sırasına uyar.

UUID Üreticiyi Aç →

Auto-increment, v4 UUID ve v7/ULID karşılaştırması

Aşağıdaki tablo, birincil anahtar seçiminde en sık karşılaştırılan üç yaklaşımı özetler. v7 ve ULID, "UUID'in dağıtık üretim avantajı" ile "auto-increment'in sıralı indeks avantajı"nı birleştirmeyi hedefler:

Birincil anahtar seçenekleri karşılaştırması
Özellik	Auto-increment	v4 UUID	v7 UUID / ULID
Çakışmasız dağıtık üretim	Hayır	Evet	Evet
Sıralı indeks eklemesi	Evet	Hayır	Evet (yaklaşık)
Kayıt sayısını gizler	Hayır	Evet	Kısmen (zaman sızdırır)
Boyut	8 bayt	16 bayt	16 bayt (ULID: 26 karakter metin)
Ekosistem desteği	Evrensel	Çok yaygın	Artan, bazı ORM'lerde ek kütüphane gerekir

v7 ve ULID'in "kısmen gizler" notu önemlidir: zaman damgası içerdikleri için bir kaydın yaklaşık ne zaman oluşturulduğunu ifşa ederler (tam sayıyı değil). Kayıt zamanının gizli kalması kritikse (ör. hassas finansal veriler), v4 tercih edilmelidir.

Hangi durumda hangisini kullanmalı?

Kısa cevap Tek sunuculu basit uygulamalarda ve maksimum yazma performansı gerekiyorsa auto-increment. Dağıtık/çok bölgeli sistemlerde, mikroservislerde veya URL'de ID gösterilecekse v7 UUID ya da ULID (auto-increment'in performansına yakın, UUID'in dağıtık avantajına sahip). Kayıt zamanının kesinlikle gizli kalması gerekiyorsa v4 UUID.

Küçük/orta ölçekli, tek veritabanlı uygulama: auto-increment (BIGINT) genelde en basit, performanslı seçimdir.
Mikroservis mimarisi veya çok bölgeli veritabanı: v7 UUID veya ULID — dağıtık üretim + sıralı indeks avantajını birlikte sunar.
URL'de ID gösterilecek, kayıt sayısı gizli kalmalı (ör. sipariş no): v4 UUID veya ULID.
Çevrimdışı çalışan mobil/masaüstü istemciler: v4 veya v7 UUID zorunludur — auto-increment çevrimdışı üretilemez.
Eski, değiştirilemeyen auto-increment şema: dışarıya gösterilecek ayrı bir "public_id" (UUID) sütunu ekleyip iç ilişkilerde auto-increment'i koruyabilirsiniz.

Pratik öneriler özeti

Veritabanında UUID kullanırken pratik öneriler
#	Öneri
1	Mümkünse v4 yerine v7 UUID veya ULID kullanın — indeks parçalanması riskini azaltır.
2	UUID'i metin (`VARCHAR(36)`) değil, yerel binary/UUID tipinde saklayın — depolama ve karşılaştırma performansı daha iyidir.
3	Yüksek yazma hacimli tablolarda önce ölçüm yapın — NVMe SSD rastgele I/O maliyetini büyük ölçüde azaltmış olabilir.
4	Mevcut auto-increment şemayı bozmadan, dışarıya gösterilecek bir `public_id` (UUID) sütunu ekleyebilirsiniz.
5	Kayıt zamanının kesinlikle gizli kalması gerekiyorsa v7/ULID yerine v4'ü tercih edin.

UUID versiyonlarının farkını daha derin incelemek isterseniz "UUID Sürümleri Arasındaki Fark (v1, v4, v5)" rehberimize, temel kavramlara ise "UUID Nedir, Ne İşe Yarar?" yazımıza göz atabilirsiniz.

Sık sorulan sorular

UUID'i veritabanı birincil anahtarı yapmanın avantajı nedir?

Birden fazla sunucu/istemci, merkezi bir sayaca danışmadan çakışmasız kayıt oluşturabilir. Bu, dağıtık sistemlerde auto-increment'in yaşadığı çakışma sorununu ortadan kaldırır; ayrıca kayıt sayısını sızdırmaz.

UUID veritabanı performansını neden düşürebilir?

Tamamen rastgele UUID'ler (v4) sıralı olmadığından B-tree indekslerine her ekleme rastgele bir konuma denk gelir; bu sayfa bölünmesine yol açıp yazma performansını kötüleştirebilir.

UUID kaç bayt yer kaplar, bu önemli mi?

Ham olarak 16 bayttır; BIGINT auto-increment ise 8 bayttır. Milyonlarca satırlık tablolarda ve yabancı anahtar sütunlarında bu fark toplam depolamayı belirgin şekilde büyütebilir.

UUID v7 veya ULID bu sorunu çözer mi?

Evet. İlk bitlerinde milisaniye zaman damgası taşıdıklarından art arda üretilen değerler sözlüksel olarak da artan sıradadır; bu, v4'e kıyasla indeks parçalanmasını büyük ölçüde azaltır.

Hangi durumda auto-increment, hangi durumda UUID kullanmalıyım?

Tek sunuculu, basit uygulamalarda auto-increment (veya v7/ULID) tercih edin. Dağıtık sistemlerde veya kayıt sayısının gizlenmesi gerektiğinde UUID (tercihen v7) kullanın.

UUID birincil anahtarı URL'de göstermek güvenli mi?

Evet, hatta auto-increment'e göre daha güvenlidir. Sıralı bir ID toplam kayıt sayınızı sızdırır ve IDOR saldırılarını kolaylaştırır; rastgele UUID bu bilgiyi sızdırmaz.

İlgili rehberler

Metodoloji & kaynaklar. Bu yazıdaki genel performans eğilimleri, yaygın veritabanı mühendisliği literatürüne ve B-tree indeks davranışına dayanır; kesin sayısal etki veritabanı motoru, donanım ve iş yüküne göre değişir — kritik kararlar için kendi ortamınızda ölçüm yapmanızı öneririz. Kaynaklar: RFC 9562 (UUID v7 tanımı) · ULID resmi spesifikasyonu · yaygın ilişkisel veritabanı (B-tree indeks) mühendisliği pratikleri. Son güncelleme: 17 Temmuz 2026.