01
Emergency Incident Response
Database unreachable, commits hanging, or a failover that didn't happen. A senior PostgreSQL DBA joins a live bridge within 15 minutes with access to diagnose — not a ticket acknowledgement.
Tanzu Postgres Support
24/7 Tanzu Postgres Support with a 15-Minute Emergency SLA
Last reviewed by Scott Sternloff
AceMQ is Broadcom's VMware Expert Advantage Partner of the Year for the Americas. Our senior DBAs run PostgreSQL on Kubernetes under the Tanzu operator — autovacuum falling behind on freeze, connection storms after a rolling restart, a synchronous standby blocking every commit, and checkpoint stalls that are really PVC IOPS limits. Every ticket reaches a named engineer who already knows your cluster.
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 Tanzu Postgres consulting and services.
Customers
Partners
Incident Triage
Tanzu Postgres problems we fix every week
These are real symptoms from real Tanzu Postgres production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| Wraparound warnings in the log, or the database refuses to accept commands | age(datfrozenxid) per database and the oldest relfrozenxid, then whatever is holding xmin back — normally a stale replication slot, an abandoned prepared transaction, or a long idle-in-transaction session. Autovacuum cannot freeze past the oldest xmin, so raising its aggressiveness does nothing until that holder is cleared. | 2–4 hours |
| "Too many connections" storms every time pods roll | max_connections against pool size multiplied by replica count. Horizontal scaling multiplies client-side pools while the server ceiling stays fixed, so a rolling restart reconnects everything at once. The durable fix is pgbouncer in transaction mode sized to the database, not to the application. | 1–3 hours |
| Commits hanging on the primary while the database looks otherwise healthy | synchronous_standby_names and the standby's flush and replay lag. A synchronous replica on a slower storage class blocks every commit on the primary — the primary's own metrics look fine, which is exactly why this one takes teams so long to spot. | Under 2 hours |
| Periodic write latency spikes and long checkpoint times on Kubernetes | PVC IOPS and burst-credit consumption against checkpoint volume, then checkpoint_timeout, max_wal_size, and bgwriter settings. Most of these are storage class problems wearing a Postgres costume — the tuning helps, but not if the volume runs out of burst credit every afternoon. | 2–4 hours |
| Primary is unhealthy but the operator never promoted a replica | The operator and Patroni health check definition and what it actually probes. A primary that accepts TCP but cannot serve queries — out of connections, or stuck on a full disk — passes a naive readiness probe indefinitely, so failover never triggers. | 2–4 hours |
| Sequential scans and growing disk on a table that should be small | Dead versus live tuple counts in pg_stat_user_tables alongside the oldest idle-in-transaction backend. A long-open transaction anywhere in the cluster prevents vacuum from reclaiming rows everywhere, so the bloat and the offending session are frequently in different applications. | Same day |
| Point-in-time recovery fails, or backups turn out to be incomplete | pg_stat_archiver failed_count and the object-store credentials and retention policy. Failed archive commands accumulate silently for weeks — nothing alerts, nothing degrades, and the gap is discovered at the exact moment you need to restore. | 1–3 hours |
Resolution times reflect typical Tanzu Postgres engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.
What's Included
Everything in your Tanzu Postgres 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 vacuum policy, pool configuration, or storage class change that prevents recurrence. Delivered as standard, not on request.
- 03
Query & Vacuum Tuning
EXPLAIN ANALYZE plan review, index strategy across B-tree, GIN, GiST, and BRIN, autovacuum sizing for your write pattern, partitioning for large tables, and pgbouncer pool configuration that matches your workload.
- 04
Operator & Kubernetes Operations
Tanzu Postgres operator upgrades, instance CR changes, storage class and PVC sizing, pod anti-affinity for zone-aware placement, and health checks that actually detect an unhealthy primary.
- 05
Backup, PITR & DR Assurance
WAL archiving verified end to end, restore testing that performs a real restore on a schedule, retention policy review, and documented recovery runbooks with measured recovery times rather than estimates.
- 06
Broadcom Licensing & Entitlement
As Broadcom's Expert Advantage Partner of the Year, we handle Tanzu for PostgreSQL subscription questions alongside the technical ones: entitlement reconciliation, true-up exposure, renewal terms, and quotes inside 24 hours.
Why AceMQ
What you get that you don't get elsewhere
Broadcom Expert Advantage Partner of the Year
AceMQ holds Broadcom's top VMware partner award for the Americas in 2025. That means an escalation path into Tanzu engineering when a problem is genuinely an operator defect, and one team covering both your support and your subscription.
Named DBAs, Zero Cold Start
The same senior DBAs stay on your account. They know your instance topology, your storage class, and your write profile — so a P1 starts with diagnosis instead of you explaining your cluster while commits are hanging.
No Tier-1 Triage Layer
You reach a senior PostgreSQL DBA directly by phone, email, or Slack. No help desk collecting information to pass along, no escalation approval between you and someone who can read pg_stat_activity against your storage metrics.
Database and Platform, Not One or the Other
Postgres on Kubernetes fails in ways bare-metal Postgres does not: PVC throughput limits, probes that misjudge health, pods rescheduled mid-checkpoint. We diagnose the database and the platform together, because splitting them across two vendors is how incidents stretch into days.
Genuine Follow-the-Sun Coverage
Engineers across 26+ countries and every time zone. Your 3am replication stall is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to wake up.
Proactive, Not Just Reactive
Quarterly health checks covering freeze age, bloat, slot retention, and backup verification — plus shared intelligence across our support base when a version-specific bug surfaces on someone else's cluster first.
We support Tanzu Postgres wherever it's deployed
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
- Kubernetes & OpenShift
- VMware vSphere & Tanzu
- Tanzu Platform / Cloud Foundry
- AWS (EC2, EKS)
- Microsoft Azure (AKS)
- Google Cloud (GKE)
- Bare metal & on-premise
- Hybrid cloud
- Air-gapped / no outbound access
- PostgreSQL 13 through 17
- Patroni-managed HA clusters
- pgbouncer / connection pooling tiers
Escalation Path
Your first hour of a Tanzu Postgres outage
Every tier reaches a senior Tanzu Postgres 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 Tanzu Postgres support cost?
AceMQ Tanzu Postgres 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
Tanzu Postgres problems we've already solved
Tanzu Postgres support work from AceMQ. Each card links to the full write-up: the cluster, what AceMQ diagnosed or changed, and the result.
Tanzu Postgres Failover That Never Triggered
Regional Payments Processor
Finding why a Tanzu Postgres primary stayed in service while refusing queries, and fixing the health probe so the operator promotes a replica.
Tanzu PostgresPostgreSQL
Kubernetes
PrometheusTanzu Postgres Checkpoint Stalls on Throttled Volumes
Software-as-a-Service Analytics Vendor
Support engagement tracing afternoon write latency spikes on Tanzu Postgres to volume burst credits, not the database settings everyone had been tuning.
Tanzu PostgresPostgreSQLKubernetesPrometheusTanzu Postgres Backup and Restore Assessment
Public Sector Records Agency
Restoring a Tanzu Postgres backup into a clean namespace for the first time, and finding that WAL archiving had been failing quietly for weeks.
Tanzu PostgresPostgreSQLKubernetes
LinuxTanzu Postgres Operator and Major Version Upgrade Planning
Regional Energy Distributor
Sequencing a Tanzu Postgres operator upgrade and a PostgreSQL major-version upgrade across four clusters, rehearsed on cloned data.
Tanzu PostgresPostgreSQLKubernetes
Terraform
Support options
Four tiers of Tanzu Postgres support.
AceMQ offers Tanzu Postgres 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 freeze age, archive failures and weak probes first, managed Postgres on your own Kubernetes, and fully managed Postgres on AceMQ infrastructure. Licensing is quoted in the US only, with a 72-core minimum.
- Tier 1
Tanzu Postgres 24/7 Support & Incident Management
You run it, we back you up
- 15-minute P1 response for hung commits, failed failovers and connection storms
- Named senior DBAs who know your instance topology and storage class
- Tanzu operator, other Kubernetes operators and Patroni on VMs covered
Best for: Platform teams that run Tanzu Postgres themselves and need senior DBA cover.
- Tier 2
Tanzu Postgres 24/7 Support with Proactive Monitoring
You run it, we watch it with you
- Scheduled reviews of freeze age, bloat and replication slots
- Restore tests into a clean namespace with measured recovery time
- CVE alerts for your PostgreSQL and operator versions
Best for: Teams that want the wraparound warning or the failed archive found in a review, not in an outage.
- Tier 3
Managed Tanzu Postgres on Your Infrastructure
We run it in your cloud or data centre
- AceMQ holds the pager for primaries, replicas and poolers
- Rolling operator upgrades with a tested failback
- Restore times measured, not estimated
Best for: Regulated estates that must keep PostgreSQL inside their own Kubernetes boundary.
- Tier 4
Fully Managed Tanzu Postgres on AceMQ Infrastructure
We host it and run it, as a service
- Hosted and operated by AceMQ, sized to your workload
- Replication across zones with failover tested under load
- Backups, upgrades and monitoring included
Best for: Teams that want Postgres on Kubernetes without owning the operator, the pager or the restore drill.
| 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 Tanzu Postgres 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 Tanzu Postgres
Everything else AceMQ does for Tanzu Postgres.
Support is one part of what AceMQ does for Tanzu Postgres. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
- ConsultingTanzu Postgres consulting and services
- LicensingTanzu Postgres licensing
- LifecycleEnd-of-life software support
- Enterprise supportOpen source support across your whole stack
- GuideTanzu Postgres 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 does AceMQ Tanzu Postgres support include?
Our support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, query and vacuum tuning, operator and Kubernetes operations, backup and point-in-time recovery assurance, major 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.
We're getting transaction ID wraparound warnings. How urgent is that?
Urgent, but almost always fixable well before the database stops accepting writes. Wraparound warnings mean autovacuum has not been able to freeze old rows, and the reason is nearly always something holding xmin back — a stale replication slot from a decommissioned replica, an orphaned prepared transaction, or a session left idle in transaction. Clearing that holder lets freezing proceed, and only then does autovacuum tuning matter. We handle these as P1 and typically have the blocker identified inside the first hour.
How fast do you respond to a Postgres production outage?
P1 emergencies — database unreachable, commits hanging, failover not completing — 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.
Do you support PostgreSQL outside the Tanzu operator?
Yes. We support Tanzu for PostgreSQL, other Kubernetes operators, Patroni clusters on VMs, and traditional bare-metal deployments, including estates that run several of these at once. The Tanzu operator changes how failover and upgrades are orchestrated, but xmin, autovacuum, WAL, and the planner behave the same everywhere — and that is where most incidents originate.
Our failover didn't trigger even though the primary was clearly broken. Why?
Usually because the health check was answering a narrower question than you assumed. A primary that has exhausted max_connections, filled its data volume, or wedged on a synchronous standby will still complete a TCP handshake and can still pass a shallow readiness probe, so the operator sees a healthy leader and never promotes. We review the probe definition against the failure modes you actually need it to catch, then verify the change by inducing those failures in a non-production cluster rather than assuming.
Can you help with our Broadcom Tanzu for PostgreSQL licensing and true-up?
Yes, and it is a frequent reason Tanzu customers reach out. As Broadcom's VMware Expert Advantage Partner of the Year for the Americas, we reconcile deployed instances and core counts against purchased entitlements, surface true-up exposure ahead of an audit, and negotiate renewal and multi-year terms. Licensing quotes come back within 24 hours, from the same team that sizes your clusters.
Can we work with AceMQ on Tanzu Postgres without a long contract?
Yes. AceMQ works on Tanzu Postgres 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 Tanzu Postgres support or consulting cost?
Every AceMQ proposal is tailored to your requirements: your Tanzu Postgres 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 Tanzu Postgres is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Find Out Your Backups Work Before You Need Them
Reactive cover, proactive reviews, or AceMQ running Tanzu Postgres for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
A senior Tanzu Postgres engineer, not a sales queueQuote requests answered within 1 hourAd hoc engagements or an annual partnership
Production incident right now?Email a Tanzu Postgres Architect
Get in Touch
Talk to a Tanzu Postgres 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.