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.

tinybroker is not a replacement for production message brokers — it is a deliberately smaller tool for a narrower problem. The comparisons below explain when each alternative is the better choice and when tinybroker is the right fit.

Feature matrix

tinybrokerNATS (core)KafkaRabbitMQPulsarRedis Pub/SubPostgreSQL
In-memory only✓✓———✓—
Persistent—JetStream✓✓✓Streams✓
Wildcard patterns✓✓—✓✓✓—
Consumer groups✓JetStream✓✓✓Streams—
gRPC API✓———✓——
Zero config✓✓———✓—
Container image<10 MB~30 MB>500 MB~200 MB>1 GB~30 MB~400 MB
Dynamic topics✓✓—✓✓✓—
vs Apache Iggy

tinybroker vs Iggy — when you want a smaller footprint without persistence or multi-protocol support.

vs NATS

tinybroker vs NATS core — both are lightweight, but NATS lacks consumer groups in core mode.

vs Apache Kafka

tinybroker vs Kafka — wildcard topics and dynamic subscriptions vs persistent ordered log.

vs Redis Pub/Sub

tinybroker vs Redis PUBLISH/SUBSCRIBE — more consumer group control, dedicated interface, no shared cache dependency.

vs Apache Pulsar

tinybroker vs Pulsar — full-featured streaming vs minimal coordination bus.

vs RabbitMQ

tinybroker vs RabbitMQ — gRPC pub/sub vs AMQP exchange/queue model.

vs PostgreSQL LISTEN/NOTIFY

tinybroker vs PostgreSQL LISTEN/NOTIFY — dedicated messaging vs database broadcast primitive.