Data Panda brings the queues, exchanges and dead-letter traffic flowing through your RabbitMQ broker together with the data from the rest of your business. From one place, we turn it into dashboards, automations, AI workflows and custom apps your team uses every day.
RabbitMQ is an open-source broker that moves messages between producers and consumers over AMQP 0-9-1, AMQP 1.0, MQTT 5.0, STOMP and its own Stream protocol. Producers publish to exchanges, exchanges route by binding into queues, and consumers pull or get pushed the messages on a channel inside a long-lived TCP connection. The model is the smart-broker side of messaging: routing, retries, TTL, priorities, dead-lettering and access control sit in the broker, not in every consumer.
It started in 2007 at Rabbit Technologies, was acquired by SpringSource in 2010, moved through Pivotal and back to VMware, and now sits inside Broadcom, distributed under MPL 2.0. The Erlang core is why thousands of teams quietly run it as the bus between order intake and fulfilment, between webhook ingestion and downstream workers, between IoT devices and the rest of the stack.
The point of pulling RabbitMQ into a warehouse is not to land the message payloads themselves, those are usually transient and belong on the hot path. It is to make the broker layer visible: queue depth per service over time, publish and deliver rates per exchange, channel and connection counts per app, dead-letter volume per reason, vhost split per tenant. That data sits next to Salesforce revenue, Stripe billing and the application database, and the question of whether last Tuesday's slowdown was the broker, the consumer or the source system stops being a guess.
Queue, exchange and dead-letter telemetry joined to revenue and CRM in SQL.
Let RabbitMQ state changes fire actions across the rest of the stack.
Use broker telemetry to score behaviour and predict where the next backlog is forming.
Internal tools that read RabbitMQ telemetry without management UI access.
A list of concrete reports, automations and AI features we have built on RabbitMQ data. Pick the one that matches your situation.
Why did orders pile up in RabbitMQ on Tuesday?
Queue depth, consumer lag, dead-letter volume and node memory plotted on the same timeline as deploys, traffic and downstream consumer health. The Tuesday backlog story stops being a guess between platform, services and the source system, and becomes a chart everyone reads the same way.
Which dead-letter reasons keep coming back, and from which queue?
DLX traffic broken down by reason (rejected, TTL expired, queue length exceeded, delivery limit hit) per source queue and consumer. Surfaces the consumer that quietly nacks every Nth message, the queue with a TTL set too low for downstream latency, and the spike pattern that maps to a specific deploy.
What does our broker cost us per tenant?
Broker spend joined to message volume, queue count and connection count per vhost and tenant in the warehouse. The infrastructure line gets a denominator, and account managers can talk concretely about which tenants drive the next cluster upgrade.
Broker spend tied to message volume, vhost and tenant. The RabbitMQ cluster line stops being a flat infrastructure cost and gets a per-customer denominator finance can defend in the budget review.
Per-tenant message throughput and queue use surfaced on the CRM account. Account managers can talk concretely about plan limits, overage and upgrade triggers without waiting for engineering to dig out a number from the management UI.
Queue depth, dead-letter volume, consumer lag and node pressure kept in one place across deploys and traffic spikes. The on-call post-mortem starts from a chart, not from a hunch about which service was slow.
These are the 2 tables we currently pull from RabbitMQ into your warehouse. Query them directly in SQL, join them to the rest of your stack, or build reports on top.
Missing a table you need? We can extend the sync. Tell us what is missing and we will build it for you.
You keep the reporting tool you already have. We connect it to the warehouse where your RabbitMQ data lives.
OAuth authentication. Read-only by default. We sign a DPA and your admin keeps the keys.
Data flows into your warehouse on your schedule. Near real time or nightly, your call. You own the data.
We build the first dashboard, workflow or AI feature with you, then hand over the keys. Or we stay on for ongoing delivery.
We set up the foundation. Your team builds on top.
Best fit Teams that already have a BI analyst or data engineer and want to own the build.
We build the whole thing, end to end.
Best fit Teams without in-house BI or dev capacity. You tell us what you need and we deliver it.
You do. It lands in your warehouse, on your cloud account. We don't resell or aggregate it. If you stop working with us, the warehouse stays yours and keeps running.
Near real time for most operational systems. For heavier sources we schedule hourly or nightly. You pick based on what the reports need.
No. If you don't have one, we help you pick one and set it up as part of the first delivery. Common starting points are Snowflake, Microsoft Fabric, or a small Postgres start.
No, and that is on purpose. Message payloads are usually transient and belong on the hot path between services. We pull the management-API metadata: queue depth, publish and deliver rates, connection and channel counts, dead-letter activity per reason, node resource use. That metadata is what answers ops and capacity questions. If a specific queue carries records you do want in the warehouse, we tee those off explicitly per queue, with retention and PII rules attached.
The RabbitMQ management plugin is documented for basic observability and aggregates stats periodically. We pull at intervals that match what the management UI itself does, scoped per vhost, and we cache locally so a warehouse refresh does not multiply the load. For high-volume clusters we lean on the metrics the broker already aggregates rather than fanning out per-queue calls.
We review your RabbitMQ setup and the systems around it. Together we pick the first thing worth building.