PostgreSQL Temporal Tables: History Tracking ve Audit Trail 2026

Postgres temporal tablolar, bir satırın yaşam döngüsündeki her değişikliği zaman damgalı şekilde saklayarak “geçmişte X anında bu kayıt neydi?” sorusuna deterministik cevap üretir. PostgreSQL 17 çekirdeği henüz SQL:2011 standardındaki FOR SYSTEM_TIME sözdizimini native desteklemese de, tstzrange tipindeki sys_period kolonu, exclusion constraint ve temporal_tables uzantısının versioning() trigger’ı ile production’da denenmiş bir history tracking pattern’i mevcuttur. Bu yazı; SOX, GDPR Article 30 ve KVKK Madde 12 denetim yükümlülüklerini karşılayan bir audit trail mimarisini, gerçek benchmark rakamlarıyla, alternatiflerle (logical decoding, Debezium CDC, pgAudit, row trigger CDC) karşılaştırarak anlatıyor.

2025 Stack Overflow Developer Survey, PostgreSQL’i %49 kullanım oranıyla profesyonel geliştiriciler arasında en popüler ilişkisel veritabanı olarak gösterdi; bu oran 2022’deki %46’dan yükselerek MySQL’in (%38) üzerine çıktı. Aynı dönemde regülatörler de aktifleşti: ENISA’nın 2024 Threat Landscape raporu, denetim izi (audit trail) eksikliğini finans ve sağlık sektörlerinin en çok rapor ettiği uyum açığı olarak listeledi. Doğru kurulan temporal tablo şeması, hem forensic analiz hem de “right to be forgotten” gibi GDPR taleplerini soft-delete + cryptographic erase ile birleştirerek tek bir veri katmanında çözebilir.

Temporal Veritabanı Modelleri ve PostgreSQL’in Konumu

SQL:2011 standardı üç temporal kategori tanımlar: system-versioned (DBMS otomatik versiyonlar), application-time (iş tarihleri, örn. sözleşme geçerlilik aralığı) ve bitemporal (her ikisinin birleşimi). SQL Server 2016, MariaDB 10.3, Oracle Flashback ve DB2 system-versioned tabloları yerel destekler. PostgreSQL’de bu işlev üçüncü taraf araçlarla sağlanır; ancak tstzrange, GiST index ve exclusion constraint kombinasyonu standardın semantiğine eşdeğer sonuç verir.

RDBMS	System-Versioned	Application-Time	Bitemporal	Standart Söz Dizimi
SQL Server 2016+	Native	Manuel	Manuel	Kısmi (FOR SYSTEM_TIME)
MariaDB 10.3+	Native	Native	Native	SQL:2011 tam
Oracle 12c+ Flashback	Native (UNDO)	Valid Time	Native	Tam
IBM DB2 10+	Native	Business Time	Native	Tam
PostgreSQL 17 + temporal_tables	Extension	Extension/manuel	Extension	Yok (range tipi)
MySQL 8.x	Yok	Yok	Yok	Yok

PostgreSQL ekosisteminde dört dominant yaklaşım var: (1) Vlad Arkhipov’un temporal_tables uzantısı (C tabanlı versioning() trigger), (2) saf SQL trigger ile manuel history tablosu, (3) logical decoding + Debezium ile event sourcing, (4) pgAudit ile log-only audit. Her birinin yazma overhead’i, sorgu ergonomisi ve operasyonel yükü farklı.

temporal_tables Uzantısı ile Sistem Versiyonlama

Uzantı, PgPro ve community PGXN dağıtımında bulunur. Kurulum sonrası ana tabloya sys_period tstzrange NOT NULL DEFAULT tstzrange(current_timestamp, null) kolonu eklenir, paralel history tablosu oluşturulur ve BEFORE INSERT OR UPDATE OR DELETE trigger’ı versioning('sys_period', 'orders_history', true) argümanlarıyla bağlanır. Trigger her UPDATE’te eski satırı history tablosuna sys_period = tstzrange(eski_baslangic, current_timestamp) şeklinde yazar; ana tablodaki yeni satır açık aralıkla devam eder.

2024 yılında PostgreSQL Person of the Year seçilen geliştirici Andrew Atkinson’ın benchmark çalışmasında, pgbench tabanlı sentetik yüke karşı versioning() trigger’ı INSERT için yaklaşık %4, UPDATE için %18-22 ek yazma overhead’i ölçüldü (8 vCPU, 32 GB RAM, NVMe SSD; 64 concurrent client). Bu rakamlar Debezium CDC ile karşılaştırıldığında düşük; çünkü trigger inline çalışıyor, asenkron stream’e gerek yok.

Yaklaşım	INSERT overhead	UPDATE overhead	DELETE overhead	Disk amplification	Sorgu ergonomisi
temporal_tables extension	~4%	~20%	~25%	2.1x	İyi (range @>)
Manuel SQL trigger	~3%	~17%	~22%	2.0x	Orta
Logical decoding + Debezium	~1%	~3%	~3%	Eksternal (Kafka)	Düşük (replay gerek)
pgAudit (sadece log)	~0.5%	~1%	~1%	Disk log büyür	Çok düşük (text)
WAL archive + PITR	~0%	~0%	~0%	WAL bagajı	Sadece restore

“X anında bu satır neydi?” sorgusu uzantı ile şu şekilde yazılır: SELECT * FROM orders_history WHERE order_id = 42 AND sys_period @> '2026-03-14 09:00:00+03'::timestamptz UNION ALL SELECT * FROM orders WHERE order_id = 42 AND sys_period @> '2026-03-14 09:00:00+03'::timestamptz;. GiST index sys_period üzerinde USING gist (order_id, sys_period) şeklinde tanımlandığında, 50 milyon history satırında nokta sorgusu p95 latency 6.4 ms civarında kalıyor (community benchmarks, 2025).

Bu mimari hakkında daha derinlemesine bir parametre ayarlama rehberi için PostgreSQL Performans yazısında shared_buffers, effective_cache_size ve wal_compression önerileri bulunur; temporal yük altında wal_compression = lz4 WAL hacmini ortalama %35 düşürüyor.

Range Tipleri, Exclusion Constraint ve Çakışma Engelleme

Application-time temporal modelde aynı entity için zaman dilimlerinin örtüşmemesi kritik. Klasik örnek: bir çalışanın aynı anda iki farklı departmana atanmaması. PostgreSQL EXCLUDE USING gist constraint’i, btree_gist uzantısıyla birleştirildiğinde bu garantiyi DDL seviyesinde verir.

CREATE EXTENSION IF NOT EXISTS btree_gist;
CREATE TABLE employee_assignment (
  employee_id BIGINT NOT NULL,
  department_id BIGINT NOT NULL,
  valid_period TSTZRANGE NOT NULL,
  EXCLUDE USING gist (employee_id WITH =, valid_period WITH &&)
);

&& operatörü iki range’in kesişip kesişmediğini test eder. INSERT denemesi çakışma yaratırsa Postgres conflicting key value violates exclusion constraint hatasıyla rollback yapar. Bu pattern, sözleşme yönetimi, fiyat geçerlilik dönemleri, vardiya çizelgesi, abonelik faturalama gibi senaryolarda sezgisel.

Range operatörlerinin tamamı kritik:

• @> — Range bir noktayı içeriyor mu? (Nokta-zaman sorgusu için ana operatör.)
• && — İki range kesişiyor mu? (Çakışma engelleme.)
• -|- — Bitişik mi? (History compaction’da kullanılır.)
• lower(range) / upper(range) — Sınır değerleri çıkarır.
• range_agg() — PostgreSQL 14+, ardışık range’leri birleştirir (downtime hesabı için ideal).

Audit Trail Tasarımı: Kim, Ne Zaman, Neden

SOX Section 404, ISO 27001 Annex A.12.4 ve KVKK VERBİS yükümlülükleri “kim erişti, ne değişti, hangi yetkiyle” sorularına izlenebilir cevap ister. Sadece veri snapshot’ı yetmez; actor, session_id, ip, application_name ve değişimin nedeni (ticket numarası, JIRA referansı) history tablosuna kolon olarak eklenmeli. Bunun için SET LOCAL "audit.user" = '[email protected]' oturum değişkeni trigger içinde current_setting('audit.user', true) ile okunur.

Audit Alan	Kaynak	Regülasyon	Saklama Süresi (öneri)
actor_email	SET LOCAL session var	SOX, KVKK m.12	7 yıl
operation (INS/UPD/DEL)	TG_OP	SOX, GDPR Art. 30	7 yıl
session_id	pg_backend_pid() + start_time	NIST SP 800-92	2 yıl
client_ip	inet_client_addr()	ISO 27001	1 yıl
application_name	current_setting(‘application_name’)	Operasyonel	1 yıl
change_reason	SET LOCAL “audit.reason”	SOX (mantık izi)	7 yıl
row_diff_jsonb	hstore_to_jsonb(hstore(NEW)-hstore(OLD))	GDPR Art. 32	7 yıl

row_diff_jsonb kolonu hem disk tasarrufu hem de “sadece amount kolonu değişti, geri kalan 38 alan aynı” tarzı insan-okur diff için pratik. hstore uzantısı ile hstore(NEW) - hstore(OLD) sadece değişen alanları döner; bu pattern özellikle 100+ kolonlu wide tablolarda history büyüme oranını %60-70 düşürür.

Soft Delete, Tombstone ve GDPR Right to be Forgotten

Audit trail’in en büyük çelişkisi: regülatör 7 yıl saklama ister, başka regülatör (GDPR Art. 17) belirli kişisel verinin silinmesini ister. Çözüm cryptographic erase: kişisel kolonlar (email, isim, telefon) bir pgcrypto simetrik anahtarla şifrelenir, anahtar HashiCorp Vault gibi external KMS’te tutulur. Silme talebinde anahtar yok edilir; şifreli veri history’de kalır ama kimse okuyamaz. Audit izi (kim, ne zaman değişti, hangi şemada) bozulmaz.

Tombstone pattern de ayrı bir teknik: ana tabloda deleted_at timestamptz kolonu eklenip soft-delete view’ı (CREATE VIEW orders_active AS SELECT * FROM orders WHERE deleted_at IS NULL) tanımlanır. Trigger DELETE komutunu UPDATE’e çevirir. Bu yaklaşım history tablosuna ek gerektirmez ama “satır gerçekten silindi mi?” sorgusunu kirli yapar. Daha temiz çözüm: temporal_tables ile DELETE’in sys_period kapanışı olarak history’ye taşınması.

CDC Alternatifi: Debezium ve Logical Decoding

Trigger tabanlı history düşük gecikme verir ama yazma path’inde latency ekler. Yüksek throughput OLTP (3000+ TPS) için logical decoding daha uygun. PostgreSQL wal_level = logical ile yapılandırıldığında, pgoutput veya wal2json plugin’i WAL’dan change event akışı üretir. Debezium 2.x bunu Kafka topic’lerine yazar; downstream tüketici (Flink, ksqlDB, Spark Streaming) history tablosunu materialize eder.

Confluent’in 2025 State of Data Streaming raporuna göre, ankete katılan 1500+ veri mühendisinin %38’i CDC pipeline’larında Debezium kullandığını belirtti; PostgreSQL en yaygın kaynak (%54). Trade-off net: Debezium asenkron olduğu için eventual consistency kabul edilmek zorunda; “son 100 ms içindeki değişiklik henüz Kafka’ya akmadı” durumu mümkün. Bu yüzden finansal audit gibi senkron tutarlılık şartı olan use case’lerde trigger pattern hâlâ üstün.

Stream tabanlı history konusunda Stream Processing ve Event-Driven Kafka yazıları kapsamlı; özellikle Kafka topic compaction stratejisi temporal store’un yerini alıp almayacağı sorusunda yol gösterici.

Kriter	Trigger (temporal_tables)	Logical Decoding (Debezium)	WAL Archive + PITR
Yazma latency etkisi	Yüksek (~20%)	Çok düşük (~3%)	Yok
Tutarlılık	Senkron (ACID)	Asenkron (~ms)	Snapshot bazlı
Sorgu kolaylığı	Yüksek (range @>)	Düşük (replay gerek)	Yok (full restore)
Operasyonel yük	Düşük (sadece DDL)	Yüksek (Kafka, Connect)	Orta (backup mgmt)
Forensic değer	Yüksek	Yüksek	Düşük (granüler değil)
Disk maliyeti	~2x ana tablo	Kafka cluster	WAL retention süresi
İyi olduğu senaryo	Audit, regülasyon	Stream analytics	Felaket kurtarma

Bitemporal Modelleme: Sigorta ve Finans Senaryoları

Bitemporal model iki zaman ekseni saklar: valid_time (gerçek dünyada ne zaman geçerliydi) ve system_time (veritabanına ne zaman girildi). Sigorta poliçesi örneği: poliçe 1 Ocak’tan itibaren geçerli olacak şekilde 15 Aralık’ta sisteme girilir; sonra retroaktif olarak 1 Aralık’a alındığı 20 Aralık’ta düzeltilir. “20 Aralık’ta sistem hangi poliçe başlangıcını gösteriyordu?” sorusu sadece bitemporal model ile cevaplanabilir.

PostgreSQL’de bu, iki ayrı tstzrange kolonu (valid_period, sys_period) ve composite GiST index ile kurulur. Allianz, Munich Re ve Türkiye’de bazı reasürans şirketleri 2010’lardan beri DB2 üzerinde bitemporal kullanıyordu; 2024-2026 döneminde PostgreSQL 16+ ile geçiş yapan kuruluşların raporladığı maliyet tasarrufu %40-55 aralığında (lisans + donanım birleşik). McKinsey’nin 2025 “Cloud Cost in Financial Services” raporu, Postgres geçişlerinin TCO etkisini bu band içinde doğruluyor.

• Avantaj: Retroaktif düzeltmeler için cerrahi sorgu imkânı; “şu anda neyi yanlış biliyorduk” raporu.
• Dezavantaj: Şema karmaşıklığı ve sorgu yazımı standart developer için steep learning curve.
• Ne zaman seç: Sigorta, reasürans, türev finansal enstrüman, vergi yeniden değerleme, klinik kayıt.
• Ne zaman kaçın: CRUD-ağırlıklı SaaS, e-ticaret order tablosu, gerçek zamanlı IoT telemetri.

Performans Tuning: Partitioning, Index ve Vacuum

History tabloları ana tablodan 2-5 kat hızlı büyür. 100 milyon satır eşiğini aşan bir history için partitioning zorunlu. PostgreSQL 17 declarative partitioning PARTITION BY RANGE (lower(sys_period)) ile yıllık veya aylık dilimleme yapar; eski partition’lar tablespace olarak ucuz storage’a (örn. NVMe yerine SATA SSD) taşınabilir.

Operasyon	Index’siz (10M satır)	B-tree (sys_period başlangıç)	GiST (sys_period range)	BRIN (timestamp)
Nokta-zaman sorgu (p95)	2200 ms	180 ms	6 ms	320 ms
Aralık sorgu (1 gün, p95)	2400 ms	240 ms	14 ms	110 ms
Index disk boyutu	0	340 MB	620 MB	2.1 MB
INSERT overhead	~0%	~5%	~12%	~1%
Maintenance (REINDEX)	Yok	Düşük	Orta	Çok düşük

BRIN (Block Range INdex) çok büyük zaman-sıralı history için altın standart: 100 GB history tablosunda BRIN index sadece birkaç MB tutar, append-only iş yüklerinde aralık taraması GiST’ten hızlı. Hibrit yaklaşım: aktif (son 90 gün) partition’da GiST, dondurulmuş eski partition’larda BRIN.

autovacuum ayarları temporal yük için yeniden düşünülmeli. autovacuum_vacuum_scale_factor = 0.05 ve autovacuum_vacuum_cost_limit = 2000 önerilen başlangıç noktası. History tablolarında DELETE çok nadir olduğundan vacuum’un asıl işi index bloat’u önlemek; pg_repack uzantısı offline downtime olmadan bloat temizliği yapar (community sürümde, üretimde Aiven, Crunchy, EDB destekli).

Compliance Mapping: SOX, GDPR, KVKK ve Sektörel Standartlar

Düzenleme ile teknik kontrol arasında net eşleme yapılmazsa denetimde “yapısal kontrol var ama izlenebilir kanıt yok” bulgusu çıkar. Aşağıdaki matris en sık karşılaşılan kontrol-kanıt eşleşmesini özetliyor.

Düzenleme	İlgili Madde	Temporal Kontrol	Kanıt Üretimi
SOX	Section 404	Mali tablo kalem değişiklik izi	orders_history + audit kolonları
GDPR	Article 30 (Records of Processing)	Kişisel veri erişim/değişim logu	pgAudit + temporal join
GDPR	Article 17 (Right to Erasure)	Cryptographic erase	pgcrypto + KMS rotation log
KVKK	Madde 12	Veri güvenliği önlemleri kanıtı	Audit raporu, retention politikası
HIPAA	164.312(b)	Audit controls	actor + reason + diff kolonları
PCI-DSS v4	Req. 10	Tüm erişim ve değişiklik logu	WAL + Debezium + SIEM
ISO 27001	Annex A.12.4	Olay kayıtlama	Audit trail integrity check

Audit trail bütünlüğünü kanıtlamak için hash chain pattern’i öneriliyor: history satırına row_hash = sha256(prev_hash || row_content) kolonu eklenir; sonradan müdahale tüm zinciri kırar. NIST SP 800-92 “Guide to Computer Security Log Management” bu yaklaşımı immutable audit log için tavsiye ediyor. PostgreSQL 17’de pgcrypto.digest() ile trigger içinde inline hesaplama mümkün.

Veri yönetişimi katmanında bu izlerin bir Data Catalog içinde lineage olarak görünmesi denetim kolaylığı sağlar; ayrıca Veri Yönetişimi yazısı GDPR-KVKK katalog eşlemesinin kurumsal süreç tarafını detaylandırıyor.

Operasyonel Gotcha’lar ve Production Çıkarımları

Birkaç yıl içinde temporal tablo deploy etmiş ekiplerin paylaştığı tipik tuzaklar:

1. Schema migration sırasında history kopyalanmıyor: Ana tabloya yeni kolon eklenince history tablosuna manuel ALTER şart; aksi halde trigger bir sonraki UPDATE’te hata atar. Liquibase/Flyway script’lerinde --paired-tables notu kritik.
2. Tek transaction’da çok UPDATE → exclusion constraint deadlock’u: Batch işlerde SET CONSTRAINTS ALL DEFERRED ile constraint kontrolü commit’e ertelenir.
3. Replica lag temporal sorguda yanlış cevap: Hot standby okumada current_timestamp primary’den farklı saniye gösterebilir; ms hassasiyetli sorgular için synchronous_commit veya read-from-primary stratejisi.
4. Logical replication ile history tablosu eksik: Publication’a hem ana tablo hem history tablosu eklenmeli; aksi halde subscriber’da audit izi kopuk.
5. Backup boyutu 2x: pg_dump --exclude-table=*_history ile sadece soğuk yedeklere history almayı düşün; cold storage için pg_dump --compress=zstd:19 %75’e kadar küçültür.

Bu kontroller ve trade-off analizi konularında bağımsız bir göz, Ömer Önal‘ın PostgreSQL kapasite planlama ve audit mimarisi danışmanlığında sıkça incelediği başlıklardandır; kurumsal bir dağıtım öncesi mimari review’ı tekrarlanabilir hatalardan korur.

Modern Veri Mimarisinde Temporal Tabloların Yeri

Temporal pattern sadece OLTP audit değil; analitik katmanda da kritik. Slowly Changing Dimension Type 2 (SCD2) modeli warehouse’larda temporal tablonun klasik karşılığı; bir müşteri kaydının “şu tarihten itibaren VIP segmentine geçti” tarihçesi temporal join ile lineer kuruluyor. dbt Analytics Engineering yazısı dbt snapshots özelliğini açıklar; bu özellik tam olarak SCD2’yi temporal-style hidrate eder. Lakehouse ekosisteminde de eşdeğeri var: Iceberg Delta Lake tablo formatları “time travel” özelliği ile snapshot bazlı temporal sorgu sunuyor; PostgreSQL’in row-level granülasyonundan farklı, snapshot bazlı. OLTP’den OLAP’a CDC ile aktarılan veri için, sıcak katman temporal_tables, soğuk katman Iceberg snapshot — sağlıklı bir kombinasyon.

Karar verirken üç eksen birden değerlendirilmeli:

• Tutarlılık ekseni: Senkron audit gerekiyorsa trigger, eventual consistency yeterliyse Debezium.
• Volüm ekseni: 100M+ history için partitioning + BRIN; 10M altında saf GiST yeterli.
• Regülasyon ekseni: 7 yıl saklama + GDPR erasure çelişkisini cryptographic erase çözer.
• Ekosistem ekseni: OLTP’de Postgres temporal, OLAP’ta Iceberg time-travel; ikisi birbirinin yerine değil tamamlayıcı.

Karşılaştırmalı analytics motorları için BigQuery vs Snowflake ve Druid Pinot Trino yazılarındaki time-travel destek matrisi, PostgreSQL temporal kararını ekosistem bağlamında konumlandırıyor.

SSS — Sıkça Sorulan Sorular

Sonuç

PostgreSQL’de temporal tablo kurmak için ne çekirdek SQL:2011 desteği ne de pahalı bir ek lisans gerekiyor; tstzrange, GiST index, exclusion constraint ve temporal_tables uzantısı kombinasyonu standardın semantiğine eşdeğer sonuç veriyor. Karar matrisi net: senkron audit ve regülasyon zorunluluğu varsa trigger pattern, yüksek throughput stream analytics için logical decoding, hibrit sistemler için ikisinin kombinasyonu. Disk maliyeti partitioning + cold tablespace + jsonb diff ile %60-75 kontrol altına alınabilir.

Önerilen geçiş yol haritası üç fazlı: (1) küçük bir audit-kritik tabloda temporal_tables ile pilot, GiST index ve hash chain ile bütünlük; (2) compliance mapping doküman + SOX/GDPR/KVKK kanıt jeneratörü; (3) yüksek volüm tablolar için Debezium + Kafka topic compaction, hibrit kontrol. Her fazda autovacuum, wal_compression ve replication lag metriklerini Prometheus + Grafana ile izlemek, sürpriz disk şişmesinin önüne geçen tek operasyonel yatırım.

Üretime alma öncesi mimari review, partition stratejisi ve compliance kanıt akışı için iletişim sayfası üzerinden detaylı bir kapasite analizi planlanabilir; doğru kurulan temporal katman, hem regülatör hem forensic ekip için aynı veri kaynağını tek bir doğruluk noktasına indirir.

Dış otorite kaynakları: PostgreSQL Range Types Documentation · temporal_tables GitHub Repository · Debezium PostgreSQL Connector · Stack Overflow Developer Survey 2025 · NIST SP 800-92 Log Management · ENISA Threat Landscape 2024 · McKinsey Financial Services Insights