Solace Connectors: Micro-Integrations Catalogue

Solace Micro-Integrations and Integration Hub: How Solace Connects Everything Else

Solace Connectors: The Micro-Integrations Catalogue and Where Each One Runs

Solace connectors, now called Micro-Integrations, by category as of October 2026: databases, messaging, Kafka, SaaS and files, and managed vs self-managed.

Solace connectors are now called Micro-Integrations: small modules that move data between one external system and the Solace event broker, in one direction, with optional transformation, enrichment and filtering. As of October 2026 the catalogue spans messaging systems, Kafka variants, database change data capture (CDC), SaaS applications and file stores, and each connector runs either managed in Solace Cloud or self-managed in your own infrastructure. This page lays out the catalogue by category, explains where a connector should run, and covers what gets hard.

It sits under Solace integration, which explains why Solace builds integration this way, in the Solace cluster.

How Solace connectors work

Every connector has a direction. The Solace documentation defines a source micro-integration as one that carries data from an external system to the event broker, and a target as one that carries data from the broker to an external system. A two-way integration with, say, IBM MQ is two flows, configured and monitored separately.

The connector speaks the other system’s language so the broker does not have to. A CDC source reads a database’s change log and publishes each insert or update as an event. An IBM MQ source drains a queue and republishes. A target for Amazon S3 writes events to a bucket. The product page lists payload transformation, data enrichment and header modification as supporting capabilities.

What it publishes to is your design. The connector puts events onto topics you choose, and from there the Solace messaging model takes over: subscribers, queues for guaranteed delivery, and the event mesh for other sites. A connector that publishes to a badly designed topic gives you a badly designed event stream, quickly.

The Solace connectors catalogue by category

Solace does not publish a single numbered list. The table below is assembled from the December 2024 launch release, the Micro-Integrations documentation, the Integration Hub and Solace’s 2026 What’s New posts. It is a map, not a support statement: check each entry’s support type and deployment options on the Hub before you plan around it.

Category (Integration Hub naming where it exists)	Named in Solace sources, as of October 2026
Messaging and eventing	IBM MQ, TIBCO EMS, JMS, MQTT, NATS, AMQP, Oracle AQ, Amazon SQS and SNS, Azure Service Bus, Google Cloud Pub/Sub
Kafka and streaming	Apache Kafka, Confluent, Redpanda, Amazon MSK, Azure Event Hubs, Aiven managed Kafka, Amazon Kinesis Data Streams
Database and data storage	CDC and bulk CDC for IBM Db2, SQL Server, MongoDB, MySQL, Oracle and PostgreSQL; Oracle GoldenGate; Couchbase; Debezium; Azure Cosmos DB
Applications	SAP, Salesforce
Analytics and data platforms	Snowflake, Cloudera, Databricks (the “Zerobus” connector, July 2026), Apache Spark
Files and object storage	SFTP, Amazon S3 (an S3 target added 8 October 2026), Azure Blob Storage, Google Cloud Storage
AI	Qdrant vector database (Beta in the docs)

Read the support column on the Hub. The Hub marks entries as Solace-supported, partner-supported or community. A community asset can be a good starting point, but it is not a product with a support contract behind it.

Managed or self-managed: where a Solace connector runs

The docs describe two models. Managed micro-integrations are deployed from the Solace Cloud Console, which handles “infrastructure, upgrades, and monitoring”. Self-managed ones are standalone modules you deploy “as executable packages or containerized images” on Docker, Podman or Kubernetes.

Managed connectors suit systems Solace Cloud can reach over the internet. For a database or queue manager inside a plant or data centre, a self-managed connector beside it keeps the native protocol local and sends only events across the boundary.

Question	Managed (Solace Cloud)	Self-managed
Who runs the runtime	Solace	You
Upgrades and patching	Solace	You, per connector
Reaches systems inside your firewall	Only through the network paths you open	Yes, it runs beside them
Fits best	SaaS and public cloud services	On-premises databases, queue managers, file servers
Network change needed	Inbound access to the source, or none for SaaS	Outbound from the connector host to the broker

For plants, self-managed is usually the honest answer. An on-premises MES database or a plant SFTP server should not be opened to the internet so a cloud connector can reach it. A self-managed connector in the site’s IT zone or DMZ, with one outbound path to the broker, fits the zone-and-conduit model in our OT network segmentation guide. Whether the broker sits in Solace Cloud or on premises then becomes a separate decision.

Three magenta painted pipes with elbow joints and valves running in parallel against a pale sky — Each connector is a junction where one system's flow joins the shared network. Its configuration decides what passes through, in what shape, and what happens when the downstream side stops.

Building your own, and the older connectors

The Micro-Integration Development Kit (MDK) is for systems the catalogue misses. Solace states it is built on Spring Cloud Stream, and the AI-assisted MDK added in July 2026 uses LangChain4J and a sequence of structured commands to analyse the target technology, scaffold the project, configure the binder, generate the implementation and create tests. Generated or not, a custom connector is code your team owns, tests and patches.

The Transform Processor (formerly the Connector for Message Transformations) handles format changes between topics, and since April 2026 supports full XML attributes. It is often simpler than putting transformation logic into every connector.

The Kafka Connect connectors predate all of this. Solace’s open-source Kafka source and sink connectors run inside Kafka Connect. The Kafka integration page compares them with the in-broker bridge and the wireline proxy.

Planning a first set of Solace connectors

A sequence that keeps the first project small enough to finish:

Pick one business event, not one system. “Production order confirmed” is a better starting point than “connect the MES database”, because it names the consumers and the value.
Find the system of record for that event and check the Integration Hub for a matching source connector, its support type and its deployment models.
Design the topic and the payload first, and record them in Event Portal or at least in a shared document. The connector configuration follows from that design.
Place the connector using the table above, and agree the network path with the people who own the firewall.
Decide the failure behaviour: queue size, alert thresholds, and what the consumer does with a duplicate.
Run it in parallel with the old interface for a full business cycle, including a month-end, before switching off the batch job.

Where it gets hard

CDC couples you to someone else’s schema. A vendor upgrade that renames a column changes your events. Version event schemas and add connector tests to every upgrade plan.
Backpressure has to go somewhere. If a target system slows down, events queue on the broker. Size queues and set alerts before go-live, not after the first month-end.
Ordering and duplicates. Ask how each connector behaves on restart: does it resume from a checkpoint, and can it replay events already sent? Downstream consumers should tolerate a duplicate.
Secrets multiply. Every connector holds credentials for its system. Decide where those live and how they rotate.
Support boundaries blur. A failing flow can involve the source system vendor, the connector’s supporter and the broker. Agree in advance who triages first.
Catalogue entries are not equal. Launch-day names, Beta entries and community assets sit beside fully supported products. Confirm status per entry.

If your connector list is long and the systems sit across several plants, an OT network assessment is a sensible first step, because placement is a network decision before it is a software one.

Frequently asked questions

What connectors does Solace offer?

Solace's connectors are now called Micro-Integrations. As of October 2026 they cover messaging systems such as IBM MQ, TIBCO EMS and the hyperscaler queues, Kafka variants, database change data capture for Db2, SQL Server, MongoDB, MySQL, Oracle and PostgreSQL, SaaS applications such as Salesforce and SAP, and file and object stores. The Integration Hub is the current catalogue and marks who supports each entry.

What is the difference between a managed and a self-managed Solace connector?

A managed micro-integration is deployed from the Solace Cloud Console, and Solace handles its infrastructure, upgrades and monitoring. A self-managed one is a standalone module you run yourself as an executable package or a container on Docker, Podman or Kubernetes. Self-managed suits systems that sit inside a private network; managed suits SaaS and cloud services reachable from Solace Cloud.

Can I build my own Solace connector?

Yes. Solace provides a Micro-Integration Development Kit built on Spring Cloud Stream. In July 2026 Solace added an AI-assisted version that scaffolds a project, configures the binder, generates the implementation and creates tests through a sequence of structured commands. A custom connector is your code to maintain, so weigh that against asking Solace or a partner for a supported one.

Are the old Solace Kafka Connect connectors still available?

The open-source Solace Kafka Connect source and sink connectors remain on GitHub under the SolaceProducts organisation. Solace now also offers Kafka micro-integrations for Apache Kafka, Confluent, Redpanda, Amazon MSK and Azure Event Hubs, an in-broker Kafka bridge and an open-source Kafka wireline proxy. Which one fits depends on where you want the bridge to run and who operates it.