Protobuf type datastores - connect_cdc_sqdata - Latest

Connect CDC (SQData) Apply engine

Product type
Software
Portfolio
Integrate
Product family
Connect
Product
Connect > Connect CDC (SQData)
Version
Latest
ft:locale
en-US
Product name
Connect CDC (SQData)
ft:title
Connect CDC (SQData) Apply engine
Copyright
2026
First publish date
2000
ft:lastEdition
2026-08-24
ft:lastPublication
2026-08-24T13:31:43.482000
L1_Product_Gateway
Integrate
L2_Product_Segment
Data Integration
L3_Product_Brand
Precisely Connect
L4_Investment_Segment
Application Data Integration
L5_Product_Group
ADI - Connect
L6_Product_Name
Connect CDC
Table 1. Changes in this topic
Change type Description
Introduced in version 5.0.6 Describes Protobuf type datastores, including syntax, FORMAT options, and keyword descriptions.

Protobuf (Protocol Buffers) formatted datastores use a compact binary serialization format developed by Google. Like AVRO, Protobuf separates schema from data and integrates with a Confluent Schema Registry. Protobuf offers two advantages over AVRO and JSON:

  1. Protobuf payloads are smaller than AVRO payloads and significantly smaller than JSON payloads. Binary encoding produces a more compact representation than either text-based JSON or the schema-and-data structure of AVRO.
  2. Protobuf serialization and deserialization is faster than both JSON and AVRO, improving throughput in high-volume streaming environments.

Schemas are automatically generated from source record definitions and registered in the Confluent Schema Registry at parse time. A Confluent Schema Registry is always required for Protobuf targets; there is no schema-registry-free Protobuf option.

Protobuf field names automatically preserve their original case from the source definition. The USE AVRO COMPATIBLE NAMES option is specific to AVRO and JSON targets and has no effect on Protobuf datastores.

Note: For the equivalent AVRO configuration, see AVRO type datastores. For Protobuf data type mappings, see Protobuf type mapping.
Example
------------------------------------------------------------
--       DATASTORE SECTION
------------------------------------------------------------
-- SOURCE DATASTORE
DATASTORE cdc://server:port/capture/target
          OF UTSCDC
          AS CDCIN
          DESCRIBED BY GROUP SOURCE_TABLES;

-- TARGET DATASTORE
DATASTORE kafka://[<hostname>[:<port_number>]] / [<kafka_topic_id>][/ | /<partition> | /key | /root_key]
          OF PROTOBUF FORMAT CONFLUENT [TOMBSTONE]
          AS TARGET
          KEY IS DEPTNO, MGRNO
          KEY SUBJECT <kafka_topic_id>-key
          DESCRIBED BY GROUP SOURCE_TABLES;
Keyword and parameter descriptions
Keyword Description
kafka://[<hostname>[:<port_number>]] / [<kafka_topic_id>] [/ | /<partition> | /key | /root_key] URL syntax that specifies a Kafka target. Optionally identifies a Kafka broker host name, TCP/IP port, topic ID, and partition. See Kafka datastores for URL options including broker list specification, dynamic topic IDs, and key-based partitioning.
OF PROTOBUF

Specifies that the target datastore uses Protobuf binary serialization. Schemas are automatically generated from source record definitions and registered in a Confluent Schema Registry. A FORMAT clause is required.

AS <datastore_alias> Specifies the alias name of the datastore. All references to this datastore in the Apply Engine script use this alias name. The convention TARGET is commonly used for the primary output datastore.
DESCRIBED BY GROUP <group_name> Specifies the group name previously defined by a BEGIN GROUP command that contains one or more DESCRIPTION entries.
FORMAT CONFLUENT [TOMBSTONE]

Specifies the schema registration and message encoding mode. Protobuf supports only Confluent Schema Registry modes:

  • CONFLUENT — Schemas are automatically registered in the Confluent Schema Registry. Each message is prefixed with a Confluent wire format header containing the magic byte (0x00), schema ID, and message index path.
  • CONFLUENT TOMBSTONE — Same as CONFLUENT, with the addition of tombstone support. DELETE operations produce a null-value message with a key-only payload, supporting log compaction in Kafka.