Debezium (CDC): MongoDB
Asset Type:
Provider: Solace
Data Warehouse/Processing
Solace – Included

Debezium (CDC): MongoDB

The PubSub+ Connector for Debezium (CDC) has been built to “event-enable” data from your operational databases by publishing the changes (inserts, updates, deletes, etc.) to a PubSub+ Event Broker and your event mesh. The opens up that data to your modern applications built on an event-driven architecture (EDA).

The Debezium MongoDB connector is a wrapper around Debezium using Debezium Engine, which enables Change Data Capture from MongoDB databases using Debezium.

The connector uses the Debezium open source project ( to perform the CDC on a variety of databases and streams the data to a PubSub+ destination using “workflows”. A workflow is a source-to-processing-to-target data pipeline configured within the connector runtime. Each workflow (you can have up to 20 defined per connector instance) defines which table(s) will be used for the change stream, any header processing necessary, and the PubSub+ broker destination will be sent those changes.

The connector is available (below) as:

  • A runnable package based on a Java JAR file including a start script
  • A container image suitable for running in a container runtime such as Docker or Podman

The PubSub+ Connector for Debezium (CDC) is a “self-contained connector” from Solace. All self-contained connectors share a common architecture and provide a number of enterprise services to the connectors such as:

  • A local management server accessible over HTTP(s) and JMX exposing endpoints for:
    • Health check
    • Metrics monitoring
    • Log file access
    • Workflow adminstration (start & stop workflows)
  • A common set of configuration options for:
    • logging – log levels, log file size, archive and rollover rules, appenders to export to other log services
    • security setup for management endpoints – authentication and authorization to the endpoints, TLS for HTTPS endpoints
  • Various runtime deployment options:
    • Standalone
    • Active_Standby – for redundancy (you can have more than 1 standby instance)
    • Active_Active – for horizontal scaling (where the source of data will support multiple active consumers such as a non-exclusive queue in PubSub+)

Show more

Still have questions?

Explore Other Connectors Get in Touch