---
title: Sinks
slug: concepts/sinks
docTags: lfKJLr7aKY5MTF6N6g-Kq,NdAmj9E8yTRkwQ9gl8SF9
createdAt: 2025-08-18T13:17:00.887Z
---

## What is a Sink?

A **Sink** in Factry Historian is a mechanism for **sending data **(measurements, calculations, or events) to an **external system**.

This external system is an **MQTT broker**. Sinks are designed for use cases where you want to stream or publish live data out of the Historian in a **structured format**, such as JSON or Sparkplug B.

## Why does it matter?

Not all analytics, monitoring, or business intelligence happens inside Factry Historian. Many users need to:

- Integrate with IoT or cloud services
- Feed selected metrics into corporate dashboards
- Share data with third-party systems
- Stream data into custom applications

Sinks allow you to **publish relevant data**, without exposing your entire Historian or replicating the raw database.

## How does it fit in the system?

Sinks operate as **destinations**, configured to push data to a specific broker.

Each sink has:

- A **name** (e.g. Azure IoT hub, or Corporate MQTT broker) and an optional **description**.
- A **type**, either Generic MQTT, or Sparkplug B.

### Generic MQTT

The Generic MQTT sink type can be used to send any message format over MQTT. Typically, this will be JSON. The message format can be configured using [Forwarders](docId\:TD6EMj3F_0XsGJI7p4dAg).

A Sink of this type will additionally have:

- A **broker URL** and **connection details** (e.g. certificates, connection credentials)
- A **QoS** setting
- Optional **buffer** settings (in case the broker is unavailable)

### Sparkplug B

The Sparkplug B sink type can be used to enforce the Sparkplug B standard. This can only be used to forward time-series data in the form of [measurements](docId\:XQWLEmDcNfff3-0H-GMmS) or [calculations](docId\:OpIoDkGNNgYjeDX6zkg_D).

A Sink of this type will additionally have:

- A **broker URL** and **connection details** (e.g. certificates, connection credentials)
- A **NodeID** and a **GroupID**
- A setting to configure the **amount of metrics per message**
- A setting to configure **data only mode** (where no Birth or Death messages are sent)
- Optional **buffer** settings (in case the broker is unavailable)

## Example

You are operating a site where:

- Local users and systems need to share **detailed process and energy data** via an on-site MQTT broker
- Corporate needs only aggregated **OEE** and **energy** data pushed to their cloud platform

You configure **two separate sinks**:

1. A **local MQTT sink**, which will be used to send:
   - Line1.Speed, Line1.Temperature, Line1.Energy\_kW, etc.
   - All data is published at a high frequency to the local broker
2. A **corporate MQTT sink**, publishing only:
   - Line1.Energy\_kWh and Line1.OEE, once per day using [Events](docId:0Ith2zLcAIs5YYwhSdTjE). 
   - Data is published at a lower rate to reduce bandwidth and match what corporate cares about

## When you use it

Use a sink when:

- You need to integrate Historian data into a cloud or IIoT platform
- You want to send only specific values, not full database exports
- The receiving system expects a specific protocol or message format
- You need to decouple storage from external consumption

Sinks are often used in hybrid setups where data stays on-premise but select metrics are pushed to the cloud.

## Common misconceptions

- A sink is not a database replication tool. It only sends specific, configured values, using [Forwarders](docId\:TD6EMj3F_0XsGJI7p4dAg), not all measurements.
- Sinks are not meant for backups or historical data exports. They are designed for live or near-real-time streaming.

## Best practices

- Use clear and consistent naming for your sinks.
- Choose the sink type that best matches the receiving system.
- Test your sink with real data and monitor for delivery issues.

## More information

- [Creating a sink](docId\:Y4kZ8um7H731s4Hdh0n1y)