Inside HiveMQ - The Origin and Future of MQTT | EP05 - The Connected Factory podcast
In this episode of The Connected Factory podcast, Dominik Obermaier, CEO and Co-Founder of HiveMQ, joins Alexander Krüger, CEO and Co-Founder of United Manufacturing Hub, to share insights into his journey with HiveMQ, the evolution of MQTT, and its applications in various industries.
Key Takeaways
- Founding & Product-Market Fit
HiveMQ found early success by selling real value—paying customers proved the product’s worth without depending on venture capital.- First automotive customers in Germany validated reliability at scale.
- Tight feedback loops shaped the broker’s features.
- Bootstrapping forced focus: only a few shots at real market traction.
- MQTT Simplicity & Edge-to-Cloud Strategy
MQTT’s lightweight, publish-subscribe model offers reliability and low overhead—ideal for industrial IoT with patchy connections.- MQTT was niche in 2012 but well-suited for large-scale device communication.
- Dominik contributed to standardizing MQTT, ensuring interoperability.
- Automotive, energy, and logistics sectors rely on minimal latency, robust scalability, and secure data flow.
- Future Outlook & Unified Namespace Governance
Enterprises are moving toward “Unified Namespace” (UNS) that harmonize data end-to-end, from edge to cloud, requiring governance, security, and standardization.- HiveMQ is expanding beyond “just a broker” to a cloud platform enabling data hub functionality, routing, security, and governance.
- Companies want to manage global rollouts (hundreds of factories or energy assets) without duplicating systems.
IT / OT Integration Platform for Industrial DataOps
Connect all your machines and systems with our Open-Source IT/OT Integration Platform to make all shop-floor data accessible at a single point.
Chapters
00:01 - Introduction and Dominik’s Background
01:18 - Bootstrapping HiveMQ and Finding Product-Market Fit
03:17 - Early Development of MQTT and Its Industry Role
05:35 - MQTT’s Simplicity and Application in Industrial IoT
08:22 - Bridging IT and OT with Edge-to-Cloud Architectures
12:23 - Workforce Challenges and Data Accessibility
14:43 - Evolution of Manufacturing Technology Standards
16:24 - HiveMQ’s Expansion to a Full IoT Data Platform
18:20 - Building and Managing Unified Namespaces
23:41 - Open Standards and Future-Proofing IoT Ecosystems
28:53 - Closing Remarks and Future Announcements
Transcript
Alexander Krüger
So great to have you here Dominik. For everybody behind the screen, can you tell us a little bit about Dominik that we don’t know from LinkedIn, you’re doing beyond HyphenQ and at HyphenQ to give us a full picture there?
Dominik
Absolutely. And thank you for having me, Alex. So besides working at HiveMQ, founding HiveMQ and driving the business, I also try to spend as much time possible outside of computer screens. So I actually really pick on things like nature, working with my wife there, but also things like barbecuing and cooking in general is something I really enjoy outside of work.
Alexander Krüger
Yeah, this is always the stuff that you can then squeeze in before and after your busy work, I guess, and also spend time with your wife. This is the precious time that you then... And so what I’m actually super interested in is: there are companies, especially in a venture space, who have an idea and a pitch deck and then raise half a million as a pre-seed and then just build it from there. For us, to some degree, but for you to an even greater degree, you had a pre-venture time. I think it was 2012 founded and then 2021 funded. What was that time of building the product like? I’m super interested in that.
Dominik
Yeah, you know, it’s interesting. When we founded the company, we had a very simple hypothesis that I still believe is true: if you build something of value, people will pay you for this. So when you break down the first phase of a company—which is usually finding product-market fit—the question is, when do you have product-market fit? And we found the best way to increase the urgency and also to find product-market fit is actually building something of value for customers who actually pay you. And the customer should be the target customers we want to have, not some random other customers.
So what we did is we bootstrapped the company, which increases the urgency incredibly because you do not have a lot of resources at your disposal. This means you can realistically only make a few shots. We were really lucky to find some early customers, especially in the automotive space in Germany, where we then worked together, understood the pain points, improved the product, built new functionality and features, and made it also fit for that specific industry.
From there—now in 2025—we’ve expanded quite a bit. While we still have a lot of automotive customers, most of the cars produced in Europe and the US either use our software while driving or while the car is being produced. So we are still pretty big in the automotive space and love our customers there, but we’ve grown into the energy sector, logistics, and smart manufacturing in general. And of course, we continue to serve automotive customers as well.
Alexander Krüger
Was it always about MQTT from the beginning? Or was it something else in 2012? Were you thinking about a distributed messaging platform, or how did it start?
Dominik
It started with us trying to understand how Gartner and Forrester and then IDC said, “There will be billions of devices in the internet of things. There will be all of these connected things.” And we were like, “How come we’re running web applications, and once we hit 100 concurrent users, everything explodes and goes up in flames and is super expensive to run? How would you run millions or billions of devices in a way that’s economically viable for large companies?”
And MQTT was not a thing back then—very niche. In around 2010, the MQTT protocol was made public in a way that there was a small community. The protocol itself was invented in 1999, used for some projects, and IBM had it in some of their products. But there was never really an industry or community around it. In 2010, that changed, and we thought, “This makes a lot of sense. This is the obvious answer for many IoT reliability and scalability problems, plus cost-effective data transmission.” But we wondered why nobody else was solving it. It turned out that it wasn’t a bad idea.
So we focused on MQTT. I personally spent a lot of time in the committees, making MQTT a full specification in 2014 and 2018. By 2016, MQTT was the dominant communication protocol for IoT and remains so for connected devices and industrial IoT.
Alexander Krüger
Yeah, I think this is a really good explanation of how MQTT originated. Kafka might not have been fully fledged at that time, but it also wasn’t specifically addressing IoT needs for unstable internet connections. You might be on Wi-Fi or even worse, a 3G device, transmitting a JSON payload once a minute, and you need it to be real-time. What’s the similarity for industrial spaces, like production floors that typically have stable Ethernet or short-distance networks, not necessarily needing to scale to millions of devices?
Dominik
It basically boils down to simplicity. In industrial environments, you have a big mess of integrations you need to do. Before founding the company, I worked at a company building MES systems (manufacturing execution systems), which live and breathe integrations. You need to integrate with pretty much anything, and no single MES fits all. Also, it needs to be mission-critical and super reliable, because if a production line breaks, it can cost tens or hundreds of thousands of dollars per minute.
Fortunately, manufacturing systems don’t break down that often, because once it’s set up, there’s not a lot of change—well, at least in 2010. Today it’s different because digitization in manufacturing demands fast iterations, and you push responsibility of changes down to the people who actually know what they’re doing. So even if it’s still centralized, it’s more distributed. That’s where you see technologies like Kafka, IT systems, Kubernetes, containerization, etc., moving down into the OT layer. MQTT remains popular because it’s so simple; it’s designed to be very lightweight on the client side for producing and consuming data.
MQTT wasn’t built to replace enterprise messaging queues like RabbitMQ or IBM MQ, which are huge in finance. There, you deal with financial transactions, often needing to store transactional history. IoT data moves quickly at high scale, so it’s different. What we see in our customers is Kafka on the cloud side, MQTT more on the edge, bridging the two. That’s how they build an edge-to-cloud network or infrastructure to move data to all systems, democratize data, and create a unified namespace with MQTT.
Alexander Krüger
I also think democratizing and pushing systems back down to the shop floor is crucial. When we talk to large customers with an IT/OT divide, IT is typically ticket- and cost-center driven. They might have a specialized AI unit, but for everyday needs, the process to get a VM or do an edge deployment is too long. The same frustration applies on the shop floor: it’s just too hard to iterate. So the simplicity of MQTT is key.
Dominik
Yes, exactly. Another key problem is looking ahead 10 years, a big chunk of the workforce is getting older, especially in manufacturing, and it’s hard to find qualified younger people. But the younger generation is digital-native. They know how to use computers. The question is, does your organization give them the data they need to solve problems and make decisions? Companies that do well here, I find, are the ones letting the shop floor people have more direct access to data. If they have to wait for corporate HQ to solve everything, it’s too slow.
Alexander Krüger
I think the shortage of automation engineers and data engineering experts is massive. We see attempts with DevOps solutions to automate PLCs, but we also see very specialized manufacturing technology stacks. For example, historians are just specialized databases with bells and whistles requiring special certifications. Moving away from all that specialized technology—special interfaces, specialized databases, specialized visualization tools—toward standards like MQTT, SQL, Postgres is key. This is also how you avoid knowledge silos. HiveMQ is an MQTT broker at heart, but you’re building a suite around it. What do you see as beyond MQTT that’s needed for the future?
Dominik
We started with the MQTT broker, but in the last few years, we’ve moved into a full cloud platform for data movement. While originally most customers came for the broker, we now have a suite with a data hub, rules engine, governance, and other pieces needed for Fortune 500-type deployments. For example, we have customers with more than 30 million concurrent devices, 400 million topic subscriptions, billions of queued messages. We removed the glass ceiling on scale.
We then built out integrations so that you can unify and harmonize data. We have a Data Hub for this, plus tools for building a unified namespace. We found that large enterprises want an end-to-end approach connecting automotive or energy or manufacturing assets. They need not just the technology, but also guidance on rolling it out globally. Governance is huge: how do you manage who can publish or subscribe to what? These are all non-trivial problems we solve.
Alexander Krüger
That’s interesting. People talk about an “Uber Broker” that can do everything: store historical messages, query them, etc. What’s your stance on that?
Dominik
I’ve heard “Uber broker” in some communities. It parallels the unified namespace concept: you have real-time data moving at high frequency with low latency, and also a need for querying historical data, or letting humans request on-demand data. You could do best-of-breed or best-of-suite. Some people piece together everything themselves—time-series databases, open source, commercial solutions—others want a more turnkey platform. We tend to focus on interoperability. Large enterprises usually already have historians or Oracle or MongoDB, so we integrate with those. But for those who need something from scratch, we offer simpler, plug-and-play solutions too.
Alexander Krüger
I see. And in building a unified namespace, you also have relational data like work orders, SOPs, or PDFs that might not fit directly into a pure real-time pub/sub model. So that’s a big reason why an “Uber broker” remains a complex proposition.
Dominik
Yes, exactly. We often see GraphQL or SQL or other queries. Different stakeholders want different ways of accessing data. Sometimes a business user or engineer just wants a report or a query. So you should support multiple interfaces, not lock people into one technology that might vanish in five years. Also, companies expect solutions to run for decades. So open standards are vital—MQTT being an OASIS standard with many vendors, including open source and proprietary. Proprietary solutions are riskier for a 40-year horizon.
Alexander Krüger
Right. You want it to be future-proof. So what does the future look like for HiveMQ?
Dominik
We work mostly with large, global customers building the biggest unified namespaces. We see them start with a pilot, roll it out across a region, and eventually globally. They need not just the tech but also help building internal adoption, training, etc. So we’re putting a lot of effort into governance tools for truly massive UNS deployments, plus hooking in AI. There’ll be announcements soon—things that simplify managing the largest unified namespaces in the world.
Alexander Krüger
Awesome. Thank you, Dominik. It was a blast having you and hearing what you’ve built with HiveMQ. I can’t wait to see what comes next.
Dominik
Thank you, Alex. Thank you for having me.
Alexander Krüger
Then see you soon. Bye.