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 |
gökhan koçmarlı
Chris Jones
Evgeny
Mark Traverse
Dylan Brophy