Replace heavy, crash-prone message queues with a single 5.7MB static binary. 167M ops/sec lock-free ring buffers, sub-microsecond latency, embedded Quantum Web Studio, and drop-in Redis RESP2/RESP3 compatibility.
$
docker run -d -p 8379:8379 -p 8380:8380 ianshugarg/vortexmq:latest
Independently verifiable throughput and microsecond latency measured on bare-metal hardware. Zero heap allocations on critical publish and consumer loops.
Designed from scratch in pure Go to permanently solve Erlang memory alarms, JVM stop-the-world pauses, and cache-eviction message loss.
Power-of-two bounded circular buffers with atomic 64-bit sequence counters. Bitwise index masking replaces modulo arithmetic, delivering 5.98ns operations with 0 B/op allocations.
64MB append-only commit segments protected by IEEE CRC32 checksums guarantee zero data loss. Tunable fsync policies commit over 640,000 durable writes per second.
Failed or poisoned tasks are quarantined into an isolated Dead Letter Queue with full error stack traces, retry counts, and payload inspection. Replay individual or bulk messages with 1 click.
Speaks native RESP2/RESP3. Connect using standard Redis clients in Python, Go, Node.js, Java, or C# using LPUSH, RPUSH, LPOP, RPOP, BRPOP, XADD, and XREADGROUP.
Native message scheduling for delayed delivery and exponential backoff retries. Runs in true O(1) time without the lock contention and high CPU churn of min-heap priority queues.
Embedded inside the single 5.7MB binary on port 8380. Features live animated fiber-optic stream flows, real-time consumer lag metrics, dark/light themes, and an interactive publisher.
Zero-allocation RESP2 Parser on port 8379
An objective, technical comparison against RabbitMQ, Apache Kafka, Redis Streams, and NATS JetStream.
| Feature & Architecture | ⚡ VortexMQ | RabbitMQ | Apache Kafka | Redis + BullMQ | NATS JetStream |
|---|---|---|---|---|---|
| Runtime & Dependencies | 100% Pure Go (Zero CGO) | Erlang OTP VM | JVM Heap + KRaft | C Engine (Redis) + Node | Go |
| Idle Memory Footprint | <15 MB RAM | 150MB - 300MB+ | 1GB - 2GB+ | 25MB - 50MB | 35MB - 50MB |
| Cold Boot Time | <5 ms | 15s - 30s | 20s - 45s | <10 ms | <20 ms |
| Hot Path In-Memory Buffer | 5.98 ns (Lock-Free Ring) | Mutex Queues | PageCache Segments | Single-Threaded Loop | Go Channels / Mutex |
| Drop-in Redis Compatibility | Native RESP2/RESP3 | Requires AMQP client | Requires Kafka client | Native Redis | Requires NATS client |
| Native Delayed Message Delivery | O(1) Timing Wheel | Plugin required | External scheduler | ZSET polling loop | Consumer delays |
| Dead Letter Queue & 1-Click Replay | Native Web Studio Replay | Manual shovel/queue | Custom consumer logic | Custom script | NATS CLI |
| Embedded Visual Dashboard | Included in 5.7MB Binary | Plugin (Heavy Erlang UI) | Requires 3rd-party UI | Requires Bull-Board | Separate binary |
| High-Pressure Vulnerability | Zero connection drops | Memory alarm freezes | JVM GC stop-the-world | OOM eviction drops | Storage limit backpressure |
No custom SDKs required. Use standard Redis clients across Go, Python, Node.js, and HTTP.
package main
import (
"context"
"fmt"
"github.com/redis/go-redis/v9"
)
func main() {
ctx := context.Background()
rdb := redis.NewClient(&redis.Options{Addr: "localhost:8379"})
// 1. Publish task to VortexMQ ring buffer
rdb.LPush(ctx, "tasks:billing", `{"user_id": 9468, "invoice_usd": 150}`)
// 2. Consume task with zero-latency blocking pop
res, _ := rdb.BRPop(ctx, 0, "tasks:billing").Result()
fmt.Println("Processed task:", res[1])
}import redis
import json
# Connect directly to VortexMQ port 8379
r = redis.Redis(host='localhost', port=8379, decode_responses=True)
# 1. Publish asynchronous task to topic
r.lpush('tasks:analytics', json.dumps({'event': 'signup', 'user': 'gopher_42'}))
# 2. Worker blocking pop with sub-microsecond pickup
_, payload = r.brpop('tasks:analytics')
print(f"Consumed from VortexMQ: {payload}")import Redis from 'ioredis';
const vmq = new Redis({ port: 8379, host: '127.0.0.1' });
// 1. Produce message to queue
await vmq.lpush('tasks:notifications', JSON.stringify({ to: 'anshu@google.com', text: 'VortexMQ v1.0 Live' }));
// 2. Consume message with sub-millisecond response
const [, task] = await vmq.brpop('tasks:notifications', 0);
console.log('Worker received:', JSON.parse(task));# 1. Publish directly over HTTP REST on port 8380
curl -X POST http://localhost:8380/api/publish \
-H "Content-Type: application/json" \
-d '{"topic": "orders", "payload": "{\"order_id\": \"vmq_1001\", \"usd\": 49.99}"}'
# 2. Check broker telemetry & live consumer lag
curl http://localhost:8380/api/metrics# Build and run native CLI tool
./bin/vortexmq-cli -port 8379
vortexmq:8379> LPUSH critical:tasks "hello from cli"
(integer) 1
vortexmq:8379> RPOP critical:tasks
"hello from cli"
vortexmq:8379> VMQ.STATS
Active Topics: 1 | Memory: 12.4 MB | Uptime: 2hDetailed technical answers covering performance, persistence guarantees, and migration paths.
head & mask) instead of expensive modulo division. Message pointers are pooled and reused on hot publish and pop paths, completely avoiding Go runtime garbage collector overhead and cache thrashing.
always, everysec, none) allow you to balance strict durability with maximum throughput. Upon server restart, the WAL is replayed sequentially into memory in milliseconds with automatic repair of incomplete tail writes.
linux/amd64 and linux/arm64, compressed to just 3.7MB. With an idle footprint under 15MB RAM and sub-5ms boot times, it is ideal for edge IoT nodes, Raspberry Pi clusters, and cloud ARM servers.
Join thousands of engineers deploying lightweight, crash-resilient streaming with zero Erlang or JVM baggage.