01
Emergency Incident Response
Ingestion stopped, segments unavailable, brokers timing out, or a Coordinator that won't hold a stable view of the cluster. A senior engineer joins a live bridge within 15 minutes with access to diagnose.
Druid Support
24/7 Apache Druid Support with a 15-Minute Emergency SLA
Last reviewed by Scott Sternloff
AceMQ supports Apache Druid in production — Kafka supervisors falling behind, segments that never hand off to deep storage, brokers timing out because a query touches fifty thousand segments, and compaction that quietly stopped running months ago. Every ticket reaches a named senior engineer who knows your tier layout.
Support quotes answered within 1 hour, by a senior engineer.
- min emergency SLA
- 15
- across Americas, EMEA, APAC
- 24/7
- enterprise customers
- 160+
- countries served
- 26+
Planning a build, upgrade or migration instead? See AceMQ Apache Druid consulting and services.
Customers
Partners
Incident Triage
Apache Druid problems we fix every week
These are real symptoms from real Apache Druid production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| Real-time data is hours behind Kafka with no error in the UI | Supervisor status for failed or repeatedly restarting indexing tasks, then per-partition consumer lag. A task that dies and is resurrected on a loop keeps the supervisor reported as running while the offsets barely advance, so the lag is the only honest signal. | 1–2 hours |
| Segments are built but never become queryable | Whether handoff completed — deep storage writes succeeding, metadata store entries created, and Historical nodes with free capacity to load them under the current load rules. Handoff waits for a Historical to accept the segment, so a full tier stalls it indefinitely. | 1–3 hours |
| Broker queries time out on wide time ranges but work on narrow ones | How many segments the query fans out to. Too-fine segmentGranularity over a long retention produces tens of thousands of small segments, and the merge cost at the Broker dominates before any Historical is even busy. | 2–4 hours |
| Query performance degrading steadily week over week | Auto-compaction status in the Coordinator. Compaction that is unconfigured, disabled, or starved of task slots leaves the cluster accumulating small segments forever — performance decays on a schedule rather than falling over, which is why it goes unnoticed for months. | 1–3 hours |
| Ingestion tasks queue and never start | MiddleManager worker capacity against the number of concurrent supervisors and their task counts. Long-running realtime tasks hold slots for the full task duration, so a handful of streaming supervisors can consume every slot and starve batch ingestion completely. | Under 2 hours |
| Segment sizes exploded after enabling rollup | Dimension cardinality in the ingestion spec. Rollup only compresses rows that share every dimension value, so one high-cardinality dimension — a request id, a session id, a raw user agent — reduces the rollup ratio to nearly nothing while the index grows. queryGranularity matters just as much. | 2–4 hours |
| Recent data queries suddenly hitting slow cold-tier segments | Coordinator load rules. A period-based rule that no longer covers your actual query window, or a tier with insufficient capacity, silently moves recent segments to a cheaper tier or leaves them unloaded and served from deep storage. | Under 2 hours |
| Coordinator or Overlord flapping, cluster state inconsistent | ZooKeeper health and metadata store latency together. Druid depends on both for coordination and segment bookkeeping, and a slow PostgreSQL or MySQL metadata database presents as Druid instability rather than as a database problem. | Same day |
Resolution times reflect typical Apache Druid engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.
What's Included
Everything in your Apache Druid support contract
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
- 02
Root Cause Analysis
Every P1 closes with a written RCA: what failed, why, the fix applied, and the ingestion spec, granularity, or capacity change that prevents recurrence. Delivered as standard, not on request.
- 03
Ingestion Pipeline Review
Kafka and Kinesis supervisor specs, task count and duration sizing, late-arriving data handling, and the schema and rollup decisions that determine segment size long before anyone sees a slow query.
- 04
Segment & Compaction Strategy
Segment granularity matched to retention and query patterns, auto-compaction configured with dedicated task capacity, and target segment sizing that keeps the Broker's fan-out cost manageable.
- 05
Cluster Sizing & Tiering
Per-role JVM heap and direct memory tuning for Broker, Historical, MiddleManager, and Coordinator, plus hot and cold tier load rules that match where your queries actually land.
- 06
Upgrades & Migrations
Rolling version upgrades across the full node set in the correct order, moves between self-managed and Imply, deep storage migrations, and migrations onto Druid from Elasticsearch or a warehouse.
Why AceMQ
What you get that you don't get elsewhere
Named Engineers, Zero Cold Start
The same senior engineers stay on your account. They know your tier layout, your supervisor specs, and your retention rules — so a P1 call opens with a hypothesis rather than a tour of your cluster.
No First-Line Triage Layer
You reach a senior Druid engineer directly by phone, email, or Slack. Nobody collects details to hand off, and no escalation approval stands between you and someone who can read a supervisor payload.
We Understand the Whole Process Set
Druid is six coordinating services with different memory models and failure modes. Most incidents are misattributed to the process that reported the error rather than the one that caused it — Historical capacity showing up as a Broker timeout, for instance.
Ingestion and Query, Not Just One
Query performance in Druid is decided at ingestion time by granularity, rollup, and partitioning. We fix the spec that created the segments rather than tuning around the segments you already have.
Genuine Follow-the-Sun Coverage
Engineers across 26+ countries and every time zone. Your 3am supervisor failure is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to wake up.
Full-Stack, Including the Dependencies
We diagnose across Kafka, ZooKeeper, the metadata database, deep storage latency, the JVM, and Kubernetes. Druid rarely fails alone, and its dependencies fail in ways that look like Druid bugs.
We support Apache Druid wherever it's deployed
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
- Apache Druid 26 – 31 (self-managed)
- Imply Enterprise & Imply Polaris
- Druid Operator on Kubernetes
- OpenShift
- AWS (EC2, EKS, S3 deep storage)
- Microsoft Azure (AKS, Blob deep storage)
- Google Cloud (GKE, GCS deep storage)
- HDFS deep storage
- ZooKeeper & PostgreSQL/MySQL metadata store
- Kafka & Kinesis streaming ingestion
- Bare metal & on-premise
- Air-gapped / no outbound access
Version coverage
Apache Druid releases and what the project supports
Apache Druid is a community project with no vendor behind it, and it publishes no support window for older release lines. The project recommends running the latest stable release, so a cluster that has not been upgraded for a year or two has no promised upstream fixes. AceMQ supports self-managed Druid and Imply independently of the project.
| Apache Druid release | Released | Project position | AceMQ cover |
|---|---|---|---|
| 38.0.0 (latest stable) | 2026 | The release the project recommends running | 24/7 support and upgrade planning |
| 37.0.0 | 2026 | Previous release, listed on the downloads page | 24/7 support and upgrade planning |
| Older releases | Apache archive | No published support window | 24/7 support and upgrade planning |
Source: the Apache Druid downloads page (druid.apache.org/downloads), checked 20 October 2026. AceMQ response times: 15 minutes for emergencies, 1 hour for critical issues, 4 hours for high-priority issues and the next business day for standard questions.
Escalation Path
Your first hour of an Apache Druid outage
Every tier reaches a senior Apache Druid engineer. There is no tier-1 triage layer to get through.
- 15 minfirst responseEmergencyProduction down, messages not flowing, queue manager failure
- 1 hourfirst responseCriticalSevere degradation, high error rates, approaching capacity
- 4 hoursfirst responseHighPerformance issues, configuration problems, non-critical failures
- Next Dayfirst responseStandardQuestions, guidance, best practices, non-urgent improvements
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
T+Elapsed15:00
15-minute P1 response, 24/7.
A response time, not a resolution time.
- T+00:00Paged
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
- T+15:00Live
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
- T+30:00If needed
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
- AfterEvery P1
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Pricing
What does AceMQ Apache Druid support cost?
AceMQ Apache Druid support contracts typically run $24,000–72,000 a year, depending on SLA level, scope (number of clusters or nodes, and environments) and deployment (self-managed, cloud-managed or Kubernetes).
| What moves the price | How it changes the contract |
|---|---|
| SLA level | Business-hours cover costs less than 24/7 cover with a 15-minute emergency response. |
| Scope | More clusters or nodes, and more environments, make a larger contract. |
| Deployment | Self-managed, cloud-managed and Kubernetes estates need different amounts of hands-on work. |
Covering several technologies under one contract, for example RabbitMQ, Kafka and Redis, earns an aggressive discount.
Support In Practice
Apache Druid problems we've already solved
Apache Druid support and remediation work from AceMQ. Each card links to the full write-up: the cluster, what AceMQ diagnosed or changed, and the result.
Apache Druid Streaming Ingestion Lag Remediation
Digital Advertising Exchange
Resolving Kafka supervisor lag caused by task slot exhaustion, oversized ingestion tasks, and handoff failures to deep storage.
Apache Druid
Kafka
Kubernetes
PrometheusApache Druid Query Performance Support
Retail Analytics Provider
Ongoing support for broker timeouts and unpredictable query latency driven by segment sizing, cache behavior, and processing thread contention.
Apache DruidKafkaKubernetesPrometheusApache Druid Tiered Historical Architecture Assessment
Energy Utility Operator
Assessment of historical tiering, retention rules, and replication factors to align infrastructure cost with how data is actually queried over time.
Apache Druid
S3KubernetesPrometheusApache Druid Segment Granularity and Compaction Design
Telecommunications Operator
Redesigning segment granularity, partitioning, and auto-compaction policy so segment counts stay bounded as historical data accumulates.
Apache DruidKafka
LinuxPrometheus
Support options
Four tiers of Apache Druid support.
AceMQ offers Apache Druid support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for clusters your team runs, proactive monitoring that catches supervisor lag, segment sprawl and full tiers first, managed Druid on your own infrastructure, and fully managed Druid on AceMQ infrastructure. Self-managed Druid, Imply Enterprise and Imply Polaris estates are covered.
- Tier 1
Apache Druid 24/7 Support & Incident Management
You run it, we back you up
- A live bridge in 15 minutes, 24/7, for stalled ingestion and unavailable segments
- Diagnosis from supervisor status, per-partition lag, handoff timing and Historical capacity
- Kafka, ZooKeeper, the metadata store and deep storage checked as part of the incident
Best for: Teams that run Druid themselves and need senior cover when dashboards go stale at 3am.
- Tier 2
Apache Druid 24/7 Support with Proactive Monitoring
You run it, we watch it with you
- Supervisor, task slot and per-partition lag checks against partition count
- Segment size, compaction status and rollup ratio reviews
- Load rules and tier capacity checked against where queries land
Best for: Teams that want the slow decay of segment sprawl found in a review, not after a year of creeping latency.
- Tier 3
Managed Apache Druid on Your Infrastructure
We run it in your cloud or data centre
- 24/7 monitoring across every service role, not only the one that reports the error
- Compaction run with its own task capacity
- Tier and load rule changes made incrementally so queries keep serving
Best for: Regulated estates that must keep analytics data inside their own boundary.
- Tier 4
Fully Managed Apache Druid on AceMQ Infrastructure
We host it and run it, as a service
- Tiers sized for how your data is queried over time
- Kafka supervisors tuned with your team against partition count
- Upgrades, patching and compaction owned by AceMQ
Best for: Teams that want real-time analytics on Druid without a six-service cluster to run, and do not need it in their own account.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Apache Druid day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for Apache Druid
Everything else AceMQ does for Apache Druid.
Support is one part of what AceMQ does for Apache Druid. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
- ConsultingApache Druid consulting and services
- LifecycleEnd-of-life software support
- Enterprise supportOpen source support across your whole stack
- GuideApache Druid guide
Support for the rest of your stack
Messaging & Streaming
- RabbitMQ supportMessaging & Streaming
- Apache Kafka supportMessaging & Streaming
- IBM MQ supportMessaging & Streaming
- ActiveMQ supportMessaging & Streaming
- Azure Service Bus supportMessaging & Streaming
- Amazon SQS supportMessaging & Streaming
- Google Cloud Pub/Sub supportMessaging & Streaming
- Redpanda supportMessaging & Streaming
- Apache Pulsar supportMessaging & Streaming
- Message Queuing supportMessaging & Streaming
Databases & Caching
Search & Analytics
Lakehouse & Compute
Observability & Monitoring
Data Integration
Cloud & Containers
API Management
See support for all 51 technologiesShow fewer
Related services
What do AceMQ's Apache Druid support services include?
Druid support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, ingestion pipeline review, segment and compaction strategy, cluster sizing and tiering, CVE and patch advisory, quarterly health checks, and upgrade or migration support. Every ticket goes to a named senior engineer assigned to your account. There is no first-line triage layer and no per-incident charge.
Our Kafka ingestion keeps falling behind. Where do you start?
With the supervisor status and per-partition consumer lag, because those two together tell you whether tasks are failing or simply undersized. The most common cause is indexing tasks dying and being restarted in a loop, which keeps the supervisor reporting as running while offsets barely move — often from a parse exception on a malformed record, or a task exceeding its heap on a high-cardinality dimension. The second most common is task slot starvation: the number of tasks per supervisor multiplied by taskDuration exceeds the total worker capacity across MiddleManagers, so new tasks queue rather than run. We fix the failing tasks first for immediate relief, then right-size task count and duration against partition count so the problem doesn't return under the next traffic increase.
How fast do you respond to a Druid production outage?
P1 emergencies — ingestion stopped, segments unavailable, queries failing cluster-wide — get a 15-minute first response with a senior engineer joining a live bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual response times covering nights, weekends, and holidays.
Query performance has degraded slowly over a year. What causes that pattern?
Almost always segment proliferation with compaction not running. Druid answers a query by fanning out to every segment covering the time range, and the Broker merges the results — so cost scales with segment count, not just data volume. Streaming ingestion produces many small segments by design, and auto-compaction is supposed to consolidate them into target-sized segments afterward. When compaction is unconfigured, disabled during an incident and never re-enabled, or perpetually starved of task slots by streaming supervisors, segment count grows every day and query latency decays with it. We check the Coordinator's compaction status, give compaction its own capacity, and then backfill-compact the historical periods that accumulated while it was off.
Do you support Imply as well as open source Apache Druid?
Yes. We support self-managed Apache Druid, Imply Enterprise, and Imply Polaris. Imply packages Druid with additional tooling and its own management layer, but the underlying segment model, ingestion mechanics, and query fan-out behaviour are the same — which is where nearly all production incidents originate. We are careful about the boundary: where a problem is genuinely inside a vendor's proprietary component we will say so and help you drive it through their support rather than pretending to fix it.
Should we be using rollup, and why did enabling it make our segments bigger?
Rollup pre-aggregates rows that share identical values across every dimension at the chosen queryGranularity, so its benefit depends entirely on how much repetition exists in your dimension set. Adding one high-cardinality dimension — a request id, a session id, a full user agent string — makes nearly every row unique, at which point rollup compresses nothing while still paying the indexing cost, and the extra dimension's own index grows the segment. The fix is to move high-cardinality fields out of the rolled-up datasource, or to keep a separate non-rolled-up datasource for the queries that genuinely need per-event detail. We size this from your actual dimension cardinalities rather than from a rule of thumb.
Can we work with AceMQ on Apache Druid without a long contract?
Yes. AceMQ works on Apache Druid in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.
How much does AceMQ Apache Druid support or consulting cost?
Every AceMQ proposal is tailored to your requirements: your Apache Druid environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Apache Druid is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Druid Degrades on a Schedule Long Before It Breaks
Reactive cover, proactive reviews, or AceMQ running Apache Druid for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
A senior Apache Druid engineer, not a sales queueQuote requests answered within 1 hourAd hoc engagements or an annual partnership
Production incident right now?Email an Apache Druid Architect
Get in Touch
Talk to an Apache Druid Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.