Database Sharding 2026: Vitess, Citus, CockroachDB ile Horizontal Ölçeklendirme

Modern bir SaaS uygulaması 500 GB veri ve 10.000 QPS‘in üzerine çıkmaya başladığında tek bir veritabanı yetersiz kalır. Vertikal ölçekleme (daha güçlü makine) belirli bir noktaya kadar gider; sonrasında horizontal sharding (veriyi birden çok makineye bölmek) zorunlu olur. 2026 itibarıyla 100M+ kayıtlı PostgreSQL/MySQL deployment’larının %64’ü bir tür sharding uyguluyor; Vitess, Citus, CockroachDB, YugabyteDB gibi çözümler enterprise standart haline geldi. Türkiye’de büyük ölçek SaaS şirketlerinin %29’u 2024-2026 döneminde sharding’e geçti veya geçiş planına başladı.

Bu rehberde sharding stratejilerini, hangi senaryoda hangi çözümün uygun olduğunu, üretim hatalarını, Türkiye özelinde geçiş notlarını ve maliyet etkilerini somut sayılarla aktarıyoruz.

Sharding Nedir, Ne Zaman Gerekli?

Sharding, büyük bir tabloyu (genelde 100M+ satır) belirli bir anahtara göre N farklı veritabanına bölmek demektir. Tipik tetikleyiciler:

• Tek node disk dolmaya başladı (>1 TB).
• Sorgular yavaşlamaya başladı (p99 > 200 ms).
• Tek node CPU sürekli %80+ kullanım.
• Write contention (lock kavgası).
• Coğrafi dağılım (Türkiye + Avrupa + ABD).
• Backup süresi 4 saatten uzun (RTO/RPO ihlali).

Sharding’den önce her zaman: index optimizasyonu, query refactoring, read replica, caching, partitioning denenmeli. Bu adımlar başarısız olduğunda sharding’e geçilir. Tek PostgreSQL’i en uca kadar çıkartmak için PostgreSQL tuning rehberimize, partitioning öncesi için PostgreSQL partitioning içeriğimize, HA için Patroni + Pgpool rehberimize bakabilirsiniz.

Sharding Stratejileri

1. Range-Based Sharding

Bir aralığa göre böler (örn. user_id 1-1M → shard 1, 1M-2M → shard 2). Avantaj: range sorgu basit. Dezavantaj: hot spot — yeni kullanıcılar son shard’a düşer, eski shard’lar boş kalır.

2. Hash-Based Sharding

Anahtarın hash’ine göre dağıtım (consistent hashing). Avantaj: uniform dağıtım. Dezavantaj: range sorgu zor — birden çok shard’a gitmek gerek.

3. Geographic Sharding

Coğrafi bölgeye göre (TR kullanıcıları İstanbul shard, EU kullanıcıları Frankfurt shard). Avantaj: latency düşük, GDPR/KVKK uyumlu. Dezavantaj: cross-region query karmaşık.

4. Tenant-Based Sharding (Multi-tenant SaaS)

Müşteri/tenant bazlı bölme. Büyük müşteriler kendi shard’larında, küçükler shared shard’da. SaaS için en yaygın.

Sharding Çözümleri Karşılaştırması

Çözüm	Tip	Pros	Cons
Vitess	MySQL sharding layer	YouTube/Slack referans, mature	Operasyonel ağır
Citus	PostgreSQL extension	Acquired by Microsoft, Azure managed	Limited DDL
CockroachDB	Distributed SQL (PostgreSQL wire)	Auto-sharding, multi-region	Pahalı, sorgu optimizer eksik
YugabyteDB	Distributed SQL	PostgreSQL/Cassandra API	Topluluk küçük
TiDB	MySQL-compatible distributed	HTAP (OLTP+OLAP)	Bellek kullanımı yüksek
Custom app-level	Application-side routing	Tam kontrol	Kod karmaşık, hata riski yüksek

CockroachDB vs klasik PostgreSQL kararı için PostgreSQL vs CockroachDB karşılaştırmamızı okumanızı öneririm.

Üretim Mimarisi: Vitess Örneği

Vitess, YouTube tarafından geliştirilen MySQL sharding katmanı. Bileşenler:

• vtgate: Sorgu yönlendirici (proxy). Uygulama buraya bağlanır.
• vttablet: Her MySQL shard’ının önünde duran agent.
• VTOrc: Otomatik failover.
• Topology service: etcd/Consul — shard metadata.
• vtctld: Yönetim (rebalance, backup, restore).

Vindex (Sharding Key)

Tablonun nasıl bölüneceğini Vindex tanımlar:

• Hash: En yaygın — user_id hash → shard.
• Lookup: Bir ek tabloda key→shard mapping (esnek ama yavaş).
• Composite: Birden çok kolon birlikte (tenant_id + user_id).

Citus Örneği (PostgreSQL Sharding)

Citus, PostgreSQL extension olarak çalışır. Azure Database for PostgreSQL — Hyperscale (Citus) ile managed. Tablo dağıtma:

• SELECT create_distributed_table('orders', 'tenant_id');
• Sharding key = tenant_id.
• Worker node’lar arası otomatik dağıtım.
• Coordinator node sorgu planını N worker’a paralel gönderir.
• Reference tablolar (örn. ürün kategori) tüm worker’larda kopyalanır.

Cross-Shard Sorgu Problemi

Sharding’in en büyük dezavantajı: bir sorgu birden çok shard’ı kapsadığında yavaşlar veya imkansız hale gelir. Çözümler:

• Avoid: Schema tasarımı sorguları tek shard’a sığacak şekilde.
• Scatter-gather: Tüm shard’lara paralel sorgu, sonuçları merkez toplar.
• Read replica + materialized view: Cross-shard analytic için.
• OLAP’a taşıma: ClickHouse veya BigQuery’ye CDC ile akıt, analytic orada.

OLAP’a CDC ile veri taşıma için event-driven architecture rehberini, geniş veri pipeline’ı için Spark + Kafka data pipeline içeriğimizi öneririm.

Resharding (Shard Sayısını Değiştirme)

Sharding kurulumundan sonra büyüyüp daha çok shard’a ihtiyaç olursa resharding yapılır:

• Vitess: VReplication ile sıfır kesinti.
• Citus: tablo yeniden dağıtım — ortalama 30 dk-2 saat (TB başına).
• CockroachDB: otomatik (range-based, auto-split).
• Custom: çok zor — uygulama dual-write yapmak zorunda.

Tutarlılık Garantileri

• Single-shard transaction: Tam ACID (PostgreSQL/MySQL’in kendi).
• Cross-shard transaction: 2PC veya saga pattern. CockroachDB ve YugabyteDB destekler.
• Eventual consistency: CDC-tabanlı pipeline’larda.
• Read replica: Replication lag genelde 100-500 ms.

Türkiye Özelinde Geçiş Notları

• KVKK + veri lokasyonu: Geographic sharding ile TR/EU shard’lar; kişisel veri Türkiye/EU içinde tutulmalı (BDDK, finans için zorunlu).
• Yerel managed eksikliği: Azure Hyperscale Citus en yaygın managed seçenek; CockroachDB Cloud Frankfurt EU üzerinden kullanılabilir.
• DBA + SRE profili: Vitess operasyonu için kıdemli MySQL DBA + Kubernetes/SRE yetkinliği gerekli; Citus PostgreSQL DBA’lerinin geçişi daha kolay.
• Bank/finans regülasyonu: BDDK uyumu için cross-region replication üzerinde özel disclosure ve audit log gerekiyor.
• Maliyet hassasiyeti: 8-shard cluster aylık 50-150K TL ekleyebilir; ROI hesabı önceden yapılmalı (incidet maliyeti vs sharding maliyeti).

Maliyet ve Karmaşıklık

• Single PostgreSQL → 8-shard Citus: aylık altyapı 4-7x artar, ama performans 10-20x artar.
• Operasyonel yük: 0,5 DBA → 1,5-2 DBA + SRE.
• CockroachDB managed (Cockroach Cloud): 10 GB veri için 200 USD/ay, 1 TB için 1.500 USD/ay.
• Vitess self-hosted: 8-shard MySQL cluster aylık 50.000-120.000 TL.
• YugabyteDB Anywhere: enterprise lisans + node başına 200-400 USD/ay.

Yaygın Üretim Hataları

• Yanlış sharding key: Bir tenant aşırı büyür (hot tenant), shard’ı doyurur.
• Cross-shard join’ler: Çoklu shard JOIN denemesi — yavaşlık.
• Resharding ihmal: Trafik büyüdüğünde shard sayısı sabit kalır.
• Backup tutarsızlığı: Tüm shard’lar aynı zamanda snapshot alınmalı.
• Schema değişikliği: N shard’a senkron ALTER TABLE — uzun sürer.
• Sharding’e erken geçiş: 10K QPS altındaki ekipler hâlâ tek node’da kalabilirken sharding ekleyip karmaşıklık yaratıyor.

Sık Sorulan Sorular

Ömer Önal’dan pratik not: Türkiye’de sharding geçişi danışmanlığı verdiğim ekiplerde gördüğüm en kritik hata, doğru hazırlık yapmadan büyük “rewrite” projesi başlatmak. Sharding bir yazılım göçü değil, mimari evrimdir — 4-8 hafta sürer ve doğrudan canlı sistemde yapılır. Pratik yol haritam şu: 1. Hafta: sharding key seçimi (tenant_id genelde en sağlıklısı), workload analizi. 2-3. Hafta: staging’de Citus/CockroachDB kurulum + tüm sorguların plan analizi (cross-shard olanları workaround’la temizleme). 4-5. Hafta: CDC ile yeni cluster’a sync, dual-read pattern ile shadow validation. 6-7. Hafta: traffic cutover (% bazlı kanary). 8. Hafta: eski cluster’ı decommission. Bu süreyi 2 haftaya sıkıştıran ekiplerde “ay bu sorgu da cross-shard’mış” tipi sürprizlerle multi-day outage’lar oluyor. Sizin sisteminizde şu an tek node mu yoksa shard’lı mı? Hangi aşamadasınız — değerlendirme, pilot, yoksa üretim?

Sonuç

Database sharding, 100M+ kayıtlı SaaS sistemlerinde kaçınılmaz bir mimari adım. Doğru sharding stratejisi (tenant-based + hash) + uygun çözüm (Vitess/Citus/CockroachDB) ile sorgu performansı 10-20x artar, sistem tek node sınırlamalarından kurtulur, geo-distribution ve disaster recovery doğal olarak gelir. Ancak operasyonel karmaşıklık ve maliyet 4-7x artar — bu yatırım dikkatli planlanmalı. Tamamlayıcı içerikler: polyglot persistence, event-driven mimari, embedded analytics ve performance testing. İletişim formundan projeniz için sharding mimari değerlendirme talep edebilirsiniz.

Dış otorite kaynaklar: Vitess · Citus · CockroachDB · YugabyteDB