Confluent Kafka Connect Connectors
Connectors
- Landoop mqtt source connector
- Confluent mqtt source connector
The connector requires a Confluent enterprise license, which is stored inside Kafka in a topic. The connector must be configured with Kafka client configuration properties so that it can connect to Kafka and validate the license.
- Evokly open source mqtt connector
https://github.com/evokly/kafka-connect-mqtt
MongoDB
- Debezium MongoDB Source Connector for Confluent Platform | Confluent Documentation
- Debezium’s MongoDB connector can monitor a MongoDB replica set or a MongoDB sharded cluster for document changes in databases and collections, recording those changes as events in Apache Kafka® topics. The connector automatically handles the addition or removal of shards in a sharded cluster, changes in membership of each replica set, elections within each replica set, and dynamically adjusts when communication issues occur.
- The Debezium MongoDB connector uses MongoDB’s oplog to capture changes. Since it makes use of MongoDB’s replication mechanism, the connector works only with MongoDB replica sets or sharded clusters.
- The Debezium MongoDB connector is not capable of monitoring the changes of a standalone MongoDB server, since standalone servers do not have an oplog. The connector will work if the standalone server is converted to a replica set with one member.
- MongoDB Atlas Source Connector for Confluent Cloud Quick Start | Confluent Documentation
- The fully-managed MongoDB Atlas Source connector for Confluent Cloud moves data from a MongoDB replica set into an Apache Kafka® cluster. The connector configures and consumes change stream event documents and publishes them to a Kafka topic.
Debezium MongoDB Connector vs MongoDB Atlas Source Connector
For a self-managed MongoDB cluster, choose based primarily on where Kafka Connect runs and the CDC event format you need.
| Area | Debezium MongoDB connector | MongoDB Atlas Source connector |
|---|---|---|
| Deployment | Self-managed Kafka Connect plugin on Confluent Platform, Kubernetes, or VMs. | Fully managed in Confluent Cloud; it can connect to self-managed MongoDB using MONGODB_SELF_MANAGED. |
| CDC mechanism | Debezium CDC based on MongoDB replica-set/sharded-cluster change capture and oplog. | MongoDB Change Streams using resume tokens. |
| MongoDB topology | Supports replica sets and sharded clusters; not standalone MongoDB servers. | Supports self-managed MongoDB, provided the cluster is reachable from Confluent Cloud. |
| Event format | Debezium envelope: typically before, after, op, source, and timestamps. | MongoDB change-stream documents, or optionally full documents. |
| Operations | You manage Kafka Connect, plugin installation, upgrades, monitoring, networking, and offsets. | Confluent manages the connector runtime and offset management. |
| Scaling | Debezium MongoDB supports one task per connector in the Confluent Platform connector documentation. | The Atlas source connector also supports one task; increasing tasks.max does not horizontally scale it. |
| Support model | Confluent supports specific Debezium-built versions on Confluent Platform; Debezium itself is open source. | Fully managed and supported as a Confluent Cloud connector; the underlying connector is MongoDB-maintained. |
| Aspect | MongoDbAtlasSource | MongoDbCdcSource |
|---|---|---|
| Underlying connector | Official MongoDB Kafka Connector | Debezium MongoDB connector |
| Template ID | MongoDbAtlasSource | MongoDbCdcSource |
| Best suited for | Simple MongoDB/Atlas CDC and document replication | Enterprise CDC pipelines requiring Debezium semantics |
| Snapshot modes | latest, timestamp, copy_existing | initial, always, never, no_data, when_needed, initial_only |
| Incremental snapshots | Not supported | Supported through signals |
| Output | Raw change-stream event or full document | Debezium envelope with before, after, source, op, and ts_ms |
| Filtering | One database/collection plus aggregation pipeline | Database/collection include/exclude lists and field filtering/renaming |
| Output formats | Avro, JSON_SR, Protobuf, JSON, String, BSON | Avro, JSON_SR, Protobuf, JSON |
| Parallelism | Configurable tasks.max | Maximum one task |
| Topic naming | More flexible namespace mapping, suffix, and separators | Standard topic.prefix-based naming |
| Heartbeats | Not exposed | Supported |
| Authentication | SCRAM-SHA-256 and X.509 | SCRAM and AWS IAM for Atlas |
| Maintenance | MongoDB Kafka Connector | Debezium-based connector |
Recommendation
- Use Debezium if you need the standard Debezium event envelope, Debezium-compatible downstream consumers, detailed CDC semantics, or you are already running Kafka Connect yourself.
- Use the MongoDB Atlas Source connector if your Kafka cluster is in Confluent Cloud and you want the lowest operational overhead—even though the MongoDB database is self-managed.
- If you need hard-delete/tombstone handling, before/after semantics, or consistency with Debezium connectors for PostgreSQL/MySQL, Debezium is generally the better fit.
- If you need a simpler MongoDB-native change-stream representation and managed operations, choose the Atlas connector.
- Important: "Atlas Source connector" does not necessarily mean the database must be MongoDB Atlas—the Confluent Cloud connector supports self-managed MongoDB with a standard host/port connection string.
Which one should you choose?
Choose MongoDbAtlasSource when you need:
- Straightforward MongoDB change-stream ingestion.
- BSON or String output.
- Aggregation-pipeline filtering.
- Multiple connector tasks.
- Flexible topic naming.
- X.509 authentication.
Choose MongoDbCdcSource when you need:
- A standard Debezium event envelope.
- Incremental or signal-based snapshots.
- Consistent CDC semantics across MongoDB, MySQL, PostgreSQL, and other Debezium connectors.
- Field-level filtering or renaming.
- Heartbeats and Debezium-specific metrics.
- AWS IAM authentication for MongoDB Atlas.
SQL Server Connector
The fully-managed Microsoft SQL Server Change Data Capture (CDC) Source V2 (Debezium) connector for Confluent Cloud streams row-level changes from a Microsoft SQL Server database into Apache Kafka® topics, using the Debezium engine internally. The connector can also take an initial snapshot of existing data before streaming subsequent INSERT, UPDATE, and DELETE changes. Each table’s events are recorded to a separate Kafka topic, and the connector supports Avro, JSON Schema, Protobuf, or JSON (schemaless) output formats.
V2 Improvements
- Supports capturing changes from multiple databases on a single SQL Server database engine using a single connector instance and multiple tasks. You must configure the
database.namesproperty with a comma-separated list of databases and settasks.maxto match the number of databases. Each task handles one database, so increasingtasks.maxbeyond the number of databases provides no additional performance benefit. - Heartbeat events are emitted even if the connector does not find any changes or the changes that did occur are not of relevance to the connector.
- Can stop or pause an in-progress incremental snapshot. Can resume the incremental snapshot if it was previously been paused.
- Supports regular expressions to specify table names for incremental snapshots.
- Supports SQL-based predicates to control the subset of records to be included in the incremental snapshot.
- Supports specifying a single column as a surrogate key for performing incremental snapshots.
- Can perform ad-hoc blocking snapshots.
- Indices that rely on hidden, auto-generated columns, or columns wrapped in database functions are no longer considered primary key alternatives for tables that do not have a primary key defined.
- Configuration options to specify how topic and schema names should be adjusted for compatibility.
Microsoft SQL Server Source (JDBC) vs Microsoft SQL Server CDC Source V2 (Debezium)
Microsoft SQL Server Source Connector for Confluent Cloud Quick Start | Confluent Documentation
Use Microsoft SQL Server Source (JDBC) when you want periodic table polling/snapshots; use Microsoft SQL Server CDC Source V2 (Debezium) when you need true change data capture with inserts, updates, and deletes from SQL Server CDC. The CDC V2 connector is the strategic choice for ongoing replication and low-latency change streaming.
Key difference
The SQL Server Source (JDBC) connector captures an initial snapshot and then monitors tables for subsequent row-level changes, but its docs explicitly note that deleted records are not captured.
The SQL Server CDC Source V2 (Debezium) connector uses SQL Server CDC, can take an initial snapshot, and then streams subsequent INSERT, UPDATE, and DELETE changes.
When to choose which
| Use case | Better connector | Why |
|---|---|---|
| Full CDC, including deletes | SQL Server CDC Source V2 (Debezium) | Streams row-level CDC events from SQL Server CDC. |
| Simpler polling-style ingestion | SQL Server Source (JDBC) | Simpler source connector flow, but not full CDC semantics. |
| Multi-database capture from one SQL Server engine | SQL Server CDC Source V2 (Debezium) | V2 supports database.names with one task per DB. |
| Lowest-latency operational replication | SQL Server CDC Source V2 (Debezium) | Built around CDC log/change-table consumption and heartbeat support. |
| Source DB cannot enable CDC | SQL Server Source (JDBC) | CDC V2 requires SQL Server CDC to be enabled. |
Important details
The CDC V2 connector supports SQL Server versions 2017, 2019, and 2022.
It also supports multiple databases, heartbeat emission even with no relevant changes, and richer incremental snapshot controls like pause/resume and regex/predicate-based selection.
The legacy SQL Server CDC Source (Debezium) v1 reached end of life on March 31, 2026, and Confluent recommends migrating to CDC Source V2.
One caveat: CDC V2 does not currently support Active Directory authentication in Confluent Cloud.
Practical recommendation
For almost all new production builds, choose Microsoft SQL Server CDC Source V2 (Debezium).
Choose Microsoft SQL Server Source (JDBC) only if you specifically want a simpler non-CDC connector model or cannot enable SQL Server CDC.