Close
0%
0%

ProtoMQ: Type-safe, bandwidth-efficient MQTT.

MQTT + ProtoBuffers + Ziglang.
Stop sending bloated JSON over the wire.

Similar projects worth following
The MQTT protocol is the go-to communication channel for Internet of Things devices. However, they are being wrongly used with data-hungry messaging packets such as JSON or so on. There is no native type-safety and a designed protocol for the communication between server and client.

Within this project, we propose a new protocol based on MQTT and Protocol Buffers. It is faster, it is data-aware and less resource-hungry! Its service discovery and runtime ProtoBuf engine allows you to never touch your client firmwares ever!

Furthermore, the project uses Ziglang and ships with no dependencies to reduce the complexity. It uses the fastest network I/O notification systems for the OSes (epoll for Linux and kqueue for BSD/MacOS).

The best part is its benchmarking suite, where 7 different real-life scenario is being tested, and their metrics are based on the hardware captured and published in the repository. You can always be sure about how fast it is!

Feel free to try it out!

ProtoMQ Mascot
MQTT's simplicity. Protobuf's efficiency. Zig's bare-metal performance.
Built for IoT and edge computing.

- Schema-enforced Messaging — `.proto` files define the contract. Malformed payloads get rejected *before* they reach subscribers.
- Custom Runtime Protobuf Engine — written from scratch in Zig. Runtime `.proto` parsing, zero external dependencies.
- Service Discovery — clients query `$SYS/discovery/request` to discover topics and download schemas on the fly. No pre-shared `.proto` files needed.
- Optional Admin HTTP API — register new schemas and topic mappings at runtime, monitor connections and throughput. Disabled by default, zero overhead when off.
- Runs in 2.6 MB — the entire broker with 100 active connections fits in under 3 MB of memory.


Why ProtoMQ?

If you've worked with IoT sensor fleets, you've probably been through this: you start with JSON over MQTT because it's easy to debug, every language has a parser, and `mosquitto_sub` lets you eyeball what's going on. It works fine... until you start caring about bandwidth.

A 12-field sensor reading weighs around 310 bytes in JSON. The same data in Protobuf: 82 bytes. On a cellular-connected device pushing telemetry every 5 seconds, that gap adds up to roughly 1.6 MB/day per device — multiply by a few thousand devices and the data bill starts hurting.

But switching to Protobuf usually means code generation per language, keeping stubs in sync across firmware versions, and losing the ability to just read your payloads. ProtoMQ takes a different approach: the broker owns the `.proto` schemas and validates every message against them. The CLI can accept JSON and encode it to Protobuf before publishing, so you get a human-friendly workflow without sacrificing wire efficiency.

Plain MQTT + JSON ProtoMQ
Schema enforcement None — anything goes Validated at every PUBLISH
Payload format JSON (~170 bytes, 8 fields) Protobuf (~48 bytes)
Client bootstrap Pre-shared docs Built-in Service Discovery
Code generation Required per language CLI encodes JSON → Protobuf for you


Performance

ProtoMQ handles 208,000 messages/second on an Apple M2 Pro and 147,000 msg/s on a Raspberry Pi 5 — with sub-millisecond p99 latency and no memory leaks across 100,000 connection cycles.

Scenario Apple M2 Pro Raspberry Pi 5
p99 latency (100 clients) 0.44 ms 0.13 ms
Throughput (10-byte msgs) 208k msg/s 147k msg/s
Throughput (64 KB msgs) 39k msg/s 27k msg/s
Sustained load (10 min) 8,981 msg/s 9,012 msg/s
Memory (100 connections) 2.6 MB 2.5 MB
Connection churn (100k cycles) 1,496 conn/s 1,548 conn/s
Memory leaks 0 MB 0 MB

  • Log 2: New Release 0.2.0

    gökhan koçmarlı02/28/2026 at 09:51 0 comments


    Download the new release and comment on your thoughts!

    https://github.com/electricalgorithm/protomq/releases/tag/0.2.0

    (You'll love the updates! Don't go away, scroll down and read the next paragraph.)


    The project got quite an interest on GitHub repository. I don't know if people are using it in their projects, but the stargazer count increased to 23. Compared to other projects I had, it's a quite fast increase in one-month.

    What has changed?
    This version ships a service discovery feature where clients can ask MQTT what data formats are available for which topic. This feature is a replica of gRPC's service discovery, with a bit translated to a "data format" mentality rather than procedure calls. Furthermore, a new admin server (HTTP server) is designed to add new protobufs to the broker and map them to topics. The server's HTTP API is protected with an auth token and only works on loopback currently to reduce the security risks.

    These two features enable my dream of having "no updates" to clients when I want to change my data packet format. They even allow me to build a decoupled system like HomeAssistant, where one end only knows what data formats they can share, and the other end only knows what data formats they can consume.

    A Docker file is also added to easily run the server without having Zig download hassle.

    What's planned?
    I'll continue to develop the project by introducing QoS 1 and 2, possibly MQTT-over-TLS support. I shared the project with several boards to gather feedback from people. Would love to see yours to plan a future roadmap.

    Thanks!

  • Log 1: Observability & Dynamic Schema Management

    gökhan koçmarlı02/23/2026 at 01:25 0 comments

    One of the biggest pain points in using Protobuf with MQTT is the rigidity of the message types. In a standard setup, if you want to change a schema, you often have to rebuild and restart the broker. Not with ProtoMQ.

    We've just implemented an optional HTTP Admin Server that brings operational visibility and hot-schema updates to the broker without touching the "hot-path" of message routing.

    What’s New?

    • Dynamic Schema Registry: You can now register .proto files at runtime via POST /api/v1/schemas. This allows the broker to start decoding new message types instantly without a restart.
    • Live Telemetry: A new /metrics endpoint provides JSON-based visibility into active client connections and total messages routed.
    • Zero-Overhead footprint: True to the project's goal of running on the smallest embedded targets, this server is strictly conditional. By using Zig's build system (-Dadmin_server=true), you can choose to include it for development or larger controllers, while stripping it entirely for tiny edge devices.
    • Shared Event Loop: To ensure zero jitter in MQTT delivery, the Admin Server runs on the same non-blocking IOContext event loop as the broker. No threading overhead, just cooperative multitasking.

    Why this matters for IoT?

    Debugging a distributed fleet of sensors is hard enough. By adding standard HTTP-based monitoring and schema management, we've made ProtoMQ ready for production environments where "set and forget" isn't an option, all while maintaining our sub-millisecond latency targets.

View all 2 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates