Sink URI
The sink URI follows the basic format of:
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.
To set a different sink URI to an existing changefeed, use the with
ALTER CHANGEFEED.
Cockroach Labs recommends enabling Egress Perimeter Controls on CockroachDB Advanced clusters to mitigate the risk of data exfiltration when accessing external resources, such as cloud storage for change data capture or backup and restore operations. See for detail and setup instructions.
Kafka
Kafka sink connection
Example of a Kafka sink URI usingSCRAM-SHA-256 authentication:
OAUTHBEARER authentication:
This table shows the parameters for changefeeds to a specific sink. The
CREATE CHANGEFEED page provides a list of all the available .
Topic naming
By default, a Kafka topic has the same name as the table on which a changefeed was created. If you create a changefeed on multiple tables, the changefeed will write to multiple topics corresponding to those table names. When you runCREATE CHANGEFEED to a Kafka sink, the output will display the job ID as well as the topic name(s) that the changefeed will emit to.
To modify the default topic naming, you can specify a , , or use the . Using the parameter, you can specify an arbitrary topic name and feed all tables into that topic.
You can either manually create a topic in your Kafka cluster before starting the changefeed, or the topic will be automatically created when the changefeed connects to your Kafka cluster.
You must have the Kafka cluster setting
auto.create.topics.enable set to true for automatic topic creation. This will create the topic when the changefeed sends its first message. If you create the consumer before that, you will also need the Kafka consumer configuration allow.auto.create.topics to be set to true.- Legal characters are numbers, letters, and
[._-]. - The maximum character length of a topic name is 249.
- Topics with a period (
.) and underscore (_) can collide on internal Kafka data structures, so you should use either but not both. - Characters not accepted by Kafka will be automatically encoded as unicode characters by CockroachDB.
Kafka sink configuration
Thekafka_sink_config option allows configuration of a changefeed’s message delivery, Kafka server version, and batching parameters.
Each of the following settings have significant impact on a changefeed’s behavior, such as latency. For example, it is possible to configure batching parameters to be very high, which would negatively impact changefeed latency. As a result it would take a long time to see messages coming through to the sink. Also, large batches may be rejected by the Kafka server unless it’s separately configured to accept a high
max.message.bytes."Flush"."MaxMessages" and "Flush"."Frequency" are configurable batching parameters depending on latency and throughput needs. For example, if "MaxMessages" is set to 1000 and "Frequency" to 1 second, it will flush to Kafka either after 1 second or after 1000 messages are batched, whichever comes first. It’s important to consider that if there are not many messages, then a "1s" frequency will add 1 second latency. However, if there is a larger influx of messages these will be flushed quicker.
Using the default values or not setting fields in kafka_sink_config will mean that changefeed messages emit immediately.
The configurable fields are as follows:
Kafka sink messages
The following shows the messages for a changefeed emitting to Kafka:Google Cloud Pub/Sub
This feature is in and subject to change. To share feedback and/or issues, contact Support.
changefeed.new_pubsub_sink_enabled to improve the throughput of changefeeds emitting to Pub/Sub sinks. Enabling this setting also alters the message format to use capitalized top-level fields in changefeeds emitting JSON-encoded messages. Therefore, you may need to reconfigure downstream systems to parse the new message format before enabling this setting:
This table shows the parameters for changefeeds to a specific sink. The
CREATE CHANGEFEED page provides a list of all the available .
When using Pub/Sub as your downstream sink, consider the following:
- Pub/Sub sinks support
JSONmessage format. You can use the option in combination with for CSV-formatted messages. - Use the option for multi-region Pub/Sub. Google Cloud’s multi-region Pub/Sub will have lower latency when emitting from multiple regions, but Google Cloud Pub/Sub does not support message ordering for multi-region topics.
- Changefeeds connecting to a Pub/Sub sink do not support the
topic_prefixoption.
- To create topics on changefeed creation, you must use the Pub/Sub Editor role, which contains the permissions to create a topic.
- If the topic the changefeed is writing to already exists, then you can use the more limited Pub/Sub Publisher role, which can only write to existing topics.
You can use Google’s Pub/Sub emulator, which allows you to run Pub/Sub locally for testing. CockroachDB uses the Google Cloud SDK, which means that you can follow Google’s instructions for Setting environment variables to run the Pub/Sub emulator.
Pub/Sub topic naming
When running aCREATE CHANGEFEED statement to a Pub/Sub sink, consider the following regarding topic names:
- Changefeeds will try to create a topic automatically. When you do not specify the topic in the URI with the parameter, the changefeed will use the table name to create the topic name.
- If the topic already exists in your Pub/Sub sink, the changefeed will write to it.
- Changefeeds watching multiple tables will write to multiple topics corresponding to those table names.
- The option will create a topic using the fully qualified table name for each table the changefeed is watching.
- The output from
CREATE CHANGEFEEDwill display the job ID as well as the topic name(s) to which the changefeed will emit.
CREATE CHANGEFEED page.
Pub/Sub sink configuration
You can configure flushing, retry, and concurrency behavior of changefeeds running to a Pub/Sub sink with the following:- If you have enabled
changefeed.new_pubsub_sink_enabled, set the to configure the number of concurrent workers used by changefeeds in the cluster when sending requests to a Pub/Sub sink. When you setchangefeed.sink_io_workers, it will not affect running changefeeds; , setchangefeed.sink_io_workers, and then . Settingchangefeed.sink_io_workerswill also affect changefeeds emitting to webhook sinks whenchangefeed.new_webhook_sink_enabledis set totrue. - Set the
pubsub_sink_configoption to configure the changefeed flushing and retry behavior to your webhook sink. For details on thepubsub_sink_configoption’s configurable fields, refer to the following table and examples.
For example:
Setting either
Messages or Bytes with a non-zero value without setting Frequency will cause the sink to assume Frequency has an infinity value. If either Messages or Bytes have a non-zero value, then a non-zero value for Frequency must be provided. This configuration is invalid and will cause an error, since the messages could sit in a batch indefinitely if the other conditions do not trigger.Flush fields for batching:
-
When all batching parameters are zero (
"Messages","Bytes", and"Frequency") the sink will interpret this configuration as “send batch every time a message is available.” This would be the same as not providing any configuration at all: -
If one or more fields are set as non-zero values, any fields with a zero value the sink will interpret as infinity. For example, in the following configuration, the sink will send a batch whenever the size reaches 100 messages, or, when 5 seconds has passed since the batch was populated with its first message.
Bytesis unset, so the batch size is unlimited. No flush will be triggered due to batch size:
Pub/Sub sink messages
In CockroachDB v23.2 and later, changefeeds will have
changefeed.new_pubsub_sink_enabled enabled by default.changefeed.new_pubsub_sink_enabled cluster setting is enabled, changefeeds will have improved throughput and the changefeed JSON-encoded message format has top-level fields that are capitalized:
Before enabling
changefeed.new_pubsub_sink_enabled, you may need to reconfigure downstream systems to parse the new message format.changefeed.new_pubsub_sink_enabled set to false, changefeeds emit JSON messages with the top-level fields all lowercase:
changefeed.new_pubsub_sink_enabled is set to false, changefeeds will not benefit from the improved throughput performance that this setting enables.
The following shows the default JSON messages for a changefeed created with changefeed.new_pubsub_sink_enabled set to false. These changefeed messages were emitted as part of the example:
Cloud storage sink
Use a cloud storage sink to deliver changefeed data to OLAP or big data systems without requiring transport via Kafka. Some considerations when using cloud storage sinks:- Cloud storage sinks work with
JSONand emit newline-delimitedJSONfiles. You can use the option in combination with for CSV-formatted messages. - Cloud storage sinks can be configured to store emitted changefeed messages in one or more subdirectories organized by date. See file partitioning and the examples.
- The supported cloud schemes are:
s3,gs,azure,http, andhttps. - Both
http://andhttps://are cloud storage sinks, not webhook sinks. It is necessary to prefix the scheme withwebhook-for webhook sinks.
specified or implicit authentication. CockroachDB also supports assume role authentication for Amazon S3 and Google Cloud Storage, which allows you to limit the control specific users have over your storage buckets. For detail and instructions on authenticating to cloud storage sinks, see .
Examples of supported cloud storage sink URIs:
Amazon S3
Azure Blob Storage
Google Cloud Storage
HTTP
Cloud storage parameters
The following table lists the available parameters for cloud storage sink URIs:
For example:
CREATE CHANGEFEED FOR TABLE users INTO 'gs://...?AUTH...&partition_format=hourly' Default:
daily
S3_STORAGE_CLASS | AWS S3 | Specify the S3 storage class for files created by the changefeed. See for the available classes and an example. Default:
STANDARD
topic_prefix | All | Adds a prefix to all topic names.For example,
CREATE CHANGEFEED FOR TABLE foo INTO 's3://...?topic_prefix=bar_' would emit rows under the topic bar_foo instead of foo.
This table shows the parameters for changefeeds to a specific sink. The CREATE CHANGEFEED page provides a list of all the available .
provides more detail on authentication to cloud storage sinks.
Cloud storage sink messages
The following shows the default JSON messages for a changefeed emitting to a cloud storage sink:Webhook sink
New in v23.1: Enable the
changefeed.new_webhook_sink_enabled to improve the throughput of changefeeds emitting to webhook sinks. .
This table shows the parameters for changefeeds to a specific sink. The
CREATE CHANGEFEED page provides a list of all the available .
The following are considerations when using the webhook sink:
- Only supports HTTPS. Use the parameter when testing to disable certificate verification; however, this still requires HTTPS and certificates.
- Supports JSON output format. You can use the option in combination with for CSV-formatted messages.
Webhook sink configuration
You can configure flushing, retry, and concurrency behavior of changefeeds running to a webhook sink with the following:- If you have enabled
changefeed.new_webhook_sink_enabled, set the to configure the number of concurrent workers used by changefeeds in the cluster when sending requests to a webhook sink. When you setchangefeed.sink_io_workers, it will not affect running changefeeds; , setchangefeed.sink_io_workers, and then . Settingchangefeed.sink_io_workerswill also affect changefeeds emitting to Google Cloud Pub/Sub sinks whenchangefeed.new_pubsub_sink_enabledis set totrue. - Set the
webhook_sink_configoption to configure the changefeed flushing and retry behavior to your webhook sink. For details on thewebhook_sink_configoption’s configurable fields, refer to the following table and examples.
For example:
Messages or Bytes with a non-zero value without setting Frequency will cause the sink to assume Frequency has an infinity value. If either Messages or Bytes have a non-zero value, then a non-zero value for Frequency must be provided. This configuration is invalid and will cause an error, since the messages could sit in a batch indefinitely if the other conditions do not trigger.
Some complexities to consider when setting Flush fields for batching:
-
When all batching parameters are zero (
"Messages","Bytes", and"Frequency") the sink will interpret this configuration as “send batch every time a message is available.” This would be the same as not providing any configuration at all: -
If one or more fields are set as non-zero values, any fields with a zero value the sink will interpret as infinity. For example, in the following configuration, the sink will send a batch whenever the size reaches 100 messages, or, when 5 seconds has passed since the batch was populated with its first message.
Bytesis unset, so the batch size is unlimited. No flush will be triggered due to batch size:

