> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/build/v1/move/mode/cdc.md).

# CDC

Change data capture (CDC) reads from a database's transaction log and delivers every insert, update, and delete to your engine in near real-time, without full reloads. Use it when freshness matters and reloading the whole table is too slow or too costly.

## When to use CDC

* The use case needs near real-time freshness.
* Full reloads are too slow or expensive for the source.
* You need to preserve the history of every change.
* The source is a transactional database that exposes a transaction log or change stream.

If the source has no write-ahead log, binlog, oplog, or CDC tables, use [batch](/build/v1/move/mode/batch.md) instead.

## Before you begin

CDC needs source-side setup before the pipeline can run:

| Source               | Required setup                                                                              |
| -------------------- | ------------------------------------------------------------------------------------------- |
| PostgreSQL           | `wal_level = logical`, a dedicated replication slot, and a user with the `REPLICATION` role |
| MySQL                | `binlog_format = ROW` and a user with `REPLICATION SLAVE`                                   |
| MongoDB              | A replica set; a user with `read` on the target and the `local` database                    |
| Microsoft SQL Server | CDC enabled on the database and target tables; SQL Server Agent running                     |
| IBM Db2              | Db2 change data capture tables enabled for the target schema                                |

You also need a Depot for the source and destination, and a compute profile. See [supported CDC sources](https://v2.dataos.info/references/resources/nilus/cdc/cdc-sources) in References for full per-source prerequisites.

## 1. Write the manifest

Create a `nilus` resource with `spec.type: cdc`:

```yaml
name: ${{pipeline-name}}
version: v1alpha
type: nilus
tags:
  - nilus-cdc
description: ${{description}}
spec:
  type: cdc
  compute: ${{compute-profile}}
  logLevel: INFO
  source:
    address: dataos://${{source-depot}}?purpose=rw
    options:
      strategy: flatten            # flatten nested events into rows
      max_table_nesting: "0"
    cdc:
      table.include.list: "${{schema.table}}"
      topic.prefix: "${{prefix}}"  # connector identity; keep stable in production
      slot.name: "${{slot-name}}"  # PostgreSQL only; must be unique per pipeline
  sink:
    address: dataos://${{sink-depot}}?purpose=rw
    options:
      dest_table: ${{schema.table}}
      incremental_strategy: append
```

Choose the sink strategy:

| Strategy | Use it when                                                     |
| -------- | --------------------------------------------------------------- |
| `append` | Write every change as a new row. Preserves full change history. |
| `merge`  | Upsert by primary key. The destination reflects current state.  |

{% hint style="warning" %}
`topic.prefix` is the connector identity and is appended to the destination table name. Do not change it once the pipeline is in production. For PostgreSQL, each pipeline must use a unique `slot.name`; reusing a slot causes replication conflicts.
{% endhint %}

For the full attribute reference, see [CDC configuration](https://v2.dataos.info/references/resources/nilus/cdc/pipeline-config) in References.

## 2. Apply and confirm

```bash
dataos-ctl resource apply -f ${{path-to-manifest.yaml}}
dataos-ctl resource get -t nilus -n ${{pipeline-name}}
```

When changes are landing, [explore the moved data](/build/v1/move/explore-moved-data.md) to confirm the destination reflects the source.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://v2.dataos.info/build/v1/move/mode/cdc.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.