Managed PostgreSQL
Last reviewed by Scott Sternloff
AceMQ fully manages your PostgreSQL database in your own cloud account, Kubernetes cluster or data centre (Tier 3), or on a dedicated PostgreSQL host we run (Tier 4). We manage monitoring, high availability with Patroni failover, backups with point-in-time recovery, upgrades and the pager. The engine stays community Postgres, so the data and the exit are yours.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ PostgreSQL consulting and services.
Customers
Partners
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
We manage monitoring of what predicts PostgreSQL incidents: replication lag and inactive replication slots, WAL volume growth, autovacuum progress and transaction ID age, long idle-in-transaction sessions, connection counts against max_connections, and disk headroom. Then we take the pager, so an alert reaches an engineer who already knows your topology.
We manage high availability with Patroni-based clusters, or the repmgr or cloud failover you already have, and rehearse a failover on a schedule instead of finding out during an outage. Patroni keeps its leader state in a distributed store such as etcd, Consul, ZooKeeper or Kubernetes, so that store is monitored as part of the cluster.
A base backup plus continuous WAL archiving is what makes point-in-time recovery possible. We deploy and manage pgBackRest or Barman, set retention against your recovery point objective, and restore into a scratch environment on a schedule, because a backup that has never been restored is a guess.
We manage patching: minor releases applied on a defined cadence, with CVE assessment against the version you run. PostgreSQL ships minor releases at least every three months. Databases on a major the community has stopped patching stay covered while the upgrade is planned.
We manage database performance: slow query review with EXPLAIN and pg_stat_statements, index and partition design as tables grow, autovacuum settings per busy table, connection pooling with PgBouncer in the mode your application needs, and capacity planning written down instead of kept in someone's head.
We deploy and manage a PostgreSQL database on virtual machines or bare metal in your AWS, Azure or Google Cloud account, on Kubernetes with the operator you already use, and on-premises or air-gapped estates. The playbook is the same; the access and change process are yours.
Why AceMQ
Run a fully managed PostgreSQL database in your own account or data centre (Tier 3) when residency and compliance rules keep the data in your boundary. Or have AceMQ host a dedicated PostgreSQL cluster (Tier 4), a managed Postgres database service when you want endpoints and no cloud account, patching or on-call rota to run. The operator is a PostgreSQL specialist in both cases, not a generic hosting contract.
Incidents start with a named senior PostgreSQL engineer who already knows your replication layout and your largest tables, not with a ticket queue. The 15-minute P1 response is a response time, not a resolution time.
Many PostgreSQL incidents come from what the application does to the database: idle transactions that block vacuum, a pool per instance that exhausts connections, a query plan that flips. We manage the database server and also work on queries, workload patterns and pooling.
There is no fork and no licence change: PostgreSQL stays under the PostgreSQL License. Runbooks, topology documentation and monitoring configuration are maintained as yours. If you bring operations back in-house, or move a database between your infrastructure and ours, there is a current handover pack ready.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
The 4 tiers
Each tier moves one more responsibility from your team to AceMQ: first diagnosis, then early warning, then running the database, then owning the platform it runs on. Tiers 1 and 2 are AceMQ's PostgreSQL support. Tiers 3 and 4 are managed PostgreSQL services, and they are what the rest of this page describes.
| Tier | Who holds the pager | What AceMQ does |
|---|---|---|
| Tier 1: Reactive support | You | A senior PostgreSQL engineer responds to your tickets under the contracted SLA, with escalation and a written root-cause analysis after every P1. Access to your environment is on request, while a ticket is worked. |
| Tier 2: Proactive support | You, with AceMQ raising problems early | Tier 1, plus monitoring and scheduled reviews of autovacuum, bloat, replication lag, backup restores and CVEs, so the problem is found in a review and not in an outage. |
| Tier 3: Managed on your infrastructure | AceMQ | AceMQ operates PostgreSQL in your cloud account, Kubernetes cluster or data centre: monitoring, Patroni failover, backups, upgrades, change execution and on-call. You keep the account, the data and the cloud bill. |
| Tier 4: Managed on AceMQ infrastructure | AceMQ | AceMQ provides PostgreSQL hosting: it hosts and operates a dedicated PostgreSQL cluster on its own infrastructure, with streaming replication, point-in-time recovery and upgrades. You get connection endpoints, not a server, a cloud account or an on-call rota to run. |
Tier 3 and Tier 4 get the same operations. What differs is where the database runs and who owns the infrastructure underneath it. Tell us the workload and we will recommend a tier. Tiers 1 and 2 are on the PostgreSQL support page.
The same four tiers cover Kafka, Redis and RabbitMQ; the escalation-first option is set out in managed open-source operations.
In your account or RDS
A cloud provider's managed PostgreSQL service runs the instance. AceMQ's Tier 3 runs the whole database, with high availability and backups, in an account you own. Both are legitimate; they differ on four things.
On RDS or Aurora the database is a line on the provider's invoice and a resource inside its service. At Tier 3 it runs on instances you own, so the data stays in your account and your cloud commitments apply. At Tier 4 AceMQ owns the infrastructure and you receive endpoints.
A managed database service allows the PostgreSQL extensions, such as PostGIS or pgvector, and the parameters on its supported list for your major version. Running PostgreSQL in your own account allows any extension and any setting, including a custom build, with AceMQ carrying the change risk.
A managed service does not remove the community end-of-life date. Amazon RDS Extended Support lets a major version keep running past the RDS end of standard support for an additional cost, available for up to three years, and a database past that date with Extended Support disabled is upgraded automatically (AWS documentation, checked 26 October 2026). At Tier 3 you choose the upgrade date.
A provider supports its platform. Query plans, bloat, locks and connection exhaustion stay with your team on every managed service. At Tier 3 and 4 a PostgreSQL engineer owns those too, and we also support databases that stay on RDS or Aurora at Tier 1 or 2.
Vendor behaviour changes, so the full side-by-side with dates is kept on one page. Managed PostgreSQL options compared
Upgrades and HA
PostgreSQL gets its last community release five years after the first, and the clock is short for older majors. We manage the database upgrade and deploy the new version with a tested fallback. Managed PostgreSQL includes planning and running the move.
PostgreSQL 13 had its final release on 13 November 2025. PostgreSQL 14 follows on 12 November 2026. PostgreSQL 15 ends on 11 November 2027, 16 on 9 November 2028, 17 on 8 November 2029 and 18 on 14 November 2030. Each major gets a final minor release and is then unsupported.
pg_upgrade moves the data files to a later major without a dump and restore, supports sources from 9.2 and later, and needs both servers stopped, with a --check run beforehand and an optional --link mode that is faster but leaves the old cluster unusable once the new one starts. Logical replication can replicate between major versions and is the route when the cutover window is short. We pick per database and rehearse on a copy first.
The target is the newest major your extensions, drivers and application have been tested against. PostgreSQL 17 is supported until November 2029 and 18 until November 2030. Extensions such as PostGIS or pg_partman have their own version matrix, so the extension check comes before the date.
Patroni is a template for high-availability PostgreSQL clusters. We design the high availability cluster, keep the distributed store healthy, run switchover tests, and keep the old primary available as a fallback until the new major has run production traffic. Where a major cannot move yet, PostgreSQL 11 to 14 can be kept patched through OSSeva.
Not ready to hand over operations yet? The 1 to 4 week HA review comes first on the support page. PostgreSQL support and HA review
Price drivers
AceMQ does not publish a price list. A managed PostgreSQL quote is built from these inputs, and the written quote returns within 1 hour of your request.
How many PostgreSQL clusters you run, how many nodes each has, and whether they are primary and replica pairs or Patroni clusters across zones.
Database size and WAL volume, and the recovery point and recovery time objectives you need, which set the backup and restore work.
The price follows the cover you need, from business hours to 24/7 on-call with the 15-minute P1 response. Tell us which databases are production.
At Tier 3 you pay your cloud provider for infrastructure and AceMQ for operations. At Tier 4 the infrastructure is part of the AceMQ quote. A major-version upgrade, if one is due, is scoped in the quote.
Not a fit for
We would rather say so up front.
AceMQ is a specialist service with named engineers, not a self-service console where you click to provision a database. If you want pay-as-you-go instances with no contract, a cloud provider's service fits better.
Moving an Oracle or SQL Server database onto PostgreSQL is a separate project and is run through OSSeva, AceMQ's extended-support platform, not through this service. Once the database is on PostgreSQL we can operate it.
A scratch database with no uptime target is covered by the community and a current version. The service pays for itself where PostgreSQL holds revenue or regulated data.
Running several engines? One contract can also cover Redis, Kafka, MySQL and more. Database support across engines
Escalation Path
Every tier reaches a senior PostgreSQL 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.
Support In Practice
PostgreSQL support work from AceMQ. Each card links to the full write-up: the database estate, what AceMQ diagnosed or changed, and the result.
Telecommunications Operator
Remediation of a Grafana deployment that became unusable during incidents, with dashboards timing out exactly when engineers needed them most.
Grafana
Prometheus
Kubernetes
PostgreSQL
Digital Media Platform
Ongoing support for a Memcached tier prone to thundering-herd database load after node changes and cache expiry cliffs.
Memcached
LinuxPostgreSQLKubernetesInsurance Services Provider
Emergency intervention on a database approaching transaction ID wraparound because autovacuum could not keep pace with the largest tables.
PostgreSQLLinuxPrometheuspgBackRestDigital Banking Platform
Ongoing support for a cluster where an abandoned logical replication slot repeatedly filled the WAL volume and threatened to halt the primary.
PostgreSQLDebezium
KafkaPrometheusRetail Technology Provider
Independent assessment of query performance, index health, table and index bloat, and connection management for a cluster with degrading response times.
PostgreSQLPgBouncerPrometheusLinux
National Insurance Carrier
Restoring scheduling on Airflow deployments where zombie tasks hold executor slots and pools until nothing new gets queued.
Apache AirflowKubernetesCeleryPostgreSQLSupport options
AceMQ offers PostgreSQL support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for databases your DBAs run, proactive monitoring that finds bloat, lag and backup gaps first, managed PostgreSQL on your own infrastructure, and fully managed PostgreSQL on AceMQ infrastructure. Current releases are supported 24/7, PostgreSQL 14 can be upgraded as a project with an HA review first, and PostgreSQL 11 to 14 can be kept patched through OSSeva.
You run it, we back you up
Best for: DBA teams that run PostgreSQL themselves and need senior escalation cover.
You run it, we watch it with you
Best for: Teams that want the wraparound warning or the failed restore found in a review, not in an outage.
We run it in your cloud or data centre
Best for: Regulated estates that must keep databases inside their own boundary.
We host it and run it, as a service
Best for: Teams that want PostgreSQL without a DBA rota or a cloud database bill they cannot tune.
| 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 PostgreSQL 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 PostgreSQL
Support is one part of what AceMQ does for PostgreSQL. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
Managed PostgreSQL, also called a managed Postgres database, means someone else operates your PostgreSQL databases: monitoring, failover, backups, patching, upgrades and on-call. Cloud providers such as Amazon RDS and Aurora, Google Cloud SQL and Azure Database for PostgreSQL run the instance in their service. AceMQ offers two models. We operate PostgreSQL on your own infrastructure, so the data and the account stay yours, or we host a dedicated cluster on ours. In both, a PostgreSQL specialist also owns queries, vacuum health and connection pooling.
RDS runs PostgreSQL instances inside AWS's service, with Multi-AZ, backups and minor-version patching handled for you. Your team still owns schema design, query plans, autovacuum, connection counts and the timing of major upgrades. AceMQ's managed PostgreSQL covers those as well, and runs the database in your account (Tier 3) or on a dedicated cluster we host (Tier 4). Choose RDS when the workload is standard and procurement favours one cloud. Choose this when you need extensions or settings RDS blocks, strict residency, a version a provider has retired, or a named engineer. The trade-offs are set out in Managed PostgreSQL options compared.
Support is an SLA over a database your team runs: you hold the pager and call us when something breaks. Managed services means we run it: monitoring, failover, backups, upgrades and on-call are ours. Teams with a capable DBA team usually want support (Tiers 1 and 2). Teams that want PostgreSQL to stop being their problem want managed services (Tiers 3 and 4).
Yes. Patroni is a template for high availability PostgreSQL clusters and keeps its state in a distributed configuration store such as etcd, Consul, ZooKeeper or Kubernetes. We build and operate Patroni clusters, monitor the store as part of the cluster, and test switchover on a schedule. If your estate runs repmgr or a cloud service's own failover, we operate that instead of forcing a change.
Yes. Tier 3 runs in your data centre, on virtual machines, bare metal or Kubernetes, including air-gapped estates, using your access controls and change process. Tier 4 is the alternative when you would rather not run infrastructure at all.
Yes. We start with an assessment of version and patch position, replication and failover, backups and restore history, autovacuum and transaction ID age, extensions and monitoring gaps. We remediate the active risks and then take the pager.
Yes, as a project inside the service. PostgreSQL 13 had its final community release on 13 November 2025 and PostgreSQL 14 gets its last on 12 November 2026. We test extensions and drivers against the target major, pick pg_upgrade or logical replication per database, rehearse on a copy of production and keep the old primary as a fallback until the new major has run production traffic. PostgreSQL 11 to 14 can be kept patched through OSSeva while the move is planned.
We operate PostgreSQL in your own AWS account, Azure subscription or Google Cloud project, on virtual machines or Kubernetes, and on premises. Databases that stay on Amazon RDS, Aurora, Cloud SQL or Azure Database for PostgreSQL can be covered at Tier 1 or Tier 2, where AceMQ supports the workload but the provider runs the instance.
Emergencies such as a primary down, failover not completing, broken replication or a volume full of WAL get a 15-minute response from a senior engineer, 24/7. It is a response time, not a resolution time. Because we already run the database, most of those incidents are caught by monitoring before your team notices.
Redis and Kafka, yes: both run on the same four tiers, as separate managed services. MongoDB, MySQL, Elasticsearch and other databases are covered by AceMQ support under the same contract, so a mixed estate can have one SLA and one escalation path.
Yes. AceMQ works on PostgreSQL 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 PostgreSQL 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 PostgreSQL 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 PostgreSQL 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 PostgreSQL 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.
