Publish / stream · All operations
Send to a stream or queue
Produce to a queue or stream.
Status
- In arcform
Not built yet
arcform does not do this yet. Its place on the roadmap
- Shape of the result
- the table sent out, with nothing new to look at
- Level
- needs an arcform operator
Variants
- Send rows over a socket or pipe
Write rows straight to a listening network socket, a UDP or syslog endpoint, a named pipe or another instance, with no broker in between.
Publish rows to a message broker
Send each row as a message to a topic, queue or stream on a broker such as Kafka, JMS, MQTT or Kinesis.
What other tools call it
Meridian's classification; an independent blind rating agreed on 86.2% of 312 rows (exact class, version 2).
Apache Hop (6)
Azure Event Hubs writerread 2026-09-27Write rows as events to Azure Event Hubs
Beam GCP Pub/Sub: publishread 2026-09-27Publish messages to a Google Cloud Pub/Sub topic on the Beam engine
Beam Kafka produceread 2026-09-27Publish records to a Kafka topic on the Beam engine
Beam Kinesis produceread 2026-09-27Send records to an AWS Kinesis stream on the Beam engine
JMS producerread 2026-09-27Send each row to a JMS queue or topic as a text message
Kafka producerread 2026-09-27Publish rows as messages to a Kafka topic
Apache NiFi (5)
AzureEventHubRecordSinkread 2026-09-27Record sink: format and send records to Azure Event Hubs
Message queue and stream publisher processors (family)read 2026-09-2712 processors, PublishAMQP, PublishGCPubSub, PublishJMS, PublishKafka, PublishMQTT, PutKinesisStream, PutSQS, PutSNS, …
Network sender processors (family)read 2026-09-273 processors, PutTCP, PutUDP, PutSyslog
SiteToSiteReportingRecordSinkread 2026-09-27Record sink: send records to another NiFi instance over Site-to-Site
UDPEventRecordSinkread 2026-09-27Record sink: send records as UDP datagram packets
Duckle (1)
Streaming sinks outside DuckDB (family)read 2026-09-256 components, one per system, run by Rust drivers and HTTP clients, outside DuckDB: kafka, redpanda, nats, rabbit, pubsub, …
Pentaho Data Integration (8)
AMQP Producerread 2026-09-27Publish rows as messages to an AMQP broker in near real time
IBM WebSphere MQ Producer (deprecated)read 2026-09-27Deprecated: send messages to an IBM WebSphere MQ server
JMS Producerread 2026-09-27Send messages to a JMS server
JMS producer (deprecated)read 2026-09-27Deprecated JMS writer, replaced by JMS Producer
Kafka Producerread 2026-09-27Publish rows as messages to Kafka in near real time
Kinesis Producerread 2026-09-27Push records to a stream in Amazon Kinesis Data Streams
MQTT Producerread 2026-09-27Publish rows as messages to an MQTT broker in near real time
Socket writerread 2026-09-27Serve rows over a socket to a Socket reader step
RapidMiner Studio (1)
Write Kafka Topicread 2026-09-27Send each row of a table as a message to a Kafka topic
Talend (4)
Messaging output components (family)read 2026-09-2713 components publishing messages to a queue or stream: tKafkaOutput, tJMSOutput, tMQTTOutput, tKinesisOutput
tNamedPipeOutputread 2026-09-27Write rows into an open named pipe
tRouteOutputread 2026-09-27Send messages from the Job to a Mediation Route
tSocketOutputread 2026-09-27Send the rows of the flow to a listening socket port
Background
Message queues pass messages between processes asynchronously, so the sending and receiving parties need not use the queue at the same time.[1] Messages placed onto a message queue are stored until the recipient retrieves them.[1] A message broker is an intermediary program that translates a message from the sender's messaging protocol to the receiver's.[2]
When to use it
Reach for a stream or queue when another system has to react to each row as it arrives, rather than pick up a finished file later. (Meridian's view) In Apache Kafka, producers are the client applications that publish, or write, events to Kafka, and consumers are those that subscribe to and read them.[3] In Kafka, producers and consumers are fully decoupled, and producers never need to wait for consumers.[3] In Kafka, an event, also called a record or message, has a key, a value, a timestamp and optional metadata headers.[3] Kafka organises and durably stores events in topics, and a Kafka topic can have zero, one or many producers writing to it.[3]
Message queuing systems often offer options for delivery, such as whether a message must be delivered at least once or no more than once.[1] Settle which of those promises the receiving system needs before sending; a receiver that may see a row twice needs a key it can deduplicate on. (Meridian's view)
Kafka topics are partitioned, which means a topic is spread over a number of buckets held on different Kafka brokers.[3] Kafka writes events with the same event key to the same partition, and guarantees that a consumer reads a partition's events in the order they were written.[3] In Apache Hop's Kafka producer, a message with no key is distributed to a partition at random.[4] When the order of rows for one customer or account matters downstream, send that identifier as the message key. (Meridian's view) Apache Hop's Kafka producer can read each row's topic from a field, and a row whose topic field is empty makes the Kafka producer fail.[4]
The method
In a typical message-queueing setup, a system administrator installs and configures a queue manager or broker and defines a named message queue, or registers with a message queuing service.[1] A queue manager stores messages until a receiving application connects, and then calls the software routine that application registered.[1]
Three standards are used in open-source message queue implementations: Advanced Message Queuing Protocol (AMQP), Streaming Text Oriented Messaging Protocol (STOMP) and MQTT.[1] AMQP is a feature-rich message queue protocol, approved as ISO/IEC 19464 since April 2014.[1] MQTT, formerly MQ Telemetry Transport, is a lightweight message queue protocol especially for embedded devices.[1]
Compared with the alternatives
The Hypertext Transfer Protocol (HTTP), used in the World Wide Web and in web services, operates synchronously: a user sends a request and then waits for a reply.[1] In publish/subscribe systems, an application publishes information for any number of clients to read.[1] In a publish/subscribe system it would not make sense for the sender to have to wait if, for example, one of the recipients had crashed.[1] Prefer a queue or stream over a direct request to an API when the sender should not stall on a slow or absent receiver. (Meridian's view)
Unlike traditional messaging systems, Kafka does not delete events after they are read; a per-topic setting says how long Kafka retains them.[3] Events in a Kafka topic can be read as often as needed.[3]
Sources
- [1]Message queuesecondary source
- [2]Message brokersecondary source
- [3]Introduction | Apache Kafkadocumentation
- [4]Kafka producer | Apache Hopdocumentation