Hi Yuan, Thanks for taking the time to get familiar with BifroMQ through the documentation. You’ve actually pointed out one of the design decisions where BifroMQ intentionally differs from many existing MQTT brokers.
Compared to the common approach of integrating downstream systems via broker-side plugins (for example, writing directly into IoTDB through a connector), BifroMQ’s architecture deliberately prefers what we call a *Non-Coupled Pattern*[1]. Here, “coupling” mainly refers to implementation-level coupling between the broker and downstream systems. Instead of embedding downstream logic into the broker, BifroMQ encourages data-plane integration based purely on native MQTT protocol capabilities — most notably *Shared Subscriptions* and *Persistent Sessions*. With this model, the broker remains protocol-focused, and downstream systems consume data using standard MQTT clients. One direct benefit of this approach is neutrality at the integration layer: downstream systems do not need to implement broker-specific plugins or connectors. This reduces integration friction for users and, more importantly, helps avoid vendor lock-in when switching or coexisting with different MQTT brokers. Another important consideration is operational risk. In many production environments, the MQTT broker sits at the traffic ingress layer and is a highly business-sensitive component. Tightly coupling downstream logic via plugins means changes in downstream behavior can potentially affect broker stability. A decoupled integration model significantly lowers the operational risk introduced by downstream evolution. That said, I completely understand why plugin/connector mechanisms are popular and convenient in many brokers today. In BifroMQ, this part is intentionally left open to the community, but pushed *outside* the broker boundary. This can take different forms: * downstream systems embedding an MQTT client directly (as Chris mentioned previously); * or a more generic, broker-agnostic “rule engine”–style layer that evolves independently of the broker (for reference, [2] explores this direction). Happy to discuss further or go deeper into concrete ingestion scenarios from the IoTDB side. [1] https://bifromq.apache.org/docs/user_guide/integration/intro/ [2] https://github.com/bifromqio/bifrore Best, On Fri, Jan 30, 2026 at 4:49 PM Christofer Dutz <[email protected]> wrote: > In iotdb I currently see no way to consume mqtt messages from out of the > box without running the moquette broker. > > That's because the functionality of consuming the incoming messages is > patched intro the server part of that. > > I personally have no objections to having an optional mqtt broker > embedded, which users can activate if they don't have any other. But I > would prefer, if the ingest would be done by a standard mqtt client instead > of the way we are doing it right now. > > The main reason is: mqtt isn't built for this setup with multiple brokers > (that don't form a cluster) > > But I see benefit of embedding bifromq instead of moquette, as that can > also operate as an mqtt cluster if more than one datanode is used. > > Chris > > Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Yuan Tian <[email protected]> > Sent: Thursday, January 29, 2026 1:35:57 PM > To: [email protected] <[email protected]> > Subject: Re: [D] BifroMQ and MQTT ingestion for IoTDB > > Hi Yonny, > > I’ve spent the last couple of days studying the *BifroMQ* documentation. > It’s a fascinating project with significant innovations compared to > traditional MQTT servers. > > However, due to its unique architecture, other MQTT products can easily > integrate downstream *sink components* (such as writing messages into > *IoTDB*) via plugins. For downstream products like IoTDB, we only need to > provide an official plugin; users can then simply load it into the broker > with some configurations to enable data ingestion. This is incredibly > convenient for users. I’m wondering if BifroMQ has any similar plans or > alternative strategies in this regard? > > Best regards, > > ---------------------- > > Yuan Tian > > On Thu, Jan 29, 2026 at 8:28 PM Yonny Hao <[email protected]> wrote: > > > Hi all, > > > > Thanks Chris for introducing BifroMQ to the IoTDB community — just wanted > > to jump in and say hi. > > I’m Yonny, the original author of BifroMQ and currently one of the > > maintainers. > > > > We’ve just released our first Apache Incubator version recently, and the > > website has been updated with more details reflecting the latest progress > > and design direction: > > https://bifromq.apache.org/ > > > > I’d be very happy to explore possible ways the two projects could work > > together, especially around MQTT ingestion at different scales. > > > > Although BifroMQ is primarily designed as a multi-tenant, distributed > MQTT > > broker for large-scale deployments, it can also run perfectly fine as a > > single-tenant, single-node broker. Users can start simple, and later > scale > > out to a clustered or multi-tenant setup if and when needed — the > > deployment model is quite flexible. > > > > Looking forward to the synergy and learning more about the IoTDB side as > > well 🙂 > > > > Best, > > -- > > Yonny(Yu) Hao > > > -- Yonny(Yu) Hao
