Skip to content

Queen MQModern PostgreSQL-backed Message Queue

High-performance, feature-rich message queue system with unlimited FIFO partitions, consumer groups, transactions, and streaming capabilities

Queen MQ Logo

πŸ“š Documentation ​

Why We Built Queen MQ ​

🏨 Born from Real Production Needs

Queen was created at Smartness to power Smartchat - an AI-powered guest messaging platform for the hospitality industry.

The Context ​

At Smartness, we use Kafka extensively across our infrastructure and know it well. For Smartchat's message backbone, we initially chose Kafka for its strong reliability guarantees.

However, we encountered a use case mismatch: in Kafka, a single message processing delay affects the entire partition. For most workloads this isn't an issue, but our system involves:

  • AI translations - Can take seconds/minutes
  • Agent responses - Can take seconds/minutes
  • Variable processing times - Inherent to the domain

With potentially 100,000+ concurrent chats, we would need a Kafka partition for each chat conversation - which isn't practical at that scale.

From Custom Tables to Queen ​

We started moving long-running operations to custom PostgreSQL queue tables. As we built out the system, we needed:

  • Consumer groups - For different processing pipelines
  • Window buffering - To aggregate messages before AI processing
  • Retry limits - For better error visibility
  • Message tracing - For debugging distributed workflows

We realized we had built a complete message queue system that better fit our specific requirements.

The Result ​

Queen now handles Smartchat's message infrastructure:

  • One partition per chat - Slow processing in one chat doesn't affect others
  • Unlimited partitions - Scale to any number of concurrent conversations
  • Window buffering - Aggregate messages to optimize API calls
  • Built-in observability - Retry mechanisms and tracing for debugging
  • PostgreSQL-backed - ACID guarantees with automatic failover

Queen processes 100,000+ messages daily in production.

Technical Note

If you're building systems where message processing has inherently variable latency (chat systems, AI pipelines, human-in-the-loop workflows), Queen's partition model may be a better fit than traditional streaming platforms.

Quick Example ​

javascript
import { Queen } from 'queen-mq'

// Connect
const queen = new Queen('http://localhost:6632')

// Create queue with configuration
await queen.queue('orders')
  .config({ leaseTime: 30, retryLimit: 3 })
  .create()

// Push messages with guaranteed order per partition
await queen.queue('orders')
  .partition('customer-123')
  .push([{ data: { orderId: 'ORD-001', amount: 99.99 } }])

// Consume with consumer groups for scalability
await queen.queue('orders')
  .group('order-processor')
  .concurrency(10)
  .batch(20)
  .autoAck(false)
  .each()
  .consume(async (message) => {
    await processOrder(message.data)
  })
  .onSuccess(async (message) => {
    await queen.ack(message, true, { group: 'order-processor' })
  }).onError(async (message, error) => {
    await queen.ack(message, false, { group: 'order-processor' })
  })

Performance Metrics ​

200K+
Messages/Second
10-50ms
Latency
Unlimited
Partitions
Zero
Message Loss

Key Features Comparison ​

FeatureQueenRabbitMQKafkaRedis Streams
FIFO Partitionsβœ… UnlimitedβŒβœ… Limitedβœ… Limited
Consumer Groupsβœ…βš οΈ Manualβœ…βœ…
Transactionsβœ… Atomic⚠️ Complex⚠️ Limited❌
Long Pollingβœ… Built-inβœ…βŒβœ…
Dead Letter Queueβœ… Automaticβœ…βš οΈ Manual❌
Message Replayβœ… TimestampβŒβœ…βœ…
Persistenceβœ… PostgreSQLβœ… Diskβœ… Disk⚠️ Memory
Distributed Cacheβœ… UDPSYNCβŒβœ… ZooKeeper❌
Web Dashboardβœ… Modern⚠️ Basic⚠️ External❌

Use Cases ​

🏒 Enterprise Workflows ​

Build reliable multi-step workflows with transactions and exactly-once delivery. Perfect for financial systems, order processing, and data pipelines.

πŸ“Š Real-time Analytics ​

Stream messages to multiple consumer groups for different analytics purposes. Replay historical data from any timestamp.

πŸ”„ Event-Driven Architecture ​

Decouple microservices with guaranteed message delivery. Built-in tracing helps debug distributed systems.

πŸ’Ό Task Queues ​

Distribute work across multiple workers with automatic load balancing. Long-running tasks supported with lease renewal.

Architecture ​

Queen uses a high-performance acceptor/worker pattern with fully asynchronous, non-blocking PostgreSQL architecture:

  • Network Layer: uWebSockets with configurable workers (default: 10)
  • Database Layer: Async connection pool (142 non-blocking connections)
  • Failover Layer: Automatic disk buffering when PostgreSQL unavailable
  • Distributed Cache: UDP-based state sync between servers (UDPSYNC)
  • Background Services: Poll workers, metrics, retention, eviction

Learn more about the architecture β†’

Built by Developers, for Developers ​

Queen was created by Smartness to power their hospitality platform. It's built with modern C++17, uses PostgreSQL for ACID guarantees, and includes a beautiful Vue.js dashboard.

πŸŽ‰ Production Ready

Queen is currently running in production, handling millions of messages daily. Version 0.8.0 is stable and ready for your projects.

Get Started in Minutes ​

bash
# Start PostgreSQL and Queen server
docker network create queen
docker run --name postgres --network queen \
  -e POSTGRES_PASSWORD=postgres -p 5432:5432 -d postgres

docker run -p 6632:6632 --network queen \
  -e PG_HOST=postgres -e PG_PASSWORD=postgres \
  smartnessai/queen-mq:0.8.0

# Install JavaScript client
npm install queen-mq

# Or install Python client
pip install queen-mq

# Start building!

Full Quick Start Guide β†’

Community & Support ​

License ​

Queen MQ is released under the Apache 2.0 License.

Built with ❀️ by Smartness