> 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/move/mode/cdc.md).

# CDC

Capture inserts, updates, and deletes from an operational database in near real-time with Nilus 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/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 user with `LOGIN`, `REPLICATION`, `SELECT`, and `CREATE` (for publication auto-create); a publication; a primary key or `REPLICA IDENTITY FULL`. The slot is created on first start.      |
| MySQL                | `log_bin` on, `binlog_format = ROW`, `binlog_row_image = FULL`, a unique `server_id`; a user with `SELECT`, `RELOAD`, `SHOW DATABASES`, `REPLICATION SLAVE`, `REPLICATION CLIENT`; primary keys on captured tables |
| MongoDB              | A replica set or sharded cluster; a user with `read` on the target, `local`, and `admin` databases (and `config.shards` if sharded)                                                                                |
| Microsoft SQL Server | CDC enabled on the database and target tables; SQL Server Agent running                                                                                                                                            |
| IBM Db2              | The ASN capture service running; each table added with `ASNCDC.ADDTABLE`, then a reinit; IIDR licensing; no `BOOLEAN` columns                                                                                      |

You also need a Depot for the source (IBM Db2 has none; see below) 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=ro
    options:
      strategy: flatten            # flatten nested events into rows
      max_table_nesting: "0"
    cdc:
      table.include.list: "${{schema.table}}"   # MongoDB: use collection.include.list
      topic.prefix: "${{prefix}}"  # connector identity; keep stable in production
      slot.name: "${{slot-name}}"  # PostgreSQL only; must be unique per pipeline
      publication.name: "${{publication-name}}"  # PostgreSQL only
  sink:
    address: dataos://${{sink-depot}}?purpose=rw
    options:
      dest_table: ${{schema.table}}
      incremental_strategy: append
```

IBM Db2 has no Depot. Set `source.address` to a direct `db2://{DB2_USERNAME}:{DB2_PASSWORD}@<host>:50000/<database>` URI and project the credentials through `spec.use.projection`. See the [IBM Db2 sample](https://v2.dataos.info/references/resources/nilus/cdc/sample-configs#ibm-db2) in References.

Choose the sink strategy:

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

{% hint style="warning" %}
`topic.prefix` is the connector identity. It must be unique across CDC pipelines, and Nilus uses it as the destination table prefix (default `cdc`). 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/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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.