Single-node · In-memory · gRPC

Heads up: I ended up switching to NATS + PostgreSQL. If you need consumer groups, bare NATS won't help — you need JetStream, which requires persistence. tinybroker fills the gap when you want in-memory consumer groups with no persistence overhead. The code works and is free to use; just know why you're reaching for it.

vs NATS

NATS is a lightweight, high-performance messaging system with a minimal footprint. NATS Core (no persistence) is the most direct competitor to tinybroker in terms of simplicity. NATS JetStream adds persistence, at-least-once delivery, and consumer groups.

Use NATS when

  • You need at-least-once delivery guarantees and are willing to run JetStream (adds complexity).
  • You need a battle-hardened, widely-deployed broker with a large ecosystem.
  • You use languages that have mature NATS client libraries (most do).
  • You want subjects with a dot-separated hierarchy and > wildcard semantics that work across a cluster.
  • You need a NATS cluster for availability across multiple nodes.

Use tinybroker when

  • You want consumer groups (balanced delivery) without enabling JetStream. NATS Core has no concept of consumer groups — every subscriber gets every message (fan-out only). You would need JetStream for balanced delivery, which brings storage, replication, and operational overhead.
  • You prefer a gRPC interface over the custom NATS wire protocol. Generated stubs mean clients are consistent across all your services without a separate NATS SDK.
  • Your deployment is a single-node, in-process coordination bus where JetStream’s persistence and clustering are unnecessary weight.

Summary

NATS Core is simpler than JetStream and runs in a similar footprint to tinybroker. The key differentiator is consumer groups: if you need balanced delivery (one consumer in a group receives each message), tinybroker delivers that without persistence or clustering. If you need persistence or a multi-node cluster, NATS JetStream is the right choice.