Hi Chris,

Totally agree with that. While IoTDB needs a scalable, distributed MQTT
solution, we should also retain *Moquette* as a lightweight broker. Many
users have relatively low write loads and prefer an *out-of-the-box* way to
persist MQTT messages without writing any code. The current Moquette
implementation fits their needs perfectly.


Best regards,
----------------------
Yuan Tian


On Wed, Jan 28, 2026 at 4:09 PM Christofer Dutz <[email protected]>
wrote:

> Hi all,
>
> The reason I brought this up was:
> Right now we embed (ok now it’s separated) Moquette.
> That’s a lightweight MQTT broker, but it can’t do clustered mode. So
> currently if we start the MQTT broker on one of our data-nodes, that
> becomes a single point of failure. Or we have one broker for each data-node
> and these don’t mesh.
>
> Using Apache BifroMQ could allow us to spin up an MQTT broker cluster that
> grows with the IoTDB cluster.
>
> However, I would love to see it deployed alongside IoTDB and us use a real
> MQTT client for ingesting messages, instead of our current approach of
> hacking this functionality into the broker.
>
> Chris
>
>
> Von: Pengcheng Zheng <[email protected]>
> Datum: Mittwoch, 28. Januar 2026 um 03:35
> An: [email protected] <[email protected]>
> Betreff: [D] BifroMQ and MQTT ingestion for IoTDB
>
> Hi all,
>
> In a recent chat with Chris, he mentioned BifroMQ as an interesting MQTT
> broker architecture - actually this topic has come up more than once when
> discussing future IoT ingestion patterns.
>
> From a quick study, BifroMQ explores some design ideas that differ from
> more established brokers like EMQX or HiveMQ, such as shared subscription
> as a core primitive, native multi-tenancy, and cloud-native scaling [1].
> These seem potentially useful for large-scale or SaaS-style ingestion
> pipelines.
>
> This is not to suggest replacing existing MQTT integrations, but I wonder
> whether this direction could be interesting for future IoTDB ingestion
> architectures.
>
> Curious to hear your thoughts, and whether anyone has hands-on experience
> with BifroMQ.
>
>
> [1] https://bifromq.apache.org/
>
>
> Best regards,
> Pengcheng
>

Reply via email to