A core system may need to feed new applications without being repeatedly queried or modified for each one. Change data capture (CDC) monitors changes to its data rather than repeatedly reading the complete current contents. For a relational database, a connector can follow the transaction log, where changes are recorded, and send the resulting data to Kafka. section 11.9 section 18.2
Why not just poll a table? A JDBC Source Connector can track an incrementing column or timestamp, but those choices can miss changes. An update to an existing row does not give it a new ID; two changes sharing a timestamp can also cause one to be skipped. JDBC bulk mode reloads the entire table and is inefficient. A CDC connector such as Debezium addresses the change-tracking problem instead. section 11.8.3 section 11.10
For a PostgreSQL-to-Kafka setup:
- Set PostgreSQL’s wal_level to logical and restart the server so the connector can monitor the necessary changes. section 11.9.1
- Create a database user with REPLICATION privilege, then install and configure the Debezium connector. section 11.9.1
- Configure database connection details and table filtering; use topic.prefix to organize generated Kafka topic names and avoid conflicts. section 11.10
# Linux file path: /etc/postgresql/<version>/main/postgresql.conf # Windows file path: C://Programs/PostgreSQL/<version>/data/postgresql.conf wal_level = logical
The PostgreSQL configuration line needed before the Debezium connector can monitor changes. section 11.9.1
Getting changes into Kafka is not the same as making them ready for other teams. Core-system data may retain unfamiliar formats and be spread across many normalized tables. Build new, usable data structures from the captured data rather than asking downstream applications to consume the raw tables directly; consolidation can require substantial joins and state stores. section 18.2 section 18.6




