PostgreSQL CDC: Logical Replication ve Debezium 2026

Postgres CDC Debezium mimarisi, PostgreSQL’in wal_level=logical ayarıyla ürettiği Write-Ahead Log (WAL) kayıtlarını Debezium connector’u üzerinden Kafka topic’lerine streaming eden çözümün adıdır. 2026 itibarıyla Debezium 2.7 sürümü, PostgreSQL 14-17 arasındaki tüm logical replication slot’larını pgoutput plugin’i üzerinden okuyabiliyor ve tipik bir OLTP yükünde 8-22 ms uçtan uca latency, 18.000-45.000 olay/saniye throughput sağlıyor. CDC pipeline’ı doğru kurulduğunda batch ETL’in 6-24 saatlik gecikmesini saniyenin altına indirir; yanlış kurulduğunda replication slot şişer, master disk dolar, üretim çöker.

Bu yazı; logical replication mekaniğini, Debezium’un pgoutput vs wal2json karşılaştırmasını, slot yönetimi tuzaklarını, exactly-once garantisini, Kafka Connect cluster boyutlandırmasını ve 2026 sürüm matrisini gerçek rakamlarla aktarıyor. PostgreSQL’i analitik tarafa, mikroservis senkronizasyonuna veya data lake’e gerçek zamanlı taşımak isteyen mühendisler için karar çerçevesidir.

CDC Nedir, Neden Postgres’te Logical Replication?

Change Data Capture (CDC), bir veritabanındaki INSERT/UPDATE/DELETE olaylarını kaynağa dokunmadan dışarı akıtma tekniğidir. Trigger tabanlı CDC tarihte yaygındı ama her satır için ek bir INSERT yaratıp OLTP transaction süresini %15-40 uzatıyordu. Log tabanlı CDC ise transaction log’unu (Postgres’te WAL, MySQL’de binlog, Oracle’da redo log) okur — kaynak veritabanına ek I/O baskısı %1-3 seviyesinde kalır.

PostgreSQL 9.4’ten beri (Aralık 2014) logical decoding özelliği ile WAL kayıtlarını satır seviyesinde JSON/Protobuf/Avro formatına çevirebiliyor. 2026’da PostgreSQL 17 ile gelen failover-aware logical slot özelliği, primary-standby geçişlerinde slot pozisyonunun kaybolmasını engelliyor — bu, üretim CDC kurulumlarında yıllarca baş ağrısı olmuş bir konuydu. Stack Overflow Developer Survey 2024’e göre PostgreSQL, profesyonel geliştiriciler arasında %49 ile en çok kullanılan veritabanı; bu, CDC pipeline’larının çoğunluğunun Postgres kaynaklı olmasını açıklıyor.

• Avantaj: Kaynak DB’ye OLTP yükü eklemez (WAL zaten yazılıyor).
• Avantaj: Satır seviyesinde before/after image — audit ve analitik için ideal.
• Dezavantaj: DDL değişiklikleri (ALTER TABLE) çoğu plugin tarafından replicate edilmez; şema evrimi ayrı yönetilir.
• Ne zaman seç: Saniye altı veri tazeliği gerektiren OLAP/operasyonel raporlama, mikroservis event sourcing, multi-region read replica.
• Ne zaman seçme: Günde tek seferlik batch yeterliyse — CDC operasyonel yük getirir.

CDC’nin ekosistemdeki yerini netleştirmek için Spark + Kafka pipeline yazımıza bakabilirsiniz; CDC genellikle Kafka’ya yazar, Spark veya Flink okur.

PostgreSQL Logical Replication Mekaniği

Logical replication üç parçadan oluşur: replication slot (WAL pozisyonunu tutar), output plugin (WAL’i okunabilir formata çevirir) ve subscriber (consumer). Slot yaratıldığı andan itibaren, consumer son okuduğu LSN’i (Log Sequence Number) pg_replication_slots view’inde işaretler. Consumer geri kalırsa Postgres, WAL dosyalarını silmez — bu da disk şişmesinin ana sebebidir.

2026’da yaygın 3 output plugin var: pgoutput (Postgres 10’dan beri built-in, Protobuf-benzeri binary), wal2json (community, JSON çıktısı), decoderbufs (Debezium’un eski Protobuf plugin’i, artık önerilmiyor). Debezium 2.x ile birlikte pgoutput de-facto standart oldu çünkü ek extension kurulumu gerektirmiyor; managed Postgres servislerinde (RDS, Cloud SQL, Azure Database) tek desteklenen seçenek genellikle pgoutput.

Önemli postgresql.conf parametreleri:

• wal_level = logical — kritik, restart gerekir.
• max_replication_slots = 10 — varsayılan, CDC + standby toplamı.
• max_wal_senders = 10 — eşzamanlı walsender process sayısı.
• wal_keep_size = 2GB (PG13+) — slot şişerse güvenlik tamponu.
• max_slot_wal_keep_size = 10GB — slot’un tutabileceği maksimum WAL; aşılırsa slot invalidated olur (üretimde önerilen güvenlik valfi).

Output Plugin	Format	Kurulum	Throughput (olay/sn)	Managed PG Desteği	2026 Önerisi
pgoutput	Binary (Protobuf-like)	Built-in (PG 10+)	40.000-55.000	RDS, Cloud SQL, Azure	Varsayılan
wal2json	JSON	Extension	18.000-28.000	Sınırlı (Aiven, self-host)	Sadece legacy
decoderbufs	Protobuf	Extension	30.000-40.000	Yok	Deprecated
test_decoding	Text	Built-in	5.000-10.000	Hepsi	Sadece debug

Rakamlar Debezium 2.7 + PostgreSQL 16 + c6i.4xlarge (16 vCPU, 32 GB) üzerinde TPC-C benzeri yükle ölçülmüş tipik aralıklardır; uygulama profili ve WAL kayıt boyutuna göre değişir. PostgreSQL’in genel performans optimizasyonu için Postgres performans yazımız WAL ayarlarına detaylı giriyor.

Debezium Mimarisi ve Kafka Connect

Debezium, resmi mimari dokümanında belirtildiği gibi Kafka Connect framework’ü üzerinde çalışan source connector’lardan oluşur. Her tablo bir Kafka topic’ine map edilir; default isimlendirme ..

formatındadır. Connector başlatıldığında önce snapshot fazına girer (mevcut tablo verisini SELECT ile çeker), ardından streaming fazına geçer (WAL’i takip eder). 2026’da Debezium 2.5+ ile gelen incremental snapshot özelliği, milyarlık satır tablolarını streaming’i durdurmadan parça parça snapshot etmeyi mümkün kılıyor — eskiden çok büyük tablolarda 12-48 saatlik blocking snapshot bir prodüksiyon ağrısıydı.

Kafka Connect cluster’ı resmi Apache Kafka dokümanında belirtildiği gibi standalone veya distributed modda çalışır. Üretimde distributed mod zorunlu: minimum 3 worker, her connector için tasks.max ayarı (Debezium PostgreSQL connector’da bu değer 1’dir — single-threaded streaming; paralelliği Kafka topic partition sayısıyla downstream sağlarsınız). Worker başına 4-8 vCPU ve 8-16 GB RAM tipik konfigürasyondur.

Debezium Sürümü	Çıkış Tarihi	Kafka Connect	PostgreSQL Desteği	Java	Önemli Özellik
1.9 (final)	Mart 2022	2.x-3.x	9.6-14	Java 11	Legacy LTS
2.0	Ekim 2022	3.0+	10-15	Java 11	Yeni signal table
2.3	Haziran 2023	3.4+	10-15	Java 11	Read-only signal
2.5	Aralık 2023	3.6+	10-16	Java 17	Incremental snapshot v2
2.7	2024	3.7+	11-16	Java 17	Vector tipi desteği
3.0 (preview)	2025	3.8+	12-17	Java 21	Debezium Server v2

Tarih ve sürüm numaraları Debezium release notlarından alınmıştır; preview/RC sürümleri için tam GA tarihi değişebilir. Debezium ekosistemindeki bir alternatif: Debezium Server (Kafka Connect olmadan Quarkus tabanlı standalone process, doğrudan Kinesis/Pulsar/PubSub’a yazabiliyor) ve Debezium Engine (kendi Java uygulamanıza embed edersiniz). Kafka kullanmıyorsanız Debezium Server pratik bir köprüdür.

Snapshot Stratejileri ve İlk Yükleme

Snapshot, Debezium’un en hassas operasyonel kısmıdır çünkü tablonun consistent bir kopyasını çekerken WAL pozisyonunu da kaydetmesi gerekir. Debezium 5 snapshot modu destekler:

1. initial — varsayılan; tabloyu snapshot eder, sonra streaming’e geçer.
2. initial_only — sadece snapshot, streaming yok (tek seferlik migration için).
3. never — snapshot atlanır, doğrudan streaming başlar (yeni tablolar için riskli).
4. when_needed — slot pozisyonu kaybolmuşsa snapshot yapar.
5. schema_only — sadece DDL alır, veri almaz.

2026’da büyük tablolar için incremental snapshot önerilir. Connector çalışırken bir signal table‘a row insert ederek snapshot tetiklenir; Debezium tabloyu chunk’lara (varsayılan 1024 satır) böler ve her chunk için bir READ event’i streaming akışına karıştırır. Bu sayede:

• Avantaj: Production streaming durmaz, downtime sıfır.
• Avantaj: Snapshot başarısız olursa kaldığı chunk’tan devam eder.
• Avantaj: Tek tablo / belirli WHERE koşulu ile re-snapshot mümkün.
• Dezavantaj: Signal table yazma izni gerekir (read-only kullanıcı yetmez; 2.3+ ile read-only signal channel geldi).

Snapshot esnasında PostgreSQL’de SET TRANSACTION ISOLATION LEVEL REPEATABLE READ + SET TRANSACTION SNAPSHOT kullanılır; bu, snapshot süresince tablodaki uzun süreli AccessShareLock’u en aza indirir ama vacuum’un eski satırları temizlemesini geciktirebilir. Çok yüklü tablolarda autovacuum_vacuum_cost_delay kısa süreliğine düşürülmemelidir; snapshot bitince bloat’u temizlemek için ekstra vacuum koşturmak gerekebilir.

Replication Slot Yönetimi ve Disk Şişme Riski

Üretimde CDC pipeline’larının başına gelen 1 numaralı kaza: consumer durur, slot şişer, master disk dolar. Bunu engellemek için 3 katmanlı savunma kurulur:

1. max_slot_wal_keep_size = 10GB (veya işiniz ne kadar gecikmeye dayanabilirse) — limit aşılırsa slot otomatik invalidated, master yaşar ama CDC’yi yeniden snapshot etmek gerekir.
2. Monitoring: pg_replication_slots.active = false ve pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) > 1 GB → PagerDuty alert.
3. Heartbeat tablosu: Debezium’un heartbeat.interval.ms = 60000 ayarı, düşük yazma trafiği olan replica DB’lerde slot’un LSN’inin ilerlemesini sağlar (yoksa slot kıpırdamaz).

Durum	Belirti	Sebep	Çözüm	Önleme
Slot lag büyüyor	WAL disk %75+	Consumer yavaş/durmuş	Connector restart, scale Kafka	Slot lag alert + max_slot_wal_keep_size
Slot invalidated	“slot invalidated” log	WAL silindi	Yeni slot + initial snapshot	İzleme + tampon
Heartbeat yok	LSN ilerlemez	Tabloya yazma yok	heartbeat.interval.ms ayarla	Default heartbeat aç
Toast değer eksik	UPDATE’de TOAST kolonu __debezium_unavailable_value	REPLICA IDENTITY DEFAULT	REPLICA IDENTITY FULL veya kolon include	Tablo başı bilinçli karar
Long-running TX	WAL şişer	Açık transaction (BEGIN sonrası COMMIT yok)	idle_in_transaction_session_timeout	Application timeout
Snapshot bitmiyor	Saatlerce READ event akar	Çok büyük tablo	Incremental snapshot’a geç	Initial yerine signal-based

REPLICA IDENTITY meselesi özellikle önemlidir. Default değerle (DEFAULT), UPDATE/DELETE eventlerinde sadece primary key alanları “before” image’ında bulunur. Eğer downstream consumer eski değeri görmek istiyorsa (audit, diff, materialized view invalidation), ALTER TABLE ... REPLICA IDENTITY FULL ayarı gerekir — ama bu WAL boyutunu 2-5x büyütür. Geniş tablolarda full identity yerine sadece kritik kolonları içeren bir unique index + REPLICA IDENTITY USING INDEX kombinasyonu daha dengeli olur.

Exactly-Once mi, At-Least-Once mi?

Debezium varsayılan olarak at-least-once garanti verir: consumer çöktüğünde son commit edilen offset’ten devam eder; aynı event 2 kez gelebilir. 2024’te Debezium 2.4 ile gelen Kafka Connect exactly.once.support = required ayarı ve idempotent producer + transactional broker kombinasyonu ile pipeline’ın Debezium → Kafka kısmı exactly-once yapılabiliyor. Ancak uçtan uca exactly-once için downstream consumer’ın da Kafka transaction’larına abone olması (read_committed isolation) ve hedef sistemin idempotent yazması (UPSERT, deterministic ID) gerekir.

Pratikte 3 desen yaygın:

• At-least-once + idempotent UPSERT: En basit, en yaygın. Hedefte primary key bazlı INSERT ON CONFLICT DO UPDATE; duplicate event zararsız.
• Exactly-once Kafka transactions: Debezium → Kafka → Kafka Streams/Flink exactly-once işleme. Throughput %15-25 düşer.
• Outbox pattern: Mikroservis kendi transaction’ında bir outbox tablosuna event yazar, Debezium o tabloyu okur. İş mantığı + event yayını aynı transaction’da → distributed transaction olmadan reliable messaging.

Outbox pattern, event-driven mimari yazımızda daha geniş ele alındığı gibi, modern mikroservislerin en güvenilir entegrasyon desenidir. Debezium’un built-in Outbox Event Router SMT’si (Single Message Transform) bu deseni neredeyse sıfır kodla kurar.

Performans, Latency ve Kapasite Planlaması

CDC pipeline’ının performansını 4 metrik belirler: source DB WAL üretim hızı, plugin decode hızı, Kafka Connect throughput, Kafka broker fsync gecikmesi. Confluent’in CDC benchmark yazısında yayımlanan tipik aralıklar 2026 donanımı (NVMe SSD, 25 Gbit ağ) ile birlikte:

Senaryo	WAL Üretimi	Decode Throughput	Kafka Throughput	E2E Latency (p99)	Connect Worker Sayısı
Düşük yük OLTP	2-5 MB/sn	8.000 evt/sn	10.000 msg/sn	15-25 ms	1
Orta OLTP	20-40 MB/sn	25.000 evt/sn	30.000 msg/sn	30-60 ms	3
Yüksek OLTP	80-150 MB/sn	45.000 evt/sn	60.000 msg/sn	80-150 ms	5
Bulk load (snapshot)	—	100.000 evt/sn (incremental)	120.000 msg/sn	—	3
Multi-tenant (50+ tablo)	30 MB/sn	20.000 evt/sn (toplam)	25.000 msg/sn	50-100 ms	3

Kritik darboğaz çoğu zaman Kafka Connect worker’ın tek thread’li olmasıdır: Debezium PostgreSQL connector’da tasks.max=1 sabit (çünkü tek bir replication slot tek bir consumer tarafından okunur). Paralelliği topic partition seviyesinde sağlarsınız: topic.creation.default.partitions = 12 gibi bir ayar, downstream consumer’ların paralel ölçeklenmesini mümkün kılar. Birden fazla tabloyu paralel okumak için aynı DB’ye birden fazla connector deploy edebilirsiniz; her connector kendi slot’unu açar — ama her slot ekstra WAL retention demektir.

Stream işleme tarafında CDC olaylarını agregasyon veya enrichment için Flink veya Spark Structured Streaming ile birleştirmek yaygın. Stream processing karşılaştırma yazımız bu üç motorun CDC kullanım örneklerini detaylandırıyor.

Şema Evrimi ve DDL

Logical replication’ın en bilinen kısıtı: DDL replicate edilmez. ALTER TABLE ADD COLUMN kaynakta yapıldığında Debezium yeni kolonu eventlerinde göstermeye başlar ama downstream consumer ve şema kaydı (Confluent Schema Registry, Apicurio) güncellenmemişse mesajlar reddedilir veya sessizce kaybolur.

2026’da önerilen pratikler:

• Schema Registry zorunlu: Avro veya JSON Schema ile uyumluluk modu BACKWARD (yeni kolonlar default değerle eklenebilir, mevcut consumer’lar kırılmaz).
• DDL propagation Liquibase/Flyway ile: CI/CD pipeline’ı önce hedef sistemde şemayı evrimleştirir, sonra kaynak DB’de migration koşturur.
• Expand-Contract pattern: Yeni kolon nullable eklenir → consumer yazmaya başlar → eski kolon deprecate → tamamen kaldırılır. Hiçbir noktada incompatible olmaz.
• Forbidden DDL listesi: DROP COLUMN, RENAME COLUMN, type değişiklikleri review gerektirir; ALTER TABLE’ı self-service yapmayın.

Bu konuda veri yönetişimi ve katalog yazımız şema değişikliklerinin organizational governance tarafını ele alır; CDC ile birleştiğinde “kim hangi tabloyu hangi consumer’a yayınlıyor” sorusu data catalog disiplini gerektirir.

Debezium Alternatifleri: AWS DMS, Fivetran, Striim

Debezium open-source dünyada de-facto standart olsa da managed alternatifler ciddi pazara sahiptir. Karar matrisi:

Çözüm	Lisans/Model	Tipik Fiyat	Kaynak DB Çeşitliliği	Hedef DB Çeşitliliği	Operasyonel Yük	Ne Zaman Seç
Debezium + Kafka Connect	Apache 2.0	Sadece infra ($300-3000/ay)	10+ kaynak (PG, MySQL, Oracle, SQL Server, MongoDB, Cassandra)	Kafka via SMT/connector	Yüksek (DevOps gerekir)	Volume yüksek, customization ihtiyacı, multi-target
AWS DMS + DMS Serverless	Managed	~$0.10-0.40/saat per instance + I/O	20+ kaynak	15+ hedef	Düşük	AWS-native, dümdüz lift-and-shift
Fivetran	SaaS (MAR-based)	Tipik $1.500-15.000/ay (kullanıma göre)	300+ connector	~20 warehouse	Çok düşük	SaaS sources, analytics warehouse
Striim	Commercial	Enterprise (özel)	15+ kaynak	30+ hedef	Orta	Heterojen environment, in-flight transform
Airbyte (CDC)	OSS + Cloud	OSS bedava, Cloud $250-2.500/ay+	350+ connector	40+ hedef	Orta	Connector çeşitliliği, batch+CDC hibrit
Materialize / Decodable	Managed streaming	$500-5.000/ay	5+ kaynak	Sorgulanabilir view	Düşük	Real-time materialized view kullanım davası

Fiyatlar 2026 başı kamuya açık fiyat sayfaları ve müşteri raporlarından derlenmiş yaklaşık aralıklardır; gerçek maliyet veri hacmi, connector sayısı ve sözleşmeye göre değişir. Bu kararı verirken Ömer Önal olarak bir saha gözlemim: Postgres tek kaynak ve hedef Kafka ise Debezium neredeyse her zaman doğru seçim. Ama 12+ heterojen kaynak (Salesforce, NetSuite, Stripe + 4 DB) varsa Fivetran/Airbyte bir mühendislik takımının 6-9 ayını geri kazandırır. Bu tip mimari kararlarda danışmanlık desteği alarak ROI ve operasyonel yükü birlikte modellemek mantıklıdır.

Üretim Vakaları: Analitik, Search, Cache Invalidation

CDC pipeline’ları 2026’da 4 dominant kullanım alanına yerleşti:

1. OLTP → Analitik Warehouse: Postgres → Kafka → Snowflake/BigQuery near-real-time. Eskiden gece batch yapılıyordu, CDC ile dashboards 30-60 sn tazelikte.
2. OLTP → OpenSearch/Elasticsearch: Ürün katalog değişikliklerini search index’e yansıtmak. Debezium Elasticsearch sink connector ile.
3. Cache Invalidation: Redis/Memcached cache key’lerini DB değişikliklerinde invalidate etmek; eski TTL bazlı invalidation’a göre çok daha tutarlı.
4. Mikroservis Replication: Domain event’leri olarak komşu service’lere yayma; her domain’in “data product” çıktısı olarak yayınladığı stream haline geliyor.

Üretimden bir veri noktası: orta ölçekli bir e-ticaret (~200 GB Postgres, günlük 8M sipariş satırı UPDATE) Debezium + 3 Kafka Connect worker + 6 broker Kafka cluster ile AWS blog’larında raporlanan benzer setup’ta uçtan uca p95 latency 35-55 ms aralığında sürdürülebiliyor; aylık altyapı maliyeti 1.200-1.800 USD bandında. Aynı senaryoyu Fivetran ile çalıştıran benzer ölçekli bir müşteri tipik olarak 3.500-5.500 USD/ay ödüyor ama 0.5-1 FTE mühendis tasarruf ediyor.

İzleme, Alerting ve Operasyonel Disiplin

CDC pipeline’ı kurulduktan sonra unutulan bir sistem değildir; aktif izleme gerektirir. Minimum metrik seti:

• Source DB: pg_replication_slots.confirmed_flush_lsn vs pg_current_wal_lsn() farkı (slot lag MB).
• Debezium connector: JMX üzerinden MilliSecondsBehindSource, NumberOfEventsFiltered, QueueRemainingCapacity.
• Kafka Connect: source-record-poll-rate, source-record-write-rate, error connector count.
• Kafka broker: Topic lag, ISR shrink/expand, log flush latency.
• Downstream consumer: Application-spesifik (warehouse load latency, search index refresh time, cache hit ratio).

Alert eşikleri için pragmatik başlangıç değerleri: slot lag > 1 GB → warning, > 5 GB → critical; MilliSecondsBehindSource > 30.000 ms → warning, > 120.000 ms → critical; connector FAILED state → page. Prometheus + Grafana stack’i Debezium ve Kafka Connect’in JMX exporter’ı ile out-of-the-box çalışıyor.

SSS

Debezium 2026’da hala open source mu?

Evet, Debezium Apache License 2.0 altında Red Hat tarafından sponsorlanan tamamen açık kaynak bir projedir. 2024’te Debezium Platform adıyla yönetilen bir SaaS preview duyuruldu fakat OSS connector’lar ve Debezium Server ücretsiz kalmaya devam ediyor. GitHub’da 11.000+ star ile aktif geliştirme sürüyor.

PostgreSQL CDC için pgoutput yerine wal2json kullanmalı mıyım?

2026’da yeni kurulumlarda hayır. pgoutput built-in olduğu için RDS, Cloud SQL ve Azure Database for PostgreSQL’de tek desteklenen pratik seçenektir; binary format wal2json’a göre yaklaşık 2x throughput verir. wal2json sadece eski self-hosted setup’larla uyumluluk veya JSON formatını başka bir consumer’la paylaşma zorunluluğu varsa anlamlıdır.

Debezium’u Kafka olmadan kullanabilir miyim?

Evet, iki yol var. Debezium Server standalone bir Quarkus uygulamasıdır; doğrudan Kinesis, Pulsar, Pub/Sub, Redis Streams, EventHubs gibi alternatif streaming hedeflerine yazabilir. Debezium Engine ise embedded mode’dur; kendi Java uygulamanıza library olarak alıp event’leri callback ile işleyebilirsiniz. Her ikisinde de Kafka Connect framework’ü ve Kafka broker gereksinimi kalkıyor.

Çok büyük tablomu (1 milyar+ satır) snapshot etmek üretimi durdurur mu?

Debezium 2.3+ ile gelen incremental snapshot kullanırsanız hayır. Streaming devam ederken signal table’a snapshot tetikleyici bir satır insert edersiniz, Debezium tabloyu chunk chunk okur ve READ event’leri olarak akışa karıştırır. Tipik chunk boyutu 1024 satır; pause/resume desteklenir. Klasik initial mode’da büyük tablo saatlerce blocking snapshot yapar.

CDC ile exactly-once garantisi nasıl sağlanır?

Uçtan uca exactly-once için 3 koşul gerekir: Debezium → Kafka kısmında Kafka Connect 3.3+ ile exactly.once.support=required ve idempotent producer aktif; downstream consumer Kafka transaction’larını read_committed isolation seviyesinde okuyor; hedef sistem idempotent yazıyor (UPSERT veya deterministic primary key). At-least-once + idempotent UPSERT pratikte çoğu zaman daha basit ve yeterlidir.

Sonuç

PostgreSQL CDC için 2026’da varsayılan stack Debezium 2.7 + pgoutput + Kafka Connect distributed‘tır; bu kombinasyon 10+ yıl üretim deneyimine sahip, açık kaynak, vendor-bağımsız ve managed PostgreSQL servislerinin tamamında çalışıyor. Karar çerçevesi şöyle: tek kaynak Postgres + hedef Kafka/warehouse ise Debezium; 10+ heterojen kaynak + sınırlı DevOps kapasitesi varsa Fivetran/Airbyte; AWS ekosisteminde lift-and-shift migrasyon ise DMS.

Kurulumda kritik 3 nokta: max_slot_wal_keep_size ile güvenlik valfi açın, REPLICA IDENTITY kararını tablo başına bilinçli verin, incremental snapshot’ı varsayılan yapın. İzleme tarafında slot lag, MilliSecondsBehindSource ve connector state üç temel sinyal — bu üçü yeşilse CDC operasyonel olarak güvenlidir.

CDC, batch ETL’in 2010’lardaki dominasyonunu kıran mimari kaymanın merkezindedir; bir sonraki adım olarak streaming-native lakehouse mimarileri için Databricks / Snowflake lakehouse yazımız ve real-time stream processing için veri platformu hizmetlerimiz üzerinden danışmanlık alabilirsiniz.