CREATE CHANGEFEED

The CREATE CHANGEFEED creates a new Enterprise changefeed, which targets an allowlist of tables called “watched rows”. Every change to a watched row is emitted as a record in a configurable format (JSON or Avro) to a . CREATE CHANGEFEED also supports that allow you to filter and transform change data before emitting changefeed messages. You can create, pause, resume, , or cancel an Enterprise changefeed. To get started with changefeeds, refer to the page for important usage considerations. For detail on how changefeeds emit messages, refer to the page. The examples on this page provide the foundational syntax of the CREATE CHANGEFEED statement. For examples on more specific use cases with changefeeds see the following pages:

Cockroach Labs recommends monitoring your changefeeds to track and usage. Refer to the page for more information.

Required privileges

You can a user the CHANGEFEED privilege to allow them to create changefeeds on a specific table:

GRANT CHANGEFEED ON TABLE example_table TO user;

When you grant a user the CHANGEFEED privilege on a set of tables, they can:

Create changefeeds on the target tables even if the user does not have the or the SELECT privilege on the tables.
Manage the changefeed jobs running on the tables using the , , , and commands.

These users will be able to create changefeeds, but they will not be able to run a SELECT query on that data directly. However, they could still read this data indirectly if they have read access to the . New in v23.1: To restrict a user’s access to changefeed data and sink credentials, enable the changefeed.permissions.require_external_connection_sink.enabled cluster setting. When you enable this setting, users with the CHANGEFEED privilege on a set of tables can only create changefeeds into external connections . You can add CHANGEFEED to the user or role’s with :

ALTER DEFAULT PRIVILEGES GRANT CHANGEFEED ON TABLES TO user;

Privilege model

For fine-grained access control, we recommend using the system-level privileges CHANGEFEED and CONTROLJOB / VIEWJOB.

The following summarizes the operations users can run when they have changefeed privileges on a table:

Granted privileges	Usage
`CHANGEFEED`	Create changefeeds on tables. View and manage changefeed jobs on tables.
`CHANGEFEED` + on external connection	Create changefeeds on tables to an external connection URI. Manage changefeed jobs on tables. Note: If you need to manage access to changefeed sink URIs, set the `changefeed.permissions.require_external_connection_sink.enabled=true` cluster setting. This will mean that users with these privileges can only create changefeeds on external connections.
`SELECT`	Create a sinkless changefeed that emits messages to a SQL client.
Deprecated `CONTROLCHANGEFEED` role option + `SELECT`	Create changefeeds on tables. Users with the `CONTROLCHANGEFEED` role option must have `SELECT` on each table, even if they are also granted the `CHANGEFEED` privilege. The `CONTROLCHANGEFEED` role option will be removed in a future release. We recommend using the `CHANGEFEED` and `CONTROLJOB`/ `VIEWJOB` for fine-grained access control.
`admin`	Create, view, and manage changefeed jobs.

Synopsis

Parameters

Parameter	Description
`changefeed_target`	The name of the table (or tables in a comma separated list) to create a changefeed for. Note: Before creating a changefeed, consider the number of changefeeds versus the number of tables to include in a single changefeed. Each scenario can have an impact on total memory usage or changefeed performance. Refer to for more detail.
`sink`	The location of the configurable sink. The scheme of the URI indicates the type. For more information, refer to Sink URI. Note: If you create a changefeed without a sink, your changefeed will run like a sending messages to the SQL client. For more detail, refer to the page.
`option` / `value`	For a list of available options and their values, refer to Options.

Parameters for change data capture queries

Change data capture queries allow you to define the change data emitted to your sink when you create a changefeed. Refer to the page for detail on the functionality, syntax, and use cases for creating changefeeds that include queries.

Parameter	Description
`sink`	The location of the configurable sink. The scheme of the URI indicates the type. For more information, see Sink URI.
`option` / `value`	For a list of available options and their values, see Options.
`target_list`	The columns to emit data from.
`changefeed_target_expr`	The target table for the changefeed.
`opt_where_clause`	An optional `WHERE` clause to apply filters to the table.

Sink URI

This section provides example URIs for each of the sinks that CockroachDB changefeeds support. For more comprehensive detail of using and configuring each sink, refer to the page.

'{scheme}://{host}:{port}?{query_parameters}'

URI Component	Description
`scheme`	The type of sink: `kafka`, `gcpubsub`, any cloud storage sink, or webhook sink.
`host`	The sink’s hostname or IP address.
`port`	The sink’s port.
`query_parameters`	The sink’s query parameters.

You can create an external connection to represent a changefeed sink URI. This allows you to specify the external connection’s name in statements rather than the provider-specific URI. For detail on using external connections, see the page.

Kafka

Example of a Kafka sink URI:

'kafka://broker.address.com:9092?topic_prefix=bar_&tls_enabled=true&ca_cert=LS0tLS1CRUdJTiBDRVJUSUZ&sasl_enabled=true&sasl_user={sasl user}&sasl_password={url-encoded password}&sasl_mechanism=SCRAM-SHA-256'

and in CockroachDB Advanced clusters do not support connecting to a sink’s internal IP addresses for . To connect to a Kafka sink from CockroachDB Advanced, it is necessary to expose the Kafka cluster’s external IP address and open ports with firewall rules to allow access from a CockroachDB Advanced cluster.

Google Cloud Pub/Sub

This feature is in and subject to change. To share feedback and/or issues, contact Support.

Example of a Google Cloud Pub/Sub sink URI:

'gcpubsub://{project name}?region={region}&topic_name={topic name}&AUTH=specified&CREDENTIALS={base64-encoded key}'

New in v23.1: Enable the changefeed.new_pubsub_sink_enabled to improve the throughput of changefeeds emitting to . Enabling this setting also alters the message format to use capitalized top-level fields in changefeeds emitting JSON-encoded messages to a Pub/Sub sink. For more details, refer to the section.

explains the requirements for the authentication parameter with specified or implicit. Refer to for further consideration.

Cloud Storage

The following are example file URLs for each of the cloud storage schemes:

Location	Example
Amazon S3	`'s3://{BUCKET NAME}/{PATH}?AWS_ACCESS_KEY_ID={KEY ID}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'`
Azure Blob Storage	`'azure://{CONTAINER NAME}/{PATH}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={URL-ENCODED KEY}'`
Google Cloud	`'gs://{BUCKET NAME}/{PATH}?AUTH=specified&CREDENTIALS={ENCODED KEY'`
HTTP	`'http://localhost:8080/{PATH}'`

explains the requirements for authentication and encryption for each supported cloud storage sink. Refer to for considerations when using cloud storage.

Webhook

Example of a webhook URI:

'webhook-https://{your-webhook-endpoint}?insecure_tls_skip_verify=true'

New in v23.1: Enable the changefeed.new_webhook_sink_enabled to improve the throughput of changefeeds emitting to webhook sinks. .

Refer to for specifics on webhook sink configuration.

Query parameters

Parameters should always be URI-encoded before they are included in the changefeed’s URI, as they often contain special characters. Use Javascript’s encodeURIComponent function or Go language’s url.QueryEscape function to URI-encode the parameters. Other languages provide similar functions to URI-encode special characters.

Query parameters include:

Parameter	Sink Type	Description
`assume_role`		Pass the ARN of the role to assume. Use in combination with `AUTH=implicit` or `specified`. New in v23.1: `external_id`: Use as a value to `ASSUME_ROLE` to specify the external ID for third-party access to your S3 bucket.
`ca_cert`	, , Confluent schema registry	The base64-encoded `ca_cert` file. Specify `ca_cert` for a Kafka sink, webhook sink, and/or a Confluent schema registry. For usage with a Kafka sink, see . It’s necessary to state `https` in the schema registry’s address when passing `ca_cert`: `confluent_schema_registry='https://schema_registry:8081?ca_cert=LS0tLS1CRUdJTiBDRVJUSUZ'` See `confluent_schema_registry` for more detail on using this option. Note: To encode your `ca.cert`, run `base64 -w 0 ca.cert`.
`client_cert`	, , Confluent schema registry	The base64-encoded Privacy Enhanced Mail (PEM) certificate. This is used with `client_key`.
`client_key`	, , Confluent schema registry	The base64-encoded private key for the PEM certificate. This is used with `client_cert`. Note: Client keys are often encrypted. You will receive an error if you pass an encrypted client key in your changefeed statement. To decrypt the client key, run: `openssl rsa -in key.pem -out key.decrypt.pem -passin pass:{PASSWORD}`. Once decrypted, be sure to update your changefeed statement to use the new `key.decrypt.pem` file instead.
`file_size`		The file will be flushed (i.e., written to the sink) when it exceeds the specified file size. This can be used with the `WITH resolved` option, which flushes on a specified cadence. When you change or increase `file_size`, ensure that you adjust the `changefeed.memory.per_changefeed_limit` , which has a default of `512MiB`. Buffering messages can quickly reach this limit if you have increased the file size. Refer to for more detail. Default: `16MB`
`insecure_tls_skip_verify`	,	If `true`, disable client-side validation of responses. Note that a CA certificate is still required; this parameter means that the client will not verify the certificate. Warning: Use this query parameter with caution, as it creates MITM vulnerabilities unless combined with another method of authentication. Default: `false`
`partition_format`		Specify how changefeed file paths are partitioned in cloud storage sinks. Use `partition_format` with the following values: `daily` is the default behavior that organizes directories by dates (`2022-05-18/`, `2022-05-19/`, etc.). `hourly` will further organize directories by hour within each date directory (`2022-05-18/06`, `2022-05-18/07`, etc.). `flat` will not partition the files at all. For example: `CREATE CHANGEFEED FOR TABLE users INTO 'gs://...?AUTH...&partition_format=hourly'` Default: `daily`

For example: CREATE CHANGEFEED FOR TABLE users INTO 'gs://...?AUTH...&partition_format=hourly'

Default: daily S3_STORAGE_CLASS | | | Specify the Amazon S3 storage class for files created by the changefeed. See Create a changefeed with an S3 storage class for the available classes and an example.

Default: STANDARD New in v23.1: sasl_client_id | | | Client ID for OAuth authentication from a third-party provider. This parameter is only applicable with sasl_mechanism=OAUTHBEARER. New in v23.1: sasl_client_secret | | | Client secret for OAuth authentication from a third-party provider. This parameter is only applicable with sasl_mechanism=OAUTHBEARER. Note: You must base64 encode this value when passing it in as part of a sink URI. sasl_enabled | | | If true, the authentication protocol can be set to SCRAM or PLAIN using the sasl_mechanism parameter. You must have tls_enabled set to true to use SASL.

Default: false New in v23.1: sasl_grant_type | | | Override the default OAuth client credentials grant type for other implementations. This parameter is only applicable with sasl_mechanism=OAUTHBEARER. sasl_mechanism | | | Can be set to OAUTHBEARER, SCRAM-SHA-256, SCRAM-SHA-512, or PLAIN. A sasl_user and sasl_password are required.

See the tutorial for detail setting up OAuth using Okta.

Default: PLAIN New in v23.1: sasl_scopes | | | A list of scopes that the OAuth token should have access for. This parameter is only applicable with sasl_mechanism=OAUTHBEARER. New in v23.1: sasl_token_url | | | Client token URL for OAuth authentication from a third-party provider. Note: You must URL encode this value before passing in a URI. This parameter is only applicable with sasl_mechanism=OAUTHBEARER. sasl_user | | | Your SASL username. sasl_password | | | Your SASL password. Note: Passwords should be URL encoded since the value can contain characters that would cause authentication to fail. tls_enabled | | | If true, enable Transport Layer Security (TLS) on the connection to Kafka. This can be used with a ca_cert (see below).

Default: false topic_name | , | | Allows arbitrary topic naming for Kafka and GC Pub/Sub topics. See the or for detail on supported characters etc.

For example, CREATE CHANGEFEED FOR foo,bar INTO 'kafka://sink?topic_name=all' will emit all records to a topic named all. Note that schemas will still be registered separately. When using Kafka, this parameter can be combined with the topic_prefix parameter (this is not supported for GC Pub/Sub).

Default: table name. topic_prefix | , | | Adds a prefix to all topic names.

For example, CREATE CHANGEFEED FOR TABLE foo INTO 'kafka://...?topic_prefix=bar_' would emit rows under the topic bar_foo instead of foo.

Options

Option	Value	Description
`avro_schema_prefix`	Schema prefix name	Provide a namespace for the schema of a table in addition to the default, the table name. This allows multiple databases or clusters to share the same schema registry when the same table name is present in multiple databases. Example: `CREATE CHANGEFEED FOR foo WITH format=avro, confluent_schema_registry='registry_url', avro_schema_prefix='super'` will register subjects as `superfoo-key` and `superfoo-value` with the namespace `super`.
`compression`	`gzip`, `zstd`	Compress changefeed data files written to a . For compression options when using a Kafka sink, see .
`confluent_schema_registry`	Schema Registry address	The Schema Registry address is required to use `avro`. Use the `timeout={duration}` query parameter (duration string) in your Confluent Schema Registry URI to change the default timeout for contacting the schema registry. By default, the timeout is 30 seconds. To connect to Confluent Cloud, use the following URL structure: `'https://{API_KEY_ID}:{API_SECRET_URL_ENCODED}@{CONFLUENT_REGISTRY_URL}:443'`. See the tutorial for further detail. Use the `changefeed.schema_registry.retry_count` metric to measure the number of request retries performed when sending requests to the schema registry. For more detail on monitoring changefeeds, refer to .
`cursor`		Emit any changes after the given timestamp. `cursor` does not output the current state of the table first. When `cursor` is not specified, the changefeed starts by doing an initial scan of all the watched rows and emits the current value, then moves to emitting any changes that happen after the scan. The changefeed will encounter an error if you specify a timestamp that is before the configured garbage collection window for the target table. (Refer to .) With default garbage collection settings, this means you cannot create a changefeed that starts more than in the past. You can use `cursor` to start a new changefeed where a previous changefeed ended. Example: `cursor='1536242855577149065.0000000000'`
`diff`	N/A	Publish a with each message, which includes the value of the row before the update was applied. Changefeeds must use the `diff` option with the default `wrapped` envelope to emit the `before` field.
`end_time`		Indicate the timestamp up to which the changefeed will emit all events and then complete with a `successful` status. Provide a future timestamp to `end_time` in number of nanoseconds since the Unix epoch. For example, `end_time="1655402400000000000"`. You cannot use `end_time` and `initial_scan = 'only'` simultaneously.
`envelope`	`wrapped` / `bare` / `key_only` / `row`	`wrapped` the default envelope structure for changefeed messages containing an array of the primary key, a top-level field for the type of message, and the current state of the row (or `null` for deleted rows). `bare` removes the `after` key from the changefeed message and stores any metadata in a `crdb` field. When used with `avro` format, `record` will replace the `after` key. Note: This is the default envelope format for . For an example, refer to . `key_only` emits only the key and no value, which is faster if you only need to know the key of the changed row. This envelope option is only supported for or sinkless changefeeds. `row` emits the row without any additional metadata fields in the message. This envelope option is only supported in or sinkless changefeeds. `row` does not support `avro` format. Refer to for more detail on message format. Default: `envelope=wrapped`. Default for : `envelope=bare`.
New in v23.1: `execution_locality`	Key-value pairs	Restricts the execution of a changefeed to nodes that match the defined locality filter requirements, e.g., `WITH execution_locality = 'region=us-west-1a,cloud=aws'`. Refer to for usage and reference detail. Note: Changefeeds that use the set to a could create a plan that assigns most of the ranges to an on the coordinator node. This leads to an unbalanced plan and slow changefeed progress, particularly when the table is large and has many ranges.
`format`	`json` / `avro` / `csv` / `parquet`	Format of the emitted message. `avro`: For mappings of CockroachDB types to Avro types, and detail on . Note: `confluent_schema_registry` is required with `format=avro`. `csv`: You cannot combine `format=csv` with the `diff` or `resolved` options. Changefeeds use the same CSV format as the statement. Refer to for details using these options to create a changefeed as an alternative to `EXPORT`. Note: `initial_scan = 'only'` is required with `format=csv`. `parquet`: This is in . Cloud storage is the only supported sink. The `topic_in_value` option is not compatible with `parquet` format. Default: `format=json`.
`full_table_name`	N/A	Use fully qualified table name in topics, subjects, schemas, and record output instead of the default table name. This can prevent unintended behavior when the same table name is present in multiple databases. Note: This option cannot modify existing table names used as topics, subjects, etc., as part of an statement. To modify a topic, subject, etc., to use a fully qualified table name, create a new changefeed with this option. Example: `CREATE CHANGEFEED FOR foo... WITH full_table_name` will create the topic name `defaultdb.public.foo` instead of `foo`.
New in v23.1: `gc_protect_expires_after`	Duration string	Automatically expires protected timestamp records that are older than the defined duration. In the case where a changefeed job remains paused, `gc_protect_expires_after` will trigger the underlying protected timestamp record to expire and cancel the changefeed job to prevent accumulation of protected data. Use with `protect_data_from_gc_on_pause` to limit the amount of time a changefeed job will remain paused protecting change data. See for more detail on protecting changefeed data.
`initial_scan`	`yes`/`no`/`only`	Control whether or not an initial scan will occur at the start time of a changefeed. Only one `initial_scan` option (`yes`, `no`, or `only`) can be used. If none of these are set, an initial scan will occur if there is no `cursor`, and will not occur if there is one. This preserves the behavior from previous releases. With `initial_scan = 'only'` set, the changefeed job will end with a successful status (`succeeded`) after the initial scan completes. You cannot specify `yes`, `no`, `only` simultaneously. If used in conjunction with `cursor`, an initial scan will be performed at the cursor timestamp. If no `cursor` is specified, the initial scan is performed at `now()`. Although the syntax from previous versions is still supported, you cannot combine the previous and current syntax. Default: `initial_scan = 'yes'`
`kafka_sink_config`		Set fields to configure the required level of message acknowledgement from the Kafka server, the version of the server, and batching parameters for Kafka sinks. Set the message file compression type. See for more detail on configuring all the available fields for this option. Example: `CREATE CHANGEFEED FOR table INTO 'kafka://localhost:9092' WITH kafka_sink_config='{"Flush": {"MaxMessages": 1, "Frequency": "1s"}, "RequiredAcks": "ONE"}'`
New in v23.1: `key_column`	`'column'`	Override the key used in . This changes the key hashed to determine downstream partitions. In sinks that support partitioning by message, CockroachDB uses the 32-bit FNV-1a hashing algorithm to determine which partition to send to. Note: `key_column` does not preserve ordering of messages from CockroachDB to the downstream sink, therefore you must also include the `unordered` option in your changefeed creation statement. It does not affect per-key or the output of `key_in_value`. See the Define a key to determine the changefeed sink partition example.
`key_in_value`	N/A	Add a primary key array to the emitted message. This makes the of a deleted row recoverable in sinks where each message has a value but not a key (most have a key and value in each message). `key_in_value` is automatically used for , , and .
`metrics_label`		Define a metrics label to which the metrics for one or multiple changefeeds increment. All changefeeds also have their metrics aggregated. The maximum length of a label is 128 bytes. There is a limit of 1024 unique labels. `WITH metrics_label=label_name` For more detail on usage and considerations, see .
`min_checkpoint_frequency`	Duration string	Controls how often a node’s changefeed will flush their progress to the . A node’s changefeed aggregator will wait at least the specified duration between sending progress updates for the ranges it is watching to the coordinator. This can help you control the flush frequency of higher latency sinks to achieve better throughput. However, more frequent checkpointing can increase CPU usage. If this is set to `0s`, a node will flush messages as long as the high-water mark has increased for the ranges that particular node is processing. If a changefeed is resumed, then `min_checkpoint_frequency` is the amount of time that changefeed will need to catch up. That is, it could emit during this time. Note: `resolved` messages will not be emitted more frequently than the configured `min_checkpoint_frequency` (but may be emitted less frequently). If you require `resolved` messages more frequently than `30s`, you must configure `min_checkpoint_frequency` to at least the desired `resolved` message frequency. For more details, refer to . Default: `30s`
`mvcc_timestamp`	N/A	Include the timestamp for each emitted row in a changefeed. With the `mvcc_timestamp` option, each emitted row will always contain its MVCC timestamp, even during the changefeed’s initial backfill.
`on_error`	`pause` / `fail`	Use `on_error=pause` to pause the changefeed when encountering non-retryable errors. `on_error=pause` will pause the changefeed instead of sending it into a terminal failure state. Note: Retryable errors will continue to be retried with this option specified. Use with `protect_data_from_gc_on_pause` to protect changes from . If a changefeed with `on_error=pause` is running when a watched table is , the changefeed will pause but will not be able to resume reads from that table. Using to drop the table from the changefeed and then will work, but you cannot add the same table to the changefeed again. Instead, you will need to create a new changefeed for that table. Default: `on_error=fail`
`protect_data_from_gc_on_pause`	N/A	When a , ensure that the data needed to is not garbage collected. If `protect_data_from_gc_on_pause` is unset, pausing the changefeed will release the existing protected timestamp records. It is also important to note that pausing and adding `protect_data_from_gc_on_pause` to a changefeed will not protect data if the window has already passed. Use with `on_error=pause` to protect changes from garbage collection when encountering non-retryable errors. See for more detail on protecting changefeed data. Note: If you use this option, changefeeds that are left paused for long periods of time can prevent garbage collection. Use with the `gc_protect_expires_after` option to set a limit for protected data and for how long a changefeed will remain paused.
New in v23.1: `pubsub_sink_config`		Set fields to configure sink batching and retries. The schema is as follows: `{ "Flush": { "Messages": ..., "Bytes": ..., "Frequency": ..., }, "Retry": {"Max": ..., "Backoff": ..., } }`. Note that if either `Messages` or `Bytes` are nonzero, then a non-zero value for `Frequency` must be provided. Refer to for more details on using this option.
`resolved`	Duration string	Emit in a format dependent on the connected sink. Resolved timestamps do not emit until the changefeed job’s progress has been checkpointed. Set a minimum amount of time that the changefeed’s high-water mark (overall resolved timestamp) must advance by before another resolved timestamp is emitted. Example: `resolved='10s'`. This option will only emit a resolved timestamp if the timestamp has advanced (and by at least the optional duration, if set). If a duration is unspecified, all resolved timestamps are emitted as the high-water mark advances. Note: If you set `resolved` lower than `30s`, then you must also set `min_checkpoint_frequency` to at minimum the same value as `resolved`, because `resolved` messages may be emitted less frequently than `min_checkpoint_frequency`, but cannot be emitted more frequently. Refer to for more detail.
`schema_change_events`	`default` / `column_changes`	The type of schema change event that triggers the behavior specified by the `schema_change_policy` option: `default`: Include all events for columns that have a non-`NULL` or are , and all events. `column_changes`: Include all schema change events that add or remove any column. Default: `schema_change_events=default`
`schema_change_policy`	`backfill` / `nobackfill` / `stop`	The behavior to take when an event specified by the `schema_change_events` option occurs: `backfill`: When are finished, output all watched rows using the new schema. `nobackfill`: For , perform no logical backfills. The changefeed will not emit any messages about the schema change. `stop`: For , wait for all data preceding the schema change to be resolved before exiting with an error indicating the timestamp at which the schema change occurred. An `error: schema change occurred at <timestamp>` will display in the `cockroach.log` file. Default: `schema_change_policy=backfill`
`split_column_families`	N/A	Use this option to create a changefeed on a table with multiple . The changefeed will emit messages for each of the table’s column families. See for more usage detail.
`topic_in_value`		Set to include the topic in each emitted row update. This option is automatically set for . Note: `topic_in_value` is not compatible with changefeeds running in `parquet` format.
New in v23.1: `unordered`	N/A	Run a changefeed to without specifying a region. You must include the `unordered` option with `key_column` in your changefeed creation statement. You cannot use `unordered` with `resolved`, because resolved timestamps may not be correct in unordered mode.
`updated`	N/A	Include updated timestamps with each row. If a `cursor` is provided, the “updated” timestamps will match the timestamps of the emitted rows, and there is no initial scan. If a `cursor` is not provided, the changefeed will perform an initial scan (as of the time the changefeed was created), and the “updated” timestamp for each change record emitted in the initial scan will be the timestamp of the initial scan. Similarly, when a , the “updated” timestamp is set to the first timestamp for when the new schema is valid.
`virtual_columns`	`STRING`	Changefeeds omit from emitted by default. To maintain the behavior of previous CockroachDB versions where the changefeed would emit values for virtual computed columns, set `virtual_columns = "null"` when you start a changefeed. You may also define `virtual_columns = "omitted"`, though this is already the default behavior for v22.1+. If you do not set `"omitted"` on a table with virtual computed columns when you create a changefeed, you will receive a warning that changefeeds will filter out virtual computed values. Default: `"omitted"`
`webhook_auth_header`		Pass a value (password, token etc.) to the HTTP Authorization header with a webhook request for a “Basic” HTTP authentication scheme. Example: With a username of “user” and password of “pwd”, add a colon between “user:pwd” and then base64 encode, which results in “dXNlcjpwd2Q=”. `WITH webhook_auth_header='Basic dXNlcjpwd2Q='`.
`webhook_client_timeout`		If a response is not recorded from the sink within this timeframe, it will error and retry to connect. Note this must be a positive value. Default: `"3s"`
`webhook_sink_config`		Set fields to configure sink batching and retries. The schema is as follows: `{ "Flush": { "Messages": ..., "Bytes": ..., "Frequency": ..., }, "Retry": {"Max": ..., "Backoff": ..., } }`. Note that if either `Messages` or `Bytes` are nonzero, then a non-zero value for `Frequency` must be provided. See for more details on using this option.

Using the format=avro, envelope=key_only, and updated options together is rejected. envelope=key_only prevents any rows with updated fields from being emitted, which makes the updated option meaningless.

Files

The files emitted to a sink use the following naming conventions:

General file format
Resolved file format

The timestamp format is YYYYMMDDHHMMSSNNNNNNNNNLLLLLLLLLL.

General file format

/[date]/[timestamp]-[uniquer]-[topic]-[schema-id]

For example:

/2020-04-02/202004022058072107140000000000000-56087568dba1e6b8-1-72-00000000-test_table-1.ndjson

When emitting changefeed messages to a , you can specify a partition format for your files using the partition_format query parameter. This will result in the following file path formats:

daily: This is the default option and will follow the same pattern as the previous general file format.
hourly: This will partition into an hourly directory as the changefeed emits messages, like the following:
/2020-04-02/20/202004022058072107140000000000000-56087568dba1e6b8-1-72-00000000-test_table-1.ndjson
flat: This will result in no file partitioning. The cloud storage path you specify when creating a changefeed will store all of the message files with no additional directories created.

Resolved file format

/[date]/[timestamp].RESOLVED

For example:

/2020-04-04/202004042351304139680000000000000.RESOLVED

Examples

Before running any of the examples in this section it is necessary to . If you are working on a CockroachDB Standard or Basic cluster, this cluster setting is enabled by default. The following examples show the syntax for managing changefeeds and starting changefeeds with different use cases and features. The Options table on this page provides a list of all the available options. For information on sink-specific query parameters and configurations, refer to the page. You can create an external connection to represent a changefeed sink URI. This allows you to specify the external connection’s name in statements rather than the provider-specific URI. For detail on using external connections, see the page. We recommend limiting the number of changefeeds per cluster to 80.

Create a changefeed connected to a sink

You can connect a changefeed to the following sinks:

Kafka
Cloud storage / HTTP
Google Cloud Pub/Sub
Webhook

CREATE CHANGEFEED FOR TABLE table_name, table_name2, table_name3
  INTO 'scheme://host:port'
  WITH updated, resolved;

For guidance on the sink URI, refer to:

The page for general detail on query parameters and sink configuration.
The page for instructions on setting up each supported cloud storage authentication.

Create a changefeed that filters and transforms change data

can filter and transform change data before emitting it to a sink or a SQL client. You can adapt a changefeed with CDC queries by including SELECT and WHERE clauses in your CREATE statement:

CREATE CHANGEFEED INTO 'scheme://host:port'
  WITH updated, resolved
  AS SELECT owner_id, status
  FROM vehicles
  WHERE status = 'lost';

CDC queries can only run on a single table per changefeed and require an Enterprise license.

Create a sinkless changefeed

You can create a changefeed that will send messages to the SQL client rather than a sink:

CREATE CHANGEFEED FOR TABLE table_name, table_name2, table_name3
  WITH updated, resolved;

Sinkless changefeeds do not require an Enterprise license; however, a sinkless changefeed with CDC queries does require an Enterprise license. To create a sinkless changefeed using CDC queries:

CREATE CHANGEFEED WITH updated, resolved
  AS SELECT owner_id, status
  FROM vehicles
  WHERE status = 'lost';

Use an external connection to specify a changefeed sink

provide a way to define a name for a sink, which you can use instead of the provider-specific URI. New in v23.1: To restrict a user’s access to changefeed data and sink credentials, enable the changefeed.permissions.require_external_connection_sink.enabled cluster setting. When you enable this setting, users with the CHANGEFEED privilege on a set of tables can only create changefeeds into external connections . External connections support all changefeed sinks.

CREATE EXTERNAL CONNECTION kafka_sink
  AS 'kafka://broker.address.com:9092?topic_prefix=bar_&tls_enabled=true&ca_cert={certificate}&sasl_enabled=true&sasl_user={sasl user}&sasl_password={url-encoded password}&sasl_mechanism=SCRAM-SHA-256';

In the changefeed statement, you specify the external connection name:

CREATE CHANGEFEED FOR TABLE table_name INTO 'external://kafka_sink'
  WITH resolved;

Disallow schema changes on tables to improve changefeed performance

New in v23.1.15: Use the schema_locked to disallow on a watched table, which helps to decrease the latency between a write committing to a table and it emitting to the . You can lock the table before creating a changefeed or while a changefeed is running, which will enable the performance improvement for changefeeds watching the particular table. Enable schema_locked on the watched table with the statement:

ALTER TABLE watched_table SET (schema_locked = true);

While schema_locked is enabled on a table, attempted schema changes on the table will be rejected and an error returned. If you need to run a schema change on the locked table, unlock the table with schema_locked = false, complete the schema change, and then lock the table again with schema_locked = true. The changefeed will run as normal while schema_locked = false, but it will not benefit from the performance optimization.

ALTER TABLE watched_table SET (schema_locked = false);

Manage a changefeed

For Enterprise changefeeds, use to check the status of your changefeed jobs:

SHOW CHANGEFEED JOBS;

Use the following SQL statements to pause, resume, or cancel a changefeed.

Pause a changefeed

PAUSE JOB job_id;

For more information, see .

Resume a paused changefeed

RESUME JOB job_id;

For more information, see .

Cancel a changefeed

CANCEL JOB job_id;

For more information, see .

Modify a changefeed

To modify an Enterprise changefeed, the job and then use:

ALTER CHANGEFEED job_id [ADD table] [DROP table] [SET option] [UNSET option];

You can add new table targets, remove them, set new , and unset them. For more information, see .

Configuring all changefeeds

It is useful to be able to pause all running changefeeds during troubleshooting, testing, or when a decrease in CPU load is needed. To pause all running changefeeds:

PAUSE JOBS (WITH x AS (SHOW CHANGEFEED JOBS) SELECT job_id FROM x WHERE status = ('running'));

This will change the status for each of the running changefeeds to paused, which can be verified with . To resume all running changefeeds:

RESUME JOBS (WITH x AS (SHOW CHANGEFEED JOBS) SELECT job_id FROM x WHERE status = ('paused'));

This will resume the changefeeds and update the status for each of the changefeeds to running.

Start a new changefeed where another ended

In some situations, you may want to start a changefeed where a previously running changefeed ended. For example, a changefeed could encounter an error it cannot recover from, such as when a , and you need to restart the changefeed.

Use to find the for the ended changefeed:

SHOW CHANGEFEED JOB {job_id};

        job_id       | ... |      high_water_timestamp      | ...
+--------------------+ ... +--------------------------------+ ...
  383870400694353921 | ... | 1537279405671006870.0000000000 | ...
(1 row)

If a changefeed has failed, you must restart the changefeed from a timestamp after the event that caused the failure.

Use the high_water_timestamp to start the new changefeed:

CREATE CHANGEFEED FOR TABLE table_name, table_name2, table_name3
  INTO 'scheme//host:port'
  WITH cursor = '<high_water_timestamp';

When you use the cursor option to start a changefeed, it will not perform an initial scan.

Create a changefeed with an S3 storage class

To associate the changefeed message files with a in your Amazon S3 bucket, use the S3_STORAGE_CLASS parameter with the class. For example, the following S3 connection URI specifies the INTELLIGENT_TIERING storage class:

CREATE CHANGEFEED FOR TABLE table_name
  INTO 's3://{BUCKET NAME}?AWS_ACCESS_KEY_ID={KEY ID}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}&S3_STORAGE_CLASS=INTELLIGENT_TIERING'
  WITH resolved;

Use the parameter to set one of these storage classes listed in Amazon’s documentation. For more general usage information, see Amazon’s Using Amazon S3 storage classes documentation.

Define a key to determine the changefeed sink partition

New in v23.1: With the key_column option, you can define the key used in message metadata that determines the partition for the changefeed message at your . This option overrides the default :

CREATE CHANGEFEED FOR TABLE table_name
  INTO 'external://kafka-sink'
  WITH key_column='partition_column', unordered;

key_column does not preserve ordering of messages from CockroachDB to the downstream sink, therefore you must include the unordered option. It does not affect per-key or the output of key_in_value.

Statements

Syntax

Data Types

Spatial Data

Constraints

Required privileges

Privilege model

Synopsis

Parameters

Parameters for change data capture queries

Sink URI

Kafka

Google Cloud Pub/Sub

Cloud Storage

Webhook

Query parameters

Options

Files

General file format

Resolved file format

Examples

Create a changefeed connected to a sink

Create a changefeed that filters and transforms change data

Create a sinkless changefeed

Use an external connection to specify a changefeed sink

Disallow schema changes on tables to improve changefeed performance

Manage a changefeed

Pause a changefeed

Resume a paused changefeed

Cancel a changefeed

Modify a changefeed

Configuring all changefeeds

Start a new changefeed where another ended

Create a changefeed with an S3 storage class

Define a key to determine the changefeed sink partition

See also

​Required privileges

​Privilege model

​Synopsis

​Parameters

​Parameters for change data capture queries

​Sink URI

​Kafka

​Google Cloud Pub/Sub

​Cloud Storage

​Webhook

​Query parameters

​Options

​Files

​General file format

​Resolved file format

​Examples

​Create a changefeed connected to a sink

​Create a changefeed that filters and transforms change data

​Create a sinkless changefeed

​Use an external connection to specify a changefeed sink

​Disallow schema changes on tables to improve changefeed performance

​Manage a changefeed

​Pause a changefeed

​Resume a paused changefeed

​Cancel a changefeed

​Modify a changefeed

​Configuring all changefeeds

​Start a new changefeed where another ended

​Create a changefeed with an S3 storage class

​Define a key to determine the changefeed sink partition

​See also

Required privileges

Privilege model

Synopsis

Parameters

Parameters for change data capture queries

Sink URI

Kafka

Google Cloud Pub/Sub

Cloud Storage

Webhook

Query parameters

Options

Files

General file format

Resolved file format

Examples

Create a changefeed connected to a sink

Create a changefeed that filters and transforms change data

Create a sinkless changefeed

Use an external connection to specify a changefeed sink

Disallow schema changes on tables to improve changefeed performance

Manage a changefeed

Pause a changefeed

Resume a paused changefeed

Cancel a changefeed

Modify a changefeed

Configuring all changefeeds

Start a new changefeed where another ended

Create a changefeed with an S3 storage class

Define a key to determine the changefeed sink partition

See also