Which Debezium connector class do you configure for a MySQL, PostgreSQL, MongoDB or SQL Server source?

## What `connector.class` selects Debezium is not a single connector with a driver setting. It is a family of independent connector implementations, each packaged as a plugin and each written against one database engine's change mechanism. The `connector.class` property in a connector configuration names the Java class to instantiate, and that single line determines which log Debezium reads, which prerequisites the DBA must satisfy, and which source-specific properties are legal in the rest of the config. ## The per-source classes - **MySQL** — `io.debezium.connector.mysql.MySqlConnector`. Connects as a replication client and reads the binary log. - **PostgreSQL** — `io.debezium.connector.postgresql.PostgresConnector`. Opens a logical replication slot and decodes changes through an output plugin (`plugin.name`, commonly `pgoutput`, which ships with the server). - **MongoDB** — `io.debezium.connector.mongodb.MongoDbConnector`. Consumes change streams from a replica set or sharded cluster, configured with `mongodb.connection.string`. - **SQL Server** — `io.debezium.connector.sqlserver.SqlServerConnector`. Reads the CDC change tables that SQL Server's own capture agent fills from the transaction log, so it is one step removed from the log itself. Others exist — Oracle, Db2, Cassandra, Vitess, Spanner — with the same naming shape. Knowing the shape matters more than reciting the strings: it is always `io.debezium.connector.<engine>.<Engine>Connector`. ## The shared vocabulary Whatever the source, a Debezium configuration looks broadly the same. `topic.prefix` gives the connector a logical name that becomes the namespace for its topics. `database.hostname`, `database.port`, `database.user` and `database.password` describe the connection. `table.include.list` and `table.exclude.list` scope what is captured; `column.include.list` and `column.exclude.list` scope the fields. `heartbeat.interval.ms` keeps offsets moving on quiet sources. Value-shaping options such as `decimal.handling.mode` and `time.precision.mode` behave consistently across engines. That commonality is Debezium's main selling point: one operational model over four or more very different databases. ## Where the connectors genuinely differ The differences that break deployments are on the database side, not in the connector config. **MySQL** needs `binlog_format=ROW` and `binlog_row_image=FULL` — with statement-based logging there are no before/after row images to emit — plus a user granted `SELECT`, `RELOAD`, `SHOW DATABASES`, `REPLICATION SLAVE` and `REPLICATION CLIENT`, and a `database.server.id` that no other replication client uses. Binlog retention on the server sets how long a stopped connector can stay stopped before its position is gone. **PostgreSQL** needs `wal_level=logical`, a role with the `REPLICATION` attribute, and a slot (`slot.name`) plus a publication (`publication.name`). One connector covers one database, named by `database.dbname`. The slot is the operational hazard: it pins write-ahead log until the connector confirms consumption. **SQL Server** needs CDC enabled at the database level and then per table, via the system stored procedures `sys.sp_cdc_enable_db` and `sys.sp_cdc_enable_table`, with SQL Server Agent running to keep the capture job alive. Databases are listed in `database.names`. **MongoDB** needs a replica set (change streams do not exist on a standalone server) and a user allowed to read the oplog/change stream. ## What downstream consumers see The change-event shape is deliberately uniform across connectors, which is why a sink written for one source usually works for another. The engine-specific detail surfaces inside the event's source metadata block: MySQL reports a binlog file and position, Postgres an LSN, SQL Server a change LSN, MongoDB a resume token. If you build tooling that reasons about source position — lag dashboards, replay logic — that block is where the portability stops. ## Practical rules One connector instance covers one source database (one Postgres database, one MySQL server's selected schemas). Two connectors against the same server must differ in every identity-bearing property: distinct `topic.prefix`, distinct slot and publication names on Postgres, distinct `database.server.id` on MySQL. Getting the class right is the easy part; the interview usually moves straight to the prerequisites, because that is where real deployments stall.