Emergency Incident Response
Segment down, master unreachable, or the nightly load failing with the warehouse due at 6am. A senior Greenplum DBA joins a live bridge within 15 minutes with access to diagnose — not a ticket acknowledgement.
Tanzu Greenplum Support
Last reviewed by Scott Sternloff
AceMQ is Broadcom's VMware Expert Advantage Partner of the Year for the Americas. Our senior MPP DBAs run Greenplum in production — segment failures and mirror recovery, distribution skew, spill files filling segment disks, and ORCA plans that broadcast when they should redistribute. Every ticket reaches a named engineer who already knows your cluster layout.
Planning a build, upgrade or migration instead? See AceMQ Greenplum consulting and services.
Customers




Partners


Incident Triage
These are real symptoms from real Greenplum production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| One segment runs 5–10x longer than the rest — query time is a single segment | Row distribution per gp_segment_id on the largest fact tables. A distribution key with low cardinality, heavy NULLs, or a DISTRIBUTED RANDOMLY table joined on a skewed column puts most of the data on one segment, and every query then waits on that segment. | 1–2 days |
| Segment down, cluster running in change-tracking mode after a mirror promotion | gp_segment_configuration for role/preferred_role and mode mismatches, then the failed primary's logs to establish whether the host, the disk, or the process died. That decides gprecoverseg incremental vs. full — and full recovery needs verified disk headroom before it starts. | 2–4 hours |
| Queries abort with "no space left on device", then disk usage drops back to normal | Spill file volume in pgsql_tmp per segment against statement_mem and the gp_workfile limits. A single under-memoried hash join spilling across every segment can fill a data volume in minutes and then clean up after itself, hiding the evidence. | Under 2 hours |
| Append-optimized tables getting slower month over month despite regular VACUUM | Hidden-row fraction on the AO tables and bloat via gp_toolkit. VACUUM on an append-optimized table only compacts a segment file once the hidden fraction crosses gp_appendonly_compaction_threshold — so a table updated in small batches can bloat indefinitely while VACUUM reports success. | Same day |
| A large join went 10x slower after a data load, with no query or schema change | EXPLAIN ANALYZE motion nodes. A Broadcast Motion where a Redistribute Motion belongs — almost always ANALYZE not having run after the load, leaving ORCA with stale cardinality on the newly grown table. | Under 1 hour |
| Queries queue and never start; concurrency collapses during the ETL window | Resource group or resource queue assignment per role via gp_toolkit. Typically one ETL role holding every slot with a memory limit that leaves nothing for interactive users, or a group whose CPU limits were set for a smaller cluster. | 1–3 hours |
| Master out of memory, catalog queries crawling, gpstate slow to return | Catalog bloat on pg_attribute and pg_class from heavy temp-table or partition churn, plus master connection count. Catalog bloat needs a VACUUM FULL in a maintenance window — the reactive fix and the pattern that caused it are separate conversations. | Same day |
Resolution times reflect typical Greenplum 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.
Segment down, master unreachable, or the nightly load failing with the warehouse due at 6am. A senior Greenplum DBA joins a live bridge within 15 minutes with access to diagnose — not a ticket acknowledgement.
Every P1 closes with a written RCA: what failed, why, the fix applied, and the distribution key, resource group, or vacuum policy change that stops it recurring. Delivered as standard, not on request.
EXPLAIN ANALYZE motion analysis, ORCA vs. legacy planner selection, distribution and partition key redesign, statement_mem sizing, and resource group configuration tuned against your actual workload mix.
Mirror pair and standby master verification, gpbackup and gprestore scheduling, restore testing that actually restores, and documented gprecoverseg runbooks your team can execute at 3am without us.
Quarterly reviews of segment disk headroom, skew across your largest tables, spill volume trends, and concurrency ceilings — so you add capacity on a plan rather than during an outage.
As Broadcom's Expert Advantage Partner of the Year, we handle Tanzu Greenplum subscription questions alongside the technical ones: entitlement reconciliation, true-up exposure, renewal terms, and quotes inside 24 hours.
Why AceMQ
AceMQ holds Broadcom's top VMware partner award for the Americas in 2025. That is not a logo on a page — it means escalation paths into Tanzu engineering when a problem is genuinely a product defect, and it means your licensing and your support come from one team.
The same senior DBAs stay on your account. They know your segment count, your distribution keys, and which tables skew — so a P1 starts with diagnosis instead of twenty minutes of you describing your cluster.
You reach a senior Greenplum DBA directly by phone, email, or Slack. No help desk collecting information to pass along, no escalation approval standing between you and someone who can read a motion plan.
Greenplum is Postgres at the surface and something else entirely below it. Distribution, motion, segment-local execution, and append-optimized storage have no single-node analogue — and that is exactly where production incidents originate.
Engineers across 26+ countries and every time zone. Your 3am load failure is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to wake up.
Quarterly health checks plus shared intelligence across our support base. When a version-specific bug surfaces on one customer's cluster, every affected customer hears about it before it reaches their production.
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 Greenplum 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 Greenplum 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
Greenplum support work from AceMQ. Each card links to the full write-up: the cluster, what AceMQ diagnosed or changed, and the result.
Enterprise Technology Organizations
A review of Greenplum segment count, distribution keys, storage selection and vacuum scheduling for petabyte-scale analytics, aimed at the design decisions that cause skew.
Regional Telecom Operator
Recovering a Greenplum cluster that had run on a single copy of its data for seven weeks after a host failure, then rebuilding the mirroring layout so one host loss no longer halves performance.
Global Consumer Goods Manufacturer
Diagnosing queries that queued and never started during the nightly ETL window, and spill files that filled segment disks, then separating workloads with resource queues and memory limits.
Regional Health Benefits Administrator
Planning and rehearsing an upgrade from Greenplum 6 to Greenplum 7 on AWS, including catalog checks, a compatibility review of SQL and extensions, and a tested rollback.
Support options
AceMQ offers Greenplum support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for clusters your DBAs run, proactive monitoring that finds skew, bloat and degraded segments first, managed Greenplum on your own infrastructure, and fully managed Greenplum on AceMQ infrastructure. Greenplum 5.x, 6.x and 7.x are covered, on VMware Greenplum and open-source builds.
You run it, we back you up
Best for: DBA teams that run Greenplum themselves and need senior MPP cover at 3am.
You run it, we watch it with you
Best for: Teams that want a cluster that has been running degraded for weeks found in a review.
We run it in your cloud or data centre
Best for: Regulated estates that must keep the warehouse inside their own boundary.
We host it and run it, as a service
Best for: Teams that want a Greenplum warehouse without a DBA rota.
| 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 Greenplum 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 Greenplum
Support is one part of what AceMQ does for Greenplum. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
Our Tanzu Greenplum support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, query and plan tuning, distribution key and partition redesign, HA and backup verification, version upgrades, and Broadcom licensing support. Every ticket is handled by a named senior DBA assigned to your account. There is no tier-1 triage layer and no per-incident charge.
Broadcom's support handles vendor-side defects and patch escalations, and it is genuinely good at that. What it does not do is operate your cluster. AceMQ provides hands-on production DBA coverage — reading motion plans, rebuilding distribution keys, running gprecoverseg, sizing statement_mem for your workload. Most of our Greenplum customers run both in parallel, and because we are a Broadcom Expert Advantage Partner we can escalate into Tanzu engineering on your behalf when a problem really is a product bug.
P1 emergencies — segments down, master unreachable, warehouse unavailable — get a 15-minute first response with a senior DBA 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, not best-effort targets.
Usually, yes. Skew is a per-table property, not a cluster property, so the fix is redistributing the affected tables rather than rebuilding everything. We identify the skewed tables by row count per gp_segment_id, pick a distribution key with enough cardinality that also serves your dominant join pattern, and redistribute during a window. On very large fact tables this can take a day or more of elapsed time, which is why it is the longest resolution on our triage list — but it is nearly always cheaper than living with it.
Yes. We handle 5.x to 6.x and 6.x to 7.x upgrades with documented rolling procedures, pre-upgrade catalog checks, and a tested rollback plan. We also execute migrations onto Greenplum from Teradata, Oracle, Netezza, and Vertica, including SQL dialect translation and row-level validation before cutover.
Yes, and this is a common reason Tanzu customers call us. As Broadcom's VMware Expert Advantage Partner of the Year for the Americas, we reconcile deployed cluster capacity against purchased entitlements, flag true-up exposure before an audit finds it, and negotiate renewal and multi-year terms. Licensing quotes come back within 24 hours, and the engineers who size your cluster are the same team advising on what you actually need to license.
Greenplum Database is a massively parallel processing database system built on PostgreSQL, used for data warehousing and analytics across very large datasets: a coordinator plans each query and segments execute it in parallel. We support VMware Greenplum, now sold by Broadcom as Tanzu Greenplum, and the open-source Greenplum builds that lost their upstream when the project went closed source in 2024, on Greenplum database versions 5.x, 6.x and 7.x. Platforms covered are bare metal and virtual machines on Red Hat and other supported operating systems, vSphere, and public cloud deployments on AWS, Azure and GCP. Coverage includes the tooling around the database: PXF, the Platform Extension Framework used to query external data sources, gpbackup and gprestore, JDBC and ODBC connectivity for BI tools, and the gpsupport utility for collecting log files when a case needs escalating to Broadcom.
Most calls are about a Greenplum database cluster that is slow rather than down. We check segment and mirror health first, then free space and log files, then the query: distribution keys that skew data across segments, missing statistics, resource queues or resource groups that starve concurrent work, spill files from queries that exceed their memory, and catalog bloat that slows every operation. Configuration reviews cover the operating system settings Greenplum depends on, connection pooling, and compatibility between the Greenplum version, the client drivers and the ETL tools that load it. The aim is to leave the cluster with documented settings and a runbook, so the next incident is shorter.
Yes. AceMQ works on Greenplum 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 Greenplum 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 Greenplum 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 Greenplum 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 Greenplum 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.