Actually, for such users, since they have low write loads, they prefer 1C1D. Forcing them to set up a separate MQTT broker, write custom consumer code, and then manually pipe the data into IoTDB would be a *total disaster*. They want to minimize the number of components in their stack to reduce operational overhead.
On Wed, Jan 28, 2026 at 4:26 PM Yuan Tian <[email protected]> wrote: > 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 >> >
