Database Support
Last reviewed by Scott Sternloff
Database support services for the open source databases enterprises run in production: PostgreSQL, MySQL, MongoDB, Redis and Valkey, Apache Cassandra, ClickHouse, Elasticsearch and OpenSearch, Apache Druid, Greenplum, GemFire and Memcached. Self-managed, on Kubernetes, or on managed cloud services such as Amazon RDS, Aurora and MongoDB Atlas. One support contract and one SLA, a 15-minute response for P1 incidents, and every ticket reaches a named senior engineer who specializes in that database.
Support quotes answered within 1 hour, by a senior engineer.
Customers
Partners
Incident Triage
These are real symptoms from real Database production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| PostgreSQL: WAL directory filling the disk with no increase in write traffic | pg_replication_slots for an inactive slot. A slot left behind by a decommissioned replica or a paused CDC consumer retains WAL indefinitely, and PostgreSQL will fill the volume defending a subscriber that is never coming back. We also check for a silently failing archive_command. | Under 1 hour |
| MySQL: replica lag climbing into hours during the nightly batch | Whether apply is actually parallel: replica_parallel_workers and replica_parallel_type, plus binlog_transaction_dependency_tracking. A single large multi-row transaction serializes the whole apply pipeline regardless of worker count, so we look at transaction size before we look at hardware. | 1–2 hours |
| MongoDB: replica set keeps electing a new primary several times a day | Heartbeat latency between members, election metrics, and secondary apply lag. Network flap between availability zones and a secondary too slow to keep up are the two usual causes; priority and votes misconfiguration turns both into a loop. | 1–3 hours |
| Redis or Valkey: commands intermittently timing out under normal load | SLOWLOG for O(N) commands on the single-threaded command loop. One KEYS, one unbounded SMEMBERS on a large set, or a Lua script iterating a big collection blocks every other client for its full duration. | Under 1 hour |
| Cassandra: read timeouts on a table with heavy deletes or short TTLs | Tombstone counts per read in the system log against tombstone_warn_threshold, and how long since compaction last purged them. Every delete and every expired TTL cell is a tombstone that must be scanned on each read until it ages past gc_grace_seconds and compacts away. | 1–3 hours |
| ClickHouse: inserts failing with DB::Exception: Too many parts | Insert batch size and frequency first. Every insert statement creates at least one part per partition, and background merges cannot keep up with thousands of tiny inserts per second. We also check partition key cardinality: partitioning by day is fine, partitioning by timestamp is not. | Under 1 hour |
| Elasticsearch or OpenSearch: cluster stuck yellow or red after a node restart | The allocation explain API for one unassigned shard. The answer is almost always a disk watermark (a node past flood_stage puts indices into read_only_allow_delete) or an allocation attribute rule that no remaining node satisfies. | Under 1 hour |
| Memcached: database CPU spikes to 100% seconds after a cache node drops | Whether the client uses consistent hashing (ketama) or modulo hashing. Modulo remaps nearly every key on a ring change and sends the entire keyspace to the database at once. We check client configuration first, then add request coalescing on the hot keys. | 1–2 hours |
Resolution times reflect typical Database 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.
Database down, disk full, replication broken, a cluster gone red, or a primary that will not accept writes. A senior engineer joins a live bridge within 15 minutes, 24/7, with access to diagnose rather than a ticket acknowledgement.
Every P1 closes with a written RCA: what failed, why, the fix applied, and the configuration, index, query or client change that stops it recurring. Delivered as standard, not on request.
Slow queries, plan regressions, lock contention, memory and eviction pressure, and connection exhaustion, diagnosed against your real workload. Query optimization, index design, statistics, pooling and client settings, per database rather than one generic checklist of database performance tips.
Replica sets, streaming and logical replication, Sentinel and cluster topologies, multi-datacenter Cassandra, and shard allocation. High availability setups such as Patroni and InnoDB Cluster reviewed, and failover tested with clients connected, so the first real failover is not the first test.
Major version upgrades planned from the release notes and rehearsed with a rollback, plus migrations between self-managed PostgreSQL and Amazon RDS, Aurora, Azure Database or Cloud SQL, onto PostgreSQL from Oracle, SQL Server or MySQL, and from Redis to Valkey.
Alerts for CVEs that affect the exact version and extensions you run, with tested patch paths. Databases past community end of life stay supported, and for PostgreSQL 11 to 13, Redis and Valkey, AceMQ's OSSeva platform backports security fixes while the upgrade is planned.
Why AceMQ
Most estates run three or four databases: a relational store, a cache, a search cluster, an analytics engine. One contract covers all of them with the same 15-minute P1 SLA, so an incident never stalls on which vendor or which contract it belongs to.
The engineer who answers a PostgreSQL wraparound warning is not the one who answers a Cassandra tombstone problem. What is shared is the SLA and the contract, not the expertise, and the same named engineers stay on your account.
You reach a senior database engineer directly by phone, email or Slack. Nobody collects details to pass along while the primary is down.
RDS, Aurora, Atlas, ElastiCache and OpenSearch Service remove patching mechanics, not the problems that cause most incidents. Bloat, plan regressions, hot partitions and connection exhaustion are still yours, and we support all three deployment models.
We diagnose across the connection pooler, the ORM's query generation, storage latency, kernel settings and Kubernetes, because a surprising number of database incidents start one layer above or below the database.
Engineers across 26+ countries and every time zone, so a 3am replication break reaches someone who is already at work.
Databases covered
Every database below is covered by the same 24/7 contract and the same 15-minute P1 SLA. Each has its own support page with the failure modes we see most and the versions covered.
| Database | Deployments covered | Typical incidents |
|---|---|---|
| PostgreSQL | Self-managed PostgreSQL 12 to 17, Amazon RDS and Aurora PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL and AlloyDB, Kubernetes operators | Autovacuum lag and bloat, WAL growth, wraparound warnings, connection exhaustion |
| Tanzu for Postgres | PostgreSQL 13 to 17 under the Tanzu operator on Kubernetes and OpenShift, Patroni-managed HA clusters | Freeze vacuum falling behind, connection storms on pod rolls, checkpoint stalls |
| MySQL | MySQL 5.7 (end of life) through 8.4, Amazon RDS and Aurora MySQL, Azure, Cloud SQL, Percona Server, MariaDB, InnoDB Cluster | Replica lag, gap-lock deadlocks, long ALTER statements, binlog growth |
| MongoDB | MongoDB Atlas, Enterprise Advanced, Community 5.x to 8.x, Amazon DocumentDB, Percona Server for MongoDB | Election storms, WiredTiger cache pressure, short oplog windows, shard key hot spots |
| Redis | Self-managed, Amazon ElastiCache and MemoryDB, Azure Cache and Azure Managed Redis, Memorystore, Redis Enterprise, Sentinel and Cluster | Latency spikes, fork stalls, eviction storms, failovers that strand clients |
| Valkey | Valkey 7.2 to 9.1, self-managed, Kubernetes, ElastiCache and Memorystore for Valkey, Tanzu for Valkey | I/O thread tuning, stuck slot migrations, OOM write rejections |
| Apache Cassandra | Cassandra 3.11, 4.x and 5.0, DataStax Enterprise, Amazon Keyspaces, K8ssandra, multi-datacenter | Tombstones, oversized partitions, repairs past gc_grace_seconds |
| ClickHouse | ClickHouse Cloud, self-managed 23.x to 25.x, Keeper and ZooKeeper, Altinity builds and operator | Too many parts, memory limits, replication queues stalled behind Keeper |
| Elasticsearch | Elastic Cloud, ECK on Kubernetes, self-managed on AWS, Azure, Google Cloud and on premises | Red clusters, circuit breakers, oversharding, ILM rollover failures |
| OpenSearch | Amazon OpenSearch Service and Serverless, self-managed OpenSearch 1.x to 3.x | Unassigned shards, ISM failures, Elasticsearch client incompatibility |
| Apache Druid | Druid 26 to 31 self-managed, Imply, Druid Operator on Kubernetes | Kafka ingestion lag, segment handoff, broker timeouts |
| Greenplum | Greenplum 5.x, 6.x and 7.x on vSphere, bare metal and cloud | Segment failures, distribution skew, spill files filling disks |
| GemFire and Apache Geode | GemFire 9.x and 10.x, Apache Geode, Kubernetes and Tanzu Platform | GC pauses, members leaving the cluster, WAN sender backlog |
| Memcached | Memcached 1.5.x and 1.6.x, Amazon ElastiCache and Memorystore for Memcached | Slab calcification, eviction storms, connection limits, miss stampedes |
Coverage as listed on each database's AceMQ support page. Links to every page are below.
Escalation Path
Every tier reaches a senior Database 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 Database 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 options
AceMQ offers database support in four stages, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for databases your team runs, proactive monitoring that catches replication, bloat and capacity problems first, managed databases on your own infrastructure, and fully managed databases on AceMQ infrastructure. PostgreSQL, MySQL, MongoDB, Redis and Valkey, Cassandra, ClickHouse, Elasticsearch and OpenSearch, Druid, Greenplum, GemFire and Memcached are covered.
You run it, we back you up
Best for: Teams that run their own databases and need senior escalation cover.
You run it, we watch it with you
Best for: Teams that want fewer database incidents, not just faster ones.
We run it in your cloud or data centre
Best for: Regulated or compliance-heavy estates that cannot move their databases off their own infrastructure.
We host it and run it, as a service
Best for: Teams that want databases without owning any of their operations.
| Who does what | Stage 1 24/7 support | Stage 2 Proactive monitoring | Stage 3 Managed, your infrastructure | Stage 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Database 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 Stage can start as an ad hoc engagement or an annual partnership, and you can move up or down a Stage as your team changes.
One partner for Database
Support is one part of what AceMQ does for Database. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
Database support services give your team expert help when a production database fails or misbehaves: 24/7 incident response, troubleshooting, performance and query tuning, replication and high availability reviews, upgrades and CVE advice. Your team keeps operating the databases; the support provider is who you escalate to. AceMQ provides this for open source databases under one contract with a 15-minute response for P1 incidents.
Community support for an open source database means mailing lists, forums and issue trackers. The answers are often excellent, but nobody is obliged to respond, nobody joins your outage bridge, and nobody owns the root cause. Commercial support adds response times written into a contract, engineers who already know your deployment, and someone accountable for critical incidents at 3am. That matters most for the relational database or cache your revenue depends on.
PostgreSQL (including Tanzu for Postgres), MySQL, MongoDB, Redis, Valkey, Apache Cassandra, ClickHouse, Elasticsearch, OpenSearch, Apache Druid, Greenplum, GemFire and Apache Geode, and Memcached. Each has its own support page with the versions and deployments covered.
Emergency incident response with a 15-minute SLA for P1 incidents, a written root cause analysis for every P1, query and performance tuning, replication and failover reviews, upgrade and migration support, and CVE and patch advisory for the versions you run. Every ticket goes to a named senior engineer. There is no tier-1 triage layer and no per-incident charge.
P1 incidents, meaning production down, get a senior engineer within 15 minutes, 24/7/365, under contract. Lower severities have their own response times, shown in the SLA tiers on this page. The engineer who picks up can read the logs and act; there is no intake layer in between.
Yes. The cloud provider runs the infrastructure, but schema design, queries, indexes, connection handling, replication lag and most incident causes remain yours. We work alongside the provider's own support on those, and on migrations into or out of the managed service.
Yes. One contract and one SLA cover every database in scope, open source or commercial distribution. Each database is handled by engineers who specialize in it, so the contract is shared but the expertise is not spread thin.
Yes. Regulated estates often cannot upgrade on the community's schedule, so we support the version you actually run and plan the upgrade in parallel. For PostgreSQL 11 to 13, Redis and Valkey, AceMQ's OSSeva platform backports security fixes past community end of life. The end-of-life support page covers every technology and the options for each.
Tell us which databases you run, where they run and the SLA you need. Quote requests are answered within 1 hour and scoped against your actual deployment.
Yes. AceMQ works on Database 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 Database 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 Database is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Whether you need emergency cover tonight, a major version upgrade planned, or one contract across PostgreSQL, MongoDB, Redis and Elasticsearch, AceMQ staffs it with named senior engineers. Quote requests answered within 1 hour.
Production incident right now?Email a Database 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.
