Emergency Incident Response
Coordinator down, queries hanging cluster-wide, or a connector that won't authenticate. A senior engineer joins a live bridge within 15 minutes.
Starburst Support
Last reviewed by Scott Sternloff
AceMQ supports Starburst's federated Trino engine in production — queries that hang behind the slowest connector, coordinator OOM from unbounded metadata enumeration, and predicate pushdown that silently stopped happening. Every ticket reaches a named senior engineer.
Planning a build, upgrade or migration instead? See AceMQ Starburst consulting and services.
Customers




Partners


Incident Triage
These are real symptoms from real Starburst production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| A federated query across catalogs hangs on one connector | The query plan via EXPLAIN ANALYZE for a connector-level bottleneck. The slowest connector without pushdown support serializes the entire query behind it, regardless of how fast the others are. | 1–2 hours |
| Coordinator runs out of memory on a specific query pattern | Whether the query is missing a LIMIT or WHERE clause against a huge external table, forcing full metadata and split enumeration to happen on the coordinator itself. | Under 2 hours |
| A filter or aggregation isn't pushing down, data transfer balloons | Connector session properties and EXPLAIN output for pushdown eligibility. Some connector versions silently disable pushdown for specific data types without an error. | 1–3 hours |
| Worker nodes hit memory limits mid-query | query.max-memory-per-node against the actual working-set size for large joins and aggregations. Task retries often mask an undersized worker heap rather than a query design problem. | 2–4 hours |
| An Iceberg, Delta, or Hive connector returns stale metadata | Metastore cache TTL and whether a concurrent writer bypassed the catalog's metadata refresh path — common when a separate Spark or Databricks job writes to the same table. | 1–2 hours |
| Queries queue heavily under concurrent BI dashboard load | Resource groups configuration. A single default resource group with no per-group concurrency limits lets one dashboard starve every other workload on the cluster. | Under 2 hours |
| Catalog configuration drifts between environments | Catalog properties files against source-of-truth config management — a manually edited catalog file on one coordinator is the usual root cause of drift. | 1–2 hours |
Resolution times reflect typical Starburst engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
Coordinator down, queries hanging cluster-wide, or a connector that won't authenticate. A senior engineer joins a live bridge within 15 minutes.
Every P1 closes with a written RCA: what failed, why, the fix applied, and the configuration change that prevents recurrence.
Pushdown validation, connector session property tuning, and worker memory sizing matched against your actual federated query patterns.
Resource group design so one heavy dashboard or ad hoc query can't starve every other workload sharing the cluster.
Configuration audits across multi-catalog federated setups to catch drift before it produces a query result nobody can explain.
Federated query architecture design, connector onboarding, and migration from single-engine query tools onto Starburst.
Why AceMQ
The same senior engineers stay on your account. They know your catalog topology and which connectors actually push down — so a P1 starts with diagnosis, not you re-explaining your setup.
You reach a senior Starburst engineer directly by phone, email, or Slack. No help desk, no escalation approval process standing between you and someone who can fix it.
Federated query problems live at the connector boundary, not just the Trino engine. We diagnose pushdown behavior across Iceberg, Delta, Hive, and JDBC connectors, not just the coordinator.
We support Starburst alongside Databricks and Snowflake as a connected stack, so a federated query problem that's really a source-system problem gets diagnosed end-to-end.
Engineers across 26+ countries and every time zone. Your 3am coordinator OOM is someone's mid-afternoon — no overnight skeleton crew.
Starburst problems are frequently metastore, network, or source-system problems wearing a query timeout. We diagnose across the whole path, not just the Trino layer.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Escalation Path
Every tier reaches a senior Starburst engineer. There is no tier-1 triage layer to get through.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
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.
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.
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.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Pricing
AceMQ Starburst 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
Starburst and Trino support and remediation work from AceMQ. Each card links to the full write-up: the federated estate, what AceMQ diagnosed or changed, and the result.
Public Sector Agency
Evaluating whether a federated query layer will actually work against a given set of source systems before the platform is committed to.
Global Payments Processor
Stopping worker crashes caused by unbounded joins, missing spill configuration, and memory limits that do not match the concurrency the cluster actually sees.
Energy Trading Firm
Named-engineer support for Starburst and Trino latency regressions, connector failures, and concurrency problems in production.
Global Logistics Operator
Making predicates, aggregates, and joins execute at the source connector instead of pulling full tables into Trino workers.
Support options
AceMQ offers Starburst 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 finds pushdown, memory and metastore problems first, managed Starburst Enterprise or Trino on your own infrastructure, and fully managed Trino on AceMQ infrastructure. Enterprise LTS releases and open-source Trino are covered.
You run it, we back you up
Best for: Data platform teams that run Starburst Enterprise or Trino themselves and need senior escalation cover.
You run it, we watch it with you
Best for: Teams that want the missing pushdown or the stale metastore found in a review, not during a dashboard outage.
We run it in your cloud or data centre
Best for: Regulated estates that must keep query infrastructure inside their own network, including air-gapped sites.
We host it and run it, as a service
Best for: Teams that want federated queries without owning a query engine's operations.
| 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 Starburst 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 Starburst
Support is one part of what AceMQ does for Starburst. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
Our Starburst support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, query performance and pushdown tuning, resource group and concurrency tuning, catalog configuration management, and migration support. Every ticket reaches a named senior engineer with no tier-1 triage layer.
Yes. Federated query performance problems almost always trace to one connector not pushing filters or aggregations down to the source, which forces Starburst to pull far more data than necessary. We check EXPLAIN ANALYZE output connector-by-connector to find exactly where the query stops being efficient.
Yes. We support the full range of catalog connectors Starburst federates across, including metadata sync issues that show up when a separate Spark or Databricks job writes to a table Starburst also queries.
Through resource group configuration. A cluster with a single default resource group has no way to limit how much concurrency any one workload can consume, so we design resource groups with per-team or per-workload concurrency caps matched to your actual usage patterns.
P1 emergencies — coordinator down, queries hanging 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 targets.
Yes. Many enterprises use Starburst specifically to federate across Databricks, Snowflake, and other sources without moving data. We support all three, so a problem that looks like a Starburst issue but is actually a source-system issue gets diagnosed correctly the first time.
Yes. AceMQ works on Starburst 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.
Every AceMQ proposal is tailored to your requirements: your Starburst 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 Starburst is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Reactive cover, proactive reviews, or AceMQ running Starburst for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
Production incident right now?Email a Starburst Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.