Queen MQ introduces ACID message broker with per-entity queues and strong consistency

GitHub user queen-mq has released Queen, an open-source message broker designed to provide ACID (Atomicity, Consistency, Isolation, Durability) guarantees for distributed messaging. Published on November 10, 2026, this Rust-based system aims to simplify backend architecture by treating every customer, order, or conversation as its own queue, ensuring that state changes and message acknowledgments commit together as a single transaction.

What happened

The release introduces a broker that moves away from traditional eventual consistency models often found in high-throughput systems. Instead of relying on separate mechanisms for locking, scheduling, or retrying failed messages, Queen integrates these capabilities directly into its transactional core. The project documentation highlights that every step in a workflow, including the acknowledgment, the next message dispatch, state updates, and timer settings, commits as one atomic unit. This approach removes the complexity of managing Redis locks, cron jobs, or dedicated retry tables.

Queen supports multiple programming languages, including JavaScript, Python, Go, and Rust, and offers features such as stream processing with tumbling, sliding, and session windows. It also includes support for conflating consumer groups, which only deliver the newest message for partitions where only the latest value matters. For request-reply patterns, the broker provides ephemeral in-memory queues that are fast but intentionally lost during crashes, distinguishing them from persistent logs. The system is built to handle complex state management, offering key-value storage, distributed locks, and scheduled timers within the same transactional boundary as message processing.

Key details

• ACID Transactions: Every message operation, including acks, state changes, and timers, commits atomically, ensuring no partial updates occur.
• High Performance Benchmarks: On three GCP nodes with local NVMe, Queen achieved 3 million messages per second with p99 latency of 15-25 ms across up to 10 million partitions.
• Rapid Recovery: A node rejoining a cluster after five minutes of downtime synced only a 1.1 GB delta in 28 seconds, significantly faster than previous versions.
• Language Agnostic: Supports clients in JavaScript, Python, Go, and Rust, and allows unchanged Kafka producers and consumers to connect via a Kafka-compatible port.
• Integrated Storage: The broker can directly write queues to PostgreSQL tables or S3 buckets in JSONL or Parquet formats without requiring external processes.
• Proven Reliability: The software passed 226 Jepsen tests on version 2.7, confirming no acknowledged messages were lost and no leases were held twice.

Background

Message brokers are essential components in modern software architecture, acting as intermediaries that allow different parts of a system to communicate asynchronously. Traditional brokers like Kafka or RabbitMQ often prioritize throughput and availability, sometimes at the cost of immediate consistency. Developers frequently have to build additional infrastructure, such as database-backed retry queues or distributed lock managers, to ensure that business logic remains consistent when messages fail or arrive out of order.

ACID properties, typically associated with relational databases, ensure that transactions are processed reliably. Atomicity means all parts of a transaction succeed or fail together. Consistency ensures the database remains in a valid state. Isolation prevents concurrent transactions from interfering with each other, and Durability guarantees that committed data survives system failures. By bringing these guarantees to message brokering, Queen attempts to reduce the operational burden on engineering teams who previously had to stitch together multiple tools to achieve similar reliability.

Why it matters

For teams running their own software, the promise of ACID compliance in a message broker can significantly reduce architectural complexity. Currently, many self-hosted applications require a combination of a message queue, a relational database for state, and a separate store for distributed locks. Managing the consistency between these three systems is a common source of bugs and operational overhead. If Queen delivers on its claims, developers could replace this triad with a single component, simplifying deployment, monitoring, and debugging.

The performance benchmarks suggest that this simplicity does not come at a severe cost to throughput. Handling 3 million messages per second with low latency is competitive with established players like Redpanda and Pulsar, particularly at high partition counts. For mid-sized companies scaling their infrastructure, the ability to drain 100 GB of lag in 32 seconds and recover nodes quickly can mean the difference between a minor hiccup and a prolonged outage during peak traffic.

However, adopting a new core infrastructure component carries risk. While the Jepsen tests provide confidence in its consistency model, real-world production use cases vary widely. Teams must evaluate whether the specific features, such as per-entity queues and integrated S3 dumping, align with their data retention and processing needs. The Apache-2.0 license allows for commercial use and modification, which is attractive for companies wanting to avoid vendor lock-in while maintaining control over their source code.

What you can do

• Review the documentation: Download "The little book of QueenMQ" PDF to understand the architecture, storage model, and API guarantees before considering adoption.
• Run benchmark tests: Replicate the provided benchmarks using your own hardware or cloud environment to verify if the claimed throughput and latency meet your application requirements.
• Evaluate migration paths: If you currently use Kafka, test the Kafka-compatible port to see if existing producers and consumers can connect without code changes.
• Assess state management needs: Determine if your application logic would benefit from having KV storage, locks, and timers integrated directly into the message transaction flow.
• Test failure scenarios: Use the standby cluster feature and node recovery mechanisms in a staging environment to validate the 28-second rejoin time and data integrity.
• Check language support: Ensure that the client libraries for your primary development languages (JS, Python, Go, Rust) are mature enough for your production standards.