PostgreSQL Sharding 2026: Range, Hash, Geographic Stratejileri

PostgreSQL sharding 2026’da kurumsal veri ölçeklenmesi için pratik çözüm olarak öne çıkıyor; Citus Data 2025 raporuna göre PostgreSQL horizontal scaling kuran ekiplerde ortalama sorgu süresi %63 düştü, 10TB+ veri seti yönetiminde toplam altyapı TCO’su %44 azaldı ve doğru shard anahtarı seçimi 18 ay sonra rebalancing maliyetini %78 azaltabiliyor. Konuyla ilişkili olarak Vitess ile MySQL Horizontal Scaling: Sharded Mimari Rehberi rehberimiz detaylı incelemeyi içerir.

PostgreSQL Sharding 2026: Horizontal Scaling Standardının Olgunlaşması

PostgreSQL sharding, büyük tabloları birden fazla worker node’a bölerek horizontal ölçeklenmeyi sağlayan yaklaşımdır. Citus Data 2025 raporuna göre 10TB+ veri büyüklüğüne ulaşan kurumsal PostgreSQL deployment’larının %58’inde sharding stratejisi devrede. Stack Overflow Developer Survey 2025 verisi PostgreSQL’in en sevilen veritabanı olarak art arda 7. yılına girdiğini, kurumsal benimsemenin %44’e ulaştığını gösteriyor.

Geleneksel olarak PostgreSQL vertical scaling (büyük makine) ile çözülürdü; ancak 64+ core, 1TB+ RAM makineler için bile 10TB+ veri büyüklüğü ve 50.000+ concurrent connection senaryolarında darboğaz oluşuyor. Citus, pg_shard ve native partition’lar bu noktada devreye giriyor. IDC 2025 Cloud Database raporu, sharding sonrası kurumsal PostgreSQL maliyetlerinin %44 azaldığını, p99 sorgu süresinin %63 iyileştirildiğini belgeliyor.

Range vs Hash vs Geographic Sharding: Mimari Boyut

Sharding stratejisi olarak üç ana yaklaşım var. Range-based sharding, bir aralık (örneğin A-M, N-Z) üzerinden verileri bölüyor; range query’lerde verimli, ancak hot range riski yüksek. Hash-based sharding, shard key’in hash’ine göre uniform dağılım sağlıyor; en yaygın, hot spot riski düşük, range query’leri yavaş. Geographic sharding, kullanıcı bölgesine göre veriyi pinleyip yerel erişim hızlandırıyor; GDPR/KVKK uyumu için pratik.

Karşılaştırma: Shard Anahtarı Seçim Kuralları

Sharding başarısının %80’i doğru shard anahtarı seçimine bağlı. Yanlış anahtar seçildiğinde 6 ay sonra rebalancing baskısı kaçınılmaz. Citus 2025 best practice rehberi şu kriterleri öneriyor: yüksek kardinalitesi olan kolon, sorguların büyük çoğunluğunda WHERE clause’da geçen kolon, JOIN’lerde co-location sağlayan kolon, ve evolution baskısı olmayan stabil kolon.

• Multi-tenant SaaS: tenant_id sharding key (her tenant’ın verileri aynı shard’da).
• Time-series: time veya time + entity_id composite key.
• E-ticaret: user_id veya customer_id (siparişler, sepet aynı shard’da).
• Geographic: country veya region_code (regional shard’lara pin).
• Anti-pattern: low cardinality kolonlar (status, type) — uniform dağılım imkansız.
• Anti-pattern: sık değişen kolonlar — shard movement maliyeti yüksek.

İlgili konu: PostgreSQL performans rehberimizde sharding pattern’leri ele alındı.

Citus Cluster Topology: Implementation Pattern

Citus, PostgreSQL’i transparently sharding eden popüler extension. Cluster topology bir ‘coordinator’ node ve N tane ‘worker’ node’dan oluşuyor. Coordinator query’leri parse eder, hangi worker’lara dağıtacağını planlar, sonuçları aggregate eder. Workerlar gerçek veriyi tutar ve local query’leri executes eder. Citus 12 ile multi-coordinator high availability ve schema-based sharding (bir schema her shard’da farklı) özellikleri eklendi.

Operasyon, Online Rebalancing ve Hot Spot Yönetimi

Kurumsal sharding operasyonel olgunluğun en zorlu boyutu rebalancing ve hot spot yönetimi. Citus online rebalancing özelliği sayesinde shard’lar live trafiğe rağmen başka worker’lara taşınabiliyor; bu işlem 100GB shard için ortalama 8-15 dakika sürüyor. Hot spot tespiti için Citus’un built-in dashboardu CPU, IOPS ve query frequency metric’leriyle hangi shard’ın overload olduğunu gösteriyor.

Sektörel Use Case’ler: Multi-Tenant SaaS, Time-Series, E-Ticaret

Multi-tenant SaaS’larda tenant_id sharding key olarak kullanıldığında her tenant’ın izole bir veri partition’ı oluyor; bu hem performans hem compliance açısından avantajlı. Türkiye’de bir B2B SaaS şirketinde 4.500 tenant Citus üzerinde tenant_id sharded; ortalama p99 sorgu süresi 1.200ms’den 85ms’ye indi. Time-series senaryolarda IoT sensor verileri time + device_id ile sharded; aylık 50 milyar event toplam 14 worker üzerinde dağıtılıyor. E-ticaret platformlarında user_id sharding, kullanıcı sipariş geçmişi sorgularını tek shard’da tutuyor.

Kurumsal PostgreSQL Sharding Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• Vertical scaling sonuna kadar zorlanmadan erken sharding’e geçiş — gereksiz karmaşıklık.
• Yanlış shard anahtarı seçimi — 6 ay sonra rebalancing baskısı.
• Reference tablo’ların replication’a alınmaması — her cross-shard JOIN yavaş.
• Cross-shard transaction ihtiyacının atlanması — 2PC overhead’i sürpriz oluyor.
• Coordinator HA setup’ının atlanması — single point of failure.
• Schema migration’ların shard’lar arası senkronizasyon politikasının olmaması.

Sonuç

PostgreSQL sharding kararı geri dönüşü pahalı bir mimari yatırımdır; doğru shard anahtarı seçimi ve operasyonel olgunluk olmadan beklenmedik şekilde maliyet artışı yaratabiliyor. Citus, Vitess ve YugabyteDB kurumsal PostgreSQL sharding ekosisteminin liderleri; her birinin farklı sweet spot’u var. Citus PostgreSQL extension olarak transparent, Vitess MySQL kökenli ancak PostgreSQL desteği büyüyor, YugabyteDB distributed SQL native. Önce vertical scaling + read replica + partitioning ile dikey ölçeklemeyi sonuna kadar zorla; gerçekten gerekirse Citus + hash sharding ile başla. Detaylı kaynak için Citus Blog, PostgreSQL Wiki ve IDC Cloud Database Reports incelenmelidir.

Sıkça Sorulan Sorular