Go to connections and create a new connection. Then, select the existing Postgres source you have just created and then do the same for the Local JSON destination. Once you're done, you can set up the connection as follows.
Replication Frequency: I recommend setting it to "manual" if you're testing. You can change to any frequency that makes sense to your use case when you're ready.Destination Namespace: Mirror source structureDestination Stream Prefix: You can leave this option blank, as we don't want a prefix at the destination.Then, it's time to configure the streams , which in this case are the tables in our database. For now, we only have the cars table. If you expand it, you can see the columns it has.
Now, you should select a sync mode . If you want to take full advantage of using Change Data Capture, you should use Incremental | Append mode to only look at the rows that have changed in the source and sync them to the destination. Selecting a Full Refresh mode would sync the whole source table, which is most likely not what you want when using CDC. Learn more about sync modes in our documentation .
When using an Incremental sync mode, we would generally need to provide a Cursor field , but when using CDC, that's not necessary since the changes in the source are detected via the Debezium connector stream.
Once you're ready, save the changes. Then, you can run your first sync by clicking on Sync now . You can check your run logs to verify everything is going well. Just wait for the sync to be completed, and that's it! You've replicated data using Postgres CDC.
Step 6: Verify that the sync worked Step 7: Test CDC in action by creating and deleting an object from the database Now, let's test the CDC setup we have configured. To do that, run the following queries to insert and delete a row from the database.
INSERT INTO cars VALUES(3, 'tesla');DELETE FROM cars WHERE NAME = 'tesla';
Launch a sync and, once it finishes, check the local JSON file to verify that CDC has captured the change. The JSON file should now have two new lines, showing the addition and deletion of the row from the database.
We confirm that CDC allows you to see that a row was deleted, which would be impossible to detect when using the regular Incremental sync mode. The _ab_cdc_deleted_at meta field not being null means id=3 was deleted.
From the root directory of the Airbyte project, go to /tmp/airbyte_local/cdc_tutorial , and you will find a file named _airbyte_raw_cars.jsonl where the data from the PostgreSQL database was replicated.
You can check the file's contents in your preferred IDE or run the following command.
cat _airbyte_raw_cars.jsonl
Wrapping up In this tutorial you have learned how logical decoding works in PostgreSQL and how to leverage it to implement an EL(T) using Airbyte. Using CDC to capture database changes is one of the best ways to replicate data, especially when you have huge amounts of it and the need to track delete operations in the source database.
If you want to easily try out Airbyte, you might want to check our fully managed solution: Airbyte Cloud . We also invite you to join the conversation on our community Slack Channel to share your ideas with thousands of data engineers and help make everyone’s project a success!
FAQs (Frequently Asked Questions) What is Change Data Capture (CDC) in PostgreSQL? Change Data Capture (CDC) in PostgreSQL is a mechanism that allows real-time tracking and capturing of data changes occurring in the database. It enables organizations to monitor inserts, updates, and deletions made to database records and replicate these changes to downstream systems or data warehouses. How does Postgres CDC work, and what mechanisms does it utilize? CDC in PostgreSQL operates by leveraging a feature called logical decoding. This feature reads the write-ahead log (WAL), a log file that records all changes made to the database. Logical decoding converts these changes into a stream of events, which can then be consumed by applications or replication systems for further processing. What are the benefits of implementing CDC in PostgreSQL, and how can it improve data management? Implementing Postgres CDC offers several benefits, including real-time data synchronization, improved data integrity, and reduced latency in data replication. CDC enables organizations to make informed decisions based on up-to-date data and ensures that data across multiple systems remains consistent and accurate. What are the prerequisites for setting up CDC in PostgreSQL, and what components are required? To set up CDC in PostgreSQL, you'll need a PostgreSQL database instance configured with logical replication enabled. Additionally, you'll require a logical decoding plugin, such as pgoutput or wal2json, which converts the WAL records into a format that can be consumed by downstream applications or systems. Can CDC in PostgreSQL capture all types of data modifications, including inserts, updates, and deletions? Yes, CDC in PostgreSQL can capture all types of data modifications, including inserts, updates, and deletions. By monitoring changes at the database level and utilizing logical decoding, PostgreSQL CDC ensures that all modifications to database records are captured and made available for replication or analysis. How does CDC ensure data consistency and integrity when replicating data from PostgreSQL using a data replication tool? CDC guarantees data consistency and integrity when replicating PostgreSQL data with Airbyte by continuously monitoring database changes, capturing all modifications (inserts, updates, and deletions), and preserving the order of operations during replication. Airbyte's incremental replication minimizes latency, and its built-in data validation and error handling mechanisms ensure accuracy and reliability. 
Postgres