Back to browse
GitHub Repository

Ultra quick message queue and streaming server

959 starsCrystal

LavinMQ, an open-source message broker written in Crystal

by CarlHoerberg·Apr 28, 2026·16 points·6 comments

AI Analysis

●●●BangerBig BrainSolve My Problem

RabbitMQ alternative in Crystal that runs on a fraction of the hardware.

Strengths
  • Built by the CloudAMQP team after 14 years of hosting RabbitMQ in production.
  • Single binary with exceptional throughput and minimal RAM requirements.
  • Solves specific connection churn issues that plagued their managed service customers.
Weaknesses
  • Crystal language ecosystem is smaller than Java/Go, potentially limiting contributors.
  • Feature parity with mature RabbitMQ plugins may take time to achieve.
Target Audience

Backend engineers, DevOps teams managing high-throughput queues

Similar To

RabbitMQ · Mosquitto · NATS

Post Description

Hi HN. I'm Carl, creator of LavinMQ.

LavinMQ is an open-source message broker. AMQP 0-9-1, MQTT, HTTP and streaming. Single binary, minimal resource use. If you know RabbitMQ, it's that (but running on a fraction of hardware).

We're the team behind CloudAMQP where we've hosted RabbitMQ for 14 years. Sometimes customers hit issues we couldn't fully explain / work around. So we built our own broker, in order to provide solutions where we previously couldn't (which is much easier when you control the full stack). It all started by me building an open-source AMQP proxy to handle short-lived connections for a customer, to avoid heavy connection churn on cpu. Once the protocol was implemented, adding a persistence layer seemed like a fun challenge. How hard could it be? Turns out the protocol was the easy part. Reliable disk storage, ack handling, and replication was harder. It took years. Our first release was pushed in 2020 and today it runs on 5,000+ production instances on CloudAMQP. LavinMQ is written in Crystal (LLVM-compiled, Go-like concurrency, Ruby-like syntax). Messages go straight to disk via memory-mapped files, no in-memory cache. Append-only writes for both messages and acks. The whole design is built around minimizing memory copies, allocations and syscalls.

Numbers: ~580k msgs/sec on a t4g.micro (2 vCPU, 1 GB RAM). Over 1M msgs/sec on a c8g.large (2 vCPU, 4 GB).

Try it:

docker run -p 15672:15672 -p 5672:5672 cloudamqp/lavinmq

We are curious to hear: how are you handling messaging today? What would make you consider switching broker?

Similar Projects

Hardware●●Solid

Mqtt Broker for 10 Years

MQTT broker on a $10 ESP32 kills the Raspberry Pi tax for home automation.

Niche GemBig BrainShip It
skittleson
1512d ago
Open Source●●Solid

Android Notifications over MQTT

This is a pragmatic MQTT→Android notifier with useful attention to operational details: per-topic QoS, retained-as-new behavior, per-message read/unread state and local persistence so alerts aren’t lost, plus a persistent-foreground mode for always-on connections. It’s not reinventing the wheel, but encrypted credential storage, connection testing before saving brokers, and a Compose-based UI make it a tidy, practical tool for anyone running IoT services who wants reliable mobile alerts.

Niche GemSolve My Problem
firebadnofire
213mo ago