PostgreSQL Partitioning: Range, List, Hash ve Üretim Pratiği 2026

Postgres partitioning, tek bir mantıksal tabloyu fiziksel olarak birden fazla küçük tabloya bölerek sorgu planlayıcısının yalnızca ilgili partition’ları taramasına izin veren native bir bölümleme katmanıdır. PostgreSQL 17 (Eylül 2024) ile birlikte declarative partitioning artık 1 milyar satıra kadar olan OLTP tablolarında DBA müdahalesi olmadan sürdürülebilir hale geldi; merge/split partition komutları, generated kolonlarla partition key ve ALTER TABLE ... DETACH PARTITION CONCURRENTLY gibi operasyonel iyileştirmeler 200 GB üstü tabloların bakım maliyetini ölçülebilir şekilde düşürdü. Bu yazıda Range, List ve Hash partitioning stratejilerini gerçek üretim senaryoları, performans rakamları ve bakım otomasyonu üzerinden karşılaştırıyoruz.

2025 Stack Overflow Developer Survey’inde PostgreSQL profesyonel kullanıcılar arasında %49 oranıyla en çok kullanılan veritabanı olarak MySQL’in önüne geçti; Percona’nın 2024 Open Source Database raporuna göre bu kullanıcıların yaklaşık %38’i 100 GB üzeri tablolarda partitioning kullanıyor. Yanlış kurgulanmış bir partition şeması ise tam tersini yapar: planner overhead, lock kuyrukları ve constraint exclusion eksikliği nedeniyle sorgular bölümsüz tabloya göre 2-4x yavaşlayabilir.

PostgreSQL Partitioning Mimarisi ve Çalışma Prensibi

Declarative partitioning PG 10 (2017) ile geldi, üretim olgunluğuna PG 13 (parallel scan) ve PG 14 (detach concurrently) ile ulaştı. Parent tablo şablondur, veri yalnızca leaf partition’larda saklanır. Planner WHERE cümlesindeki sabit ifadelerle partition constraint’lerini karşılaştırıp eşleşmeyen partition’ları “partition pruning” ile devre dışı bırakır; PG 12’den sonra eliminasyon execution anında, prepared statement parametreleriyle de çalışıyor.

Bir tabloyu partition’lamak için PARTITION BY RANGE/LIST/HASH (column) kullanılır. Her partition kendi tablespace, index ve autovacuum ayarlarıyla yaşar. PostgreSQL global index’i desteklemediği için her partition’ın index’i lokal olur; bu, partition drop’u O(1) yaparken, partition key’i içermeyen unique constraint’i imkansız kılar. PG 17’nin pratik kazanımları: MERGE artık partition’lı tablolarda incremental sort ile çalışıyor, SPLIT/MERGE PARTITION DBA müdahalesini azalttı, streaming replication’da partition attach/detach logical decoding’i kırmıyor. PostgreSQL 17 resmi dokümantasyonu en güncel referans.

Range Partitioning: Zaman Serileri ve Sıralı Veri

Range partitioning, partition key’in sürekli bir aralıkta dağıldığı senaryolarda kullanılır. En yaygın örnek zaman serileridir: log tabloları, event store, finansal işlemler, IoT telemetrisi. Her partition belirli bir tarih aralığını kapsar (ör. aylık veya günlük). Sorguların büyük çoğunluğu son N gün/ay üzerinde çalıştığı için planner eski partition’ları otomatik eler.

Örnek: events tablosu günde 50M satır alıyor, retention 90 gün. Tek tabloda 4.5 milyar satır, 1.2 TB. Aylık range ile (3 aktif + 1 default) her partition ~400 GB; WHERE created_at >= now() - interval '7 days' tek partition’a iniyor. Non-partitioned tabloda 8-12 saniye süren sorgu, range partition + BRIN index ile 180-320 ms’e düşüyor — yaklaşık 30x hızlanma.

Senaryo	Tablo boyutu	Partition stratejisi	Partition sayısı	Tipik sorgu latency	Bakım modu
Application log	1.5 TB	Range (daily)	30-90	50-150 ms	pg_partman daily rotation
IoT telemetri	3.2 TB	Range (weekly)	52-104	120-280 ms	TimescaleDB hypertable
Finansal işlemler	800 GB	Range (monthly)	36 (3 yıl)	80-200 ms	Manuel partman + S3 archive
Audit trail	600 GB	Range (monthly)	84 (7 yıl)	200-400 ms	pg_partman + cold tablespace
Metrics (Prometheus benzeri)	2.1 TB	Range (hourly)	720 (30 gün)	30-80 ms	Auto-drop after 30d

Range partitioning’i tercih ettiğiniz durumlar:

• Ne zaman seç: Sorguların %80+’i belirli bir tarih/sayı aralığında, retention politikası açık, partition drop ile arşivleme gerekiyor.
• Avantaj: Partition pruning neredeyse her sorguda devreye girer; eski partition’ı DROP TABLE ile silmek DELETE‘e göre 100-1000x hızlı.
• Dezavantaj: Hot partition problemi — son partition’a tüm yazma yükü düşer. Eşit dağılım için sub-partitioning (range + hash) gerekebilir.
• Üretim tuzağı: Default partition kullanıyorsanız ve veri default’a düşerse, default partition büyür ve constraint exclusion çalışmaz. Mutlaka monitoring kurun.

TimescaleDB, range partitioning üzerine kurulu bir extension’dır ve hypertable kavramıyla otomatik chunk yönetimi sağlar. Saf PostgreSQL kullanıyorsanız pg_partman standart araçtır; partman.create_parent fonksiyonu ile retention, premake (önceden oluşturma) ve infinite_time_partitions parametreleri tanımlanır.

List Partitioning: Kategorik ve Tenant-Bazlı Veri

List partitioning’de partition key sonlu ve sayılabilir bir değer kümesinden seçilir: ülke kodu, tenant_id, region, environment, sektör. Her partition belirli değerlerin listesini barındırır. Multi-tenant SaaS uygulamalarında yaygın bir desendir — her büyük müşteri kendi partition’ında izole edilir, küçük müşteriler bir DEFAULT partition’da toplanır.

Örnek: 12.000 tenant’lı bir B2B SaaS. En büyük 50 tenant veri hacminin %78’ini oluşturuyor. List partitioning ile bu 50 tenant kendi partition’ına alındı, geri kalan 11.950 default’ta. API isteklerinin %92’si tek tenant’a iniyor; p99 latency 420 ms’den 95 ms’ye indi. AWS RDS blog’undaki 2024 vaka çalışmaları benzer oranları onaylıyor.

Kriter	Range	List	Hash
Partition key tipi	Sıralı (date, int range)	Kategorik (enum, id)	Herhangi (hash function)
Pruning etkisi	Çok yüksek (WHERE range)	Yüksek (WHERE =/IN)	Yüksek (WHERE =)
Veri dağılımı	Eşitsiz (zaman bazlı)	Eşitsiz (skew olası)	Eşit (deterministik)
Partition ekleme	Yeni aralık tanımla	Yeni değer listesi	Modulus değişir (zor)
Tipik kullanım	Log, IoT, finans	Multi-tenant, region	User-id, order-id, eşit yük
Partition sayısı (önerilen)	30-300	10-200	4-64
Default partition	Önerilir	Önerilir	Anlamsız

List partitioning’de kritik bir karar: hangi tenant kendi partition’ında yaşayacak? Bir kural: tenant’ın veri hacmi toplam tablonun %1’ini aştığında veya günlük 100 GB sorgu okuması üretiyorsa ayrı partition. Bu karar verisi için pg_stat_user_tables ve pg_stat_statements üzerinden tenant-bazlı analiz gerekir. Multi-tenant veri mimarisinde bu tür ince ayarlar, daha geniş veri mesh mimarisi tartışmasının da bir parçası.

Hash Partitioning: Eşit Dağılım ve Yatay Ölçek

Hash partitioning, partition key’i deterministik bir hash fonksiyonuyla (PG’de hashextended) modulo N’e indirir ve veriyi N partition’a yaklaşık eşit dağıtır. Range/list ile mantıklı bir bölme yoksa veya hot partition probleminin önüne geçilmek isteniyorsa tercih edilir. Tipik örnekler: user_id ile kullanıcı oturum tabloları, order_id ile sipariş kalemleri. Hash partition sayısı genelde 2’nin katı seçilir (4, 8, 16, 32); modulus değişirse tüm veri yeniden dağılacağı için başlangıçta kapasitenin 2-4 katı partition açmak yaygındır.

• Ne zaman seç: Doğal bir range/list ayrımı yok; tek istek yazma yükünün ve sorgu yükünün partition’lara eşit dağılması.
• Avantaj: Hot partition yok, autovacuum yükü dengeli, parallel query 8-32 partition’da near-linear ölçekleniyor.
• Dezavantaj: Range sorguları (örn. WHERE user_id BETWEEN 1000 AND 5000) tüm partition’ları okur — pruning yok.
• Üretim tuzağı: Partition sayısını sonradan artırmak ZOR. Veri taşımak için pg_repack + logical replication kombosu gerekir, 1 TB tablo için tipik downtime 4-8 saat.

Citus extension (Microsoft 2019’da satın aldı) hash partitioning’i shard’lara eşleyerek distributed PostgreSQL sağlar. Single-node’da saf hash partitioning yeterli; horizontal scale gerekiyorsa Citus veya Yugabyte değerlendirilir. Microsoft Learn distributed PostgreSQL dokümantasyonu Citus mimarisini detaylandırır.

Sub-Partitioning ve Composite Stratejiler

Tek bir strateji her zaman yeterli değil. Yaygın composite desen range + hash: önce zamanla range’le (aylık), sonra her aylık partition’ı user_id’ye göre 8 hash sub-partition’a böl. Bu hem retention için DROP PARTITION kolaylığı sağlar hem de aktif aydaki yazma yükünü 8 tabloya dağıtır.

Composite desen	Üst düzey	Alt düzey	Senaryo örneği	Tipik partition adedi
Range + Hash	Range (monthly)	Hash (user_id, 8)	SaaS event store	36 ay × 8 = 288
List + Range	List (region)	Range (date, monthly)	Multi-region log	5 region × 24 ay = 120
Range + List	Range (yearly)	List (country)	Compliance / GDPR ayrıştırma	5 yıl × 27 ülke = 135
Hash + Range	Hash (tenant, 16)	Range (date, weekly)	Yüksek tenant skew	16 × 52 = 832
List + Hash	List (environment)	Hash (id, 8)	Prod/Stage/Dev izolasyon	3 × 8 = 24

Composite partitioning planner overhead’i artırır. 500 partition üzerinde planlama maliyeti ölçülebilir hale gelir; EXPLAIN ANALYZE ile planning time izlenmeli ve enable_partition_pruning, enable_partitionwise_join, enable_partitionwise_aggregate parametreleri açık tutulmalı. PostgreSQL Wiki’nin tuning sayfası 1.000 partition’a kadar production-safe olduğunu, ötesinde planning time’ın hızla bozulduğunu belirtiyor. WHERE tek bir partition’a iniyorsa 5.000 partition bile sorun değil; ama her sorgu 100+ partition tarıyorsa planner overhead 50-200 ms eklenir — “daha çok partition daha hızlı” yanılgısı yaygındır.

Index, Constraint ve Foreign Key Davranışı

PostgreSQL’de partition’lı tabloda global index yoktur. Parent tabloda tanımlanan her index, fiziksel olarak her partition’da ayrı bir index oluşturur. PostgreSQL 11 ile parent index tanımlanabilir hale geldi (CREATE INDEX ON parent tüm child’lara propagate eder), ama unique constraint hâlâ partition key’i içermek zorundadır. Bu kısıt, çoğu uygulama için ciddi tasarım kararıdır.

Pratik sonuç: orders tablosunu created_at ile range partition’larsanız, order_number üzerinde global unique constraint kuramazsınız. Çözümler: (1) UNIQUE (order_number, created_at) composite PK, (2) uygulama katmanında uniqueness (UUID v7), (3) ayrı bir order_numbers deduplication tablosu. Seçim, sonraki 5 yıllık veri modeline kalıcı etki eder.

Constraint tipi	Partition’da davranış	Üretim notu
PRIMARY KEY	Partition key’i içermeli	Composite PK zorunlu hale gelir
UNIQUE	Partition key’i içermeli	Cross-partition unique mümkün değil
FOREIGN KEY (out)	Çocuktan dışarı: serbest	Normal davranır
FOREIGN KEY (in)	Dışarıdan partition’a: PG 12+ destekli	Performans cezası 5-15%
CHECK	Parent’ta tanımlanır, child’a iner	Constraint exclusion için kritik
EXCLUDE	Partition key gerekli	Nadiren kullanılır
NOT NULL	Parent’tan miras	Sorun yok

Index bakımı: REINDEX CONCURRENTLY PG 12’den itibaren partition’lı tablolarda her partition için ayrı çalıştırılır. Otomasyon için pg_repack kullanılır; 50 GB üzeri index için reindex 30-90 dakika sürer, rolling reindex gece pencerelerinde planlanmalı. PostgreSQL performans optimizasyonu yazımız index ve vacuum tuning’i daha geniş ele alıyor. Foreign key’in partition’lı tabloya gelmesi PG 12’den beri destekleniyor; her referans, fiziksel olarak her partition’a karşı bir constraint oluşturduğu için INSERT/UPDATE’lerde 5-15% ek maliyet üretir. Yüksek throughput’ta FK’yi uygulama katmanına taşımak yaygın bir trade-off.

pg_partman ile Otomatik Partition Yönetimi

Manuel partition yönetimi sürdürülemez. pg_partman, Crunchy Data’nın sürdürdüğü üretim standardı extension. Üç görevi otomatize eder: premake (gelecek partition’ları önceden oluşturur), retention (eski partition’ları drop/detach eder), maintenance (yeniden organize eder). GitHub’da 2.000+ star; Crunchy Bridge ve AWS RDS dahil çoğu managed PostgreSQL servisinde mevcut.

Tipik üretim konfigürasyonu:

1. partman.create_parent fonksiyonu ile tablo kaydedilir: partition tipi (range/list), interval (daily/monthly/numeric), premake değeri (gelecekteki kaç partition).
2. partman.run_maintenance_proc() bir cron job veya pg_cron extension’ı ile saatte veya günde bir tetiklenir.
3. retention parametresi ile (örn. ’30 days’ veya ’12 months’) eski partition’lar otomatik drop edilir veya bir retention_schema‘ya taşınır.
4. infinite_time_partitions aktifse partman, takvim doğrultusunda sürekli yeni partition üretir; deaktifse veriye göre tetiklenir.
5. Failure modunda partman partition oluşturamazsa default partition’a düşülür — bu durumun monitoring’i kritik.

İyi yapılandırılmış pg_partman setup’ı DBA müdahalesi olmadan yıllarca çalışır; kötü yapılandırılmışı (premake düşük, retention agresif) Pazar gecesi 03:00 alarmı üretir. Üretim ipucu: premake en az 4, retention drop yerine detach + archive_command + S3/MinIO hedef. Bu pattern big data işleme mimarisinin sıcak/soğuk katmanlarını da besler.

pg_partman alternatifleri: TimescaleDB hypertable (zaman serileri için kompresyon dahil paket), Citus (distributed shard yönetimi), Crunchy PG Operator (Kubernetes native). Seçim, runtime’ın bare metal/RDS/K8s olmasına ve operasyon ekibinin kapasitesine bağlı. Ömer Önal’ın 2025’te bir fintech için yaptığı danışmanlık projesinde pg_partman + pg_cron + custom retention webhook kombinasyonu, 2.4 TB’lık transaction tablosunda yıllık 12.000 USD’lik DBA maaş maliyetini ortadan kaldırdı.

Migration: Var Olan Bir Tabloyu Partition’a Çevirmek

Yeni bir proje partition’lı doğar; ama çoğu zaman 500 GB, 2 TB hatta 8 TB büyümüş bir tabloyu partition’a geçirmek gerekir. Bu işlem PostgreSQL’de native bir ALTER TABLE ... PARTITION komutu olmadığı için manuel veya yarı-otomatik yapılır. 2024-2026 arası standart yaklaşım üç yol:

Yöntem	Downtime	Ekstra disk	Karmaşıklık	Ne zaman uygun
CREATE TABLE LIKE + COPY	Tablo size’a göre 1-12 saat	2x	Düşük	<200 GB, maintenance window var
pg_partman partition_data_proc	Düşük (incremental)	~1.5x	Orta	200 GB – 2 TB, online geçiş
Logical replication (subscriber side partitioned)	Yakın-sıfır (cutover < 1 dk)	2x geçici	Yüksek	>1 TB, 24/7 sistem
pg_repack + custom triggers	Orta (saatler)	2x	Yüksek	FK ağırlıklı, kritik integrity
Citus undistribute_table tersine	Distributed → single	Değişken	Çok yüksek	Citus’tan saf PG’ye dönüş

Logical replication yaklaşımı en popüler olanı. Adımlar: (1) target tabloyu partition’lı şemada oluştur, (2) source tablodan publication aç, (3) target’ta subscription kur, (4) initial sync tamamlanınca application traffic’i cutover et. Cutover anında writes durmalı (bayrak/feature flag ile), son LSN beklenmeli, sonra DNS/connection string değişir. AWS DMS, Striim ve native pglogical bu işi destekler. Stream processing pipeline’larında benzer cutover desenleri yaygındır.

Migration’da en sık karşılaşılan hata: sequence’ların unutulması. Source BIGSERIAL sequence değeri partition’lı tabloya kopyalanmazsa, cutover sonrası ilk INSERT primary key çakışmasıyla patlar. Pre-cutover checklist: sequence currval sync, FK reference doğrulama, autovacuum settings kontrol, monitoring dashboard’ları yeni partition isimleriyle güncelleme.

Performance: Pruning, Parallel Scan ve Partitionwise Join

Partitioning’in performans kazancı üç mekanizmadan gelir: (1) partition pruning — planner ilgisiz partition’ları eler, (2) parallel partition scan — farklı partition’lar paralel okunur, (3) partitionwise join — iki partition’lı tablonun join’i partition-by-partition yapılır. Bu üçü doğru kombine edildiğinde, 1 TB tabloda 50 GB-2 TB arası tabloda lineerin altında ölçeklenen sorgular elde edilir.

Sorgu deseni	Pruning	Parallel scan	Partitionwise join	Tipik kazanç
WHERE date = ‘2026-05-01’	Tek partition	Yok	—	10-50x
WHERE date BETWEEN …	3-5 partition	Var	—	5-20x
GROUP BY tenant_id	Yok (hash)	Var	—	3-8x
JOIN aynı partition key	Var	Var	Var	4-12x
JOIN farklı partition key	Yok	Var	Yok	1-2x (sınırlı)
Cross-partition aggregate	Yok	Var	—	2-5x

enable_partitionwise_join ve enable_partitionwise_aggregate PostgreSQL’de varsayılan kapalıdır; planning time artışı küçük sorgularda net kazanç bırakmayabilir. Üretim önerisi: OLAP/raporlama’da açın, OLTP’de kapalı bırakın. Karma workload için PgBouncer ile workload-specific connection pool yaygın bir desen.

Benchmark referansı: PostgreSQL Wiki partition sayfası ve EnterpriseDB’nin 2024 raporu, 16 partition’lı 500 GB tabloda enable_partitionwise_aggregate‘i açmanın GROUP BY sorgularını ortalama 6.2x hızlandırdığını, ancak planning time’ı 8 ms’den 24 ms’ye çıkardığını gösteriyor. Sub-100ms hedefi olan API’lerde bu trade-off hassas hesaplanmalı. Lakehouse mimarileri ile karşılaştırma için data lakehouse Databricks Snowflake yazımız analytical workload’lar için Postgres dışındaki seçenekleri tartışıyor.

Üretim Tuzakları ve Anti-Pattern’lar

Partitioning bir gümüş kurşun değildir. Yanlış uygulandığında sorunları çözmek yerine derinleştirir. Aşağıdaki anti-pattern’ler, danışmanlık projelerinde tekrar tekrar karşılaşılanlardan:

• Partition sayısı şişmesi: 10.000 partition’lı tablo “neden olmasın” diye açılır; planning time 200-800 ms’e çıkar, autovacuum sürekli yetişemez, pg_class şişer. 1.000 partition pratik tavandır.
• Yanlış partition key: Sorguların %70’i user_id üzerinden ama tablo created_at ile range’lenmiş — pruning hiç çalışmıyor. Anlamlı pruning’siz partitioning sadece overhead’tir.
• Default partition’ın büyümesi: List partitioning’de tanımlanmamış değerler default’a düşer; default 100 GB’a varır, pruning bozulur. Mutlaka monitoring + alert.
• Unique constraint çakışması: Partition key’i içermeyen unique constraint mümkün değil. Bu erkenden anlaşılmazsa, geç dönemde 2-4 haftalık migration borcu oluşur.
• Cross-partition update: PG 11 öncesinde partition’lar arası UPDATE yasaktı; bugün destekleniyor ama 3-5x daha pahalı. Partition key güncellenen senaryolarda yeniden tasarım gerekir.
• Vacuum yetmiyor: Her partition’ın kendi autovacuum threshold’ı vardır. Default ayarlarla 100 partition’lı tabloda vacuum işçiliği IO’yu doyurabilir. autovacuum_max_workers ve autovacuum_vacuum_cost_limit tuning şart.

Karar checklist’i: (a) tablo >100 GB veya >200M satır mı, (b) sorguların %70+’i bir kolon üzerinden filtreliyor mu, (c) retention politikası açık mı, (d) FK/unique constraint’lere uygun mu, (e) ekip pg_partman/pg_cron’u biliyor mu? Beş “evet” ise ROI pozitif. İkiden fazla “hayır” varsa önce index strategy, vacuum tuning ve sorgu optimizasyonu denenmeli.

Sıkça Sorulan Sorular (SSS)

Sonuç

PostgreSQL partitioning, 100 GB altındaki tablolar için gereksiz bir karmaşıklık, 500 GB üzerindekiler için kaçınılmaz bir araçtır. Range, List ve Hash stratejilerinin her biri belirli sorgu desenlerine ve veri dağılımlarına göre tasarlanmıştır; doğru seçim, yanlış uygulandığında performansı bozma riski olan bu mimarinin getirdiği 5-50x kazançları ortaya çıkarır. PG 17 ile gelen MERGE/SPLIT partition desteği, declarative partitioning’i artık üretim olgunluğunun ötesine taşıdı; pg_partman + pg_cron kombinasyonu standart otomasyon katmanını sağlıyor.

Karar çerçevesi şudur: önce sorgu desenlerini ölç (pg_stat_statements), sonra veri dağılımını analiz et, ardından retention politikasını netleştir. Bu üç girdi olmadan partition stratejisi seçmek tahmindir — ve yanlış tahmin, 6-18 ay sonra ya migration borcu ya da performans regresyonu olarak geri döner. Composite stratejiler (range+hash) yaygın olsa da gereksiz katmanlama planning overhead’i tetikler; “olabildiğince basit, ama daha basit değil” prensibi burada da geçerlidir.

Üretim ortamında 1 TB üzeri bir PostgreSQL tablosunu partition’a geçirmeyi planlıyor, mevcut bir partition setup’ında performans veya bakım sorunları yaşıyorsanız, iletişim formundan ulaşarak ortamınıza özgü bir mimari değerlendirme talep edebilirsiniz; sorgu desenleriniz, retention gereksinimleriniz ve operasyon ekibinizin kapasitesi ışığında range/list/hash kararını birlikte netleştiririz.