24/7 PostgreSQL Support and Upgrades with a 15-Minute Emergency SLA

The PostgreSQL project supports a major version for five years after its first release. PostgreSQL 14 came out on 30 September 2021, so its final minor release is due on 12 November 2026, after which the community ships no more bug or security fixes for it. The usual plan is an upgrade project with a support contract around it: an HA review first (1 to 4 weeks, depending on complexity), a rehearsed upgrade to a supported release, and 24/7 cover on the new version. If the upgrade cannot finish before the date, OSSeva supplies patched PostgreSQL 14 builds and AceMQ supports the cluster in the meantime.

Not by the community: PostgreSQL 13 had its final release on 13 November 2025, so it no longer receives bug or security fixes. AceMQ still supports it 24/7, and OSSeva supplies patched builds of PostgreSQL 13 (and 11, 12 and 14) as RPM, DEB or tarball packages, so a compliance team has a patched version to point to while the upgrade is planned.

It takes 1 to 4 weeks, depending on how many clusters and how complex the topology is. An AceMQ engineer reviews your Patroni, repmgr or managed-service failover setup, replication lag and synchronous settings, backup and point-in-time recovery drills, connection pooling and monitoring, then tests a failover on a non-production copy. You get written findings ranked by risk, and they become the plan for the upgrade. Teams often start here because it is a bounded piece of work that turns into a support contract.

Yes. Postgres consulting from AceMQ is project work with a written outcome, run by the engineers who also answer the pager: the HA review, a major version upgrade, query and vacuum tuning, or a move between self-managed PostgreSQL and Amazon RDS, Aurora, Azure Database or Cloud SQL. Many teams start with one project and keep the support contract afterwards.

It depends on what you need covered. Cloud providers such as Amazon RDS, Aurora, Azure and Google Cloud run the database as a service and support the service itself. Distribution vendors sell their own builds with support. Independent firms such as AceMQ support the community PostgreSQL you already run, or the managed service you already pay for. Compare providers on four things: which versions they cover, whether the emergency response is an engineer on a call or an acknowledgement, whether they will run the upgrade with you, and whether the contract forces a move to a proprietary fork. Our comparison of managed PostgreSQL options sets the cloud services side by side.

PostgreSQL support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, query and plan tuning, vacuum and bloat remediation, HA and replication review, CVE and patch advisory, quarterly health checks, and major version upgrade support. Every ticket goes to a named senior engineer assigned to your account. There is no first-line triage layer and no per-incident charge.

Yes, alongside self-managed and Kubernetes deployments. Managed services remove patching and backup mechanics but not the problems that cause most incidents — bloat, plan regressions, connection exhaustion, lock contention, and replication lag are all still yours. Aurora also introduces its own behaviour: a different storage layer, different checkpoint and failover characteristics, and reader endpoints that need application awareness. We support RDS, Aurora, Cloud SQL, AlloyDB, and Azure Flexible Server with the same engineers who handle self-managed clusters.

P1 emergencies — database unavailable, disk full, replication broken, writes failing — 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 response times that apply nights, weekends, and holidays.

That signature is nearly always bloat caused by vacuum being unable to reclaim dead tuples. A session sitting in idle-in-transaction — often an application connection that opened a transaction and then waited on an external call — holds the xmin horizon open, so vacuum cannot remove any row version newer than it. Tables and indexes grow with dead tuples, scans read more pages each week, and the restart works only because it terminates the offending session. We find the holder, fix the application pattern, and then remove the accumulated bloat online with pg_repack.

Raising max_connections is usually the wrong lever. PostgreSQL uses a process per connection, so each one carries real memory and scheduler cost, and a few thousand mostly-idle backends will degrade the server long before they hit any configured ceiling. A transaction-mode pooler in front lets a few hundred application connections share a much smaller number of backends. The caveat is that transaction pooling breaks session-scoped features such as prepared statements, advisory locks, and SET commands, so we review your application's usage before recommending a mode.

Yes. For most clusters pg_upgrade with hard links gets the downtime into the minutes range, and we rehearse it against a restored copy of production first so the timing is measured rather than estimated. Where minutes are still too many, we use logical replication to build the new version alongside the old, catch it up, and cut over with a brief pause on writes. Either way we check extension compatibility and the plan behaviour of your top queries on the new version before the cutover, because plan regressions across major versions are the most common post-upgrade surprise.

PostgreSQL is an open source relational database developed by the PostgreSQL Global Development Group. The PostgreSQL community supports each major version with fixes for five years, and answers questions through the mailing lists and the PostgreSQL wiki, but nobody is obliged to respond to an outage. PostgreSQL support from a company such as AceMQ is the contract the project itself does not offer: 24x7x365 incident response with a named senior engineer, expert support on high availability, indexing, partitioning and database performance, and PostgreSQL services for migration and version upgrades. The project keeps a list of companies providing professional services to the PostgreSQL community; what separates them is which versions they cover, whether the emergency response is an engineer or an acknowledgement, and whether they will run the change with you rather than advise from a distance.

Yes. PostgreSQL 13 had its final release in November 2025 and PostgreSQL 14 follows in November 2026, so both are common in the estates we take on. For PostgreSQL 11 to 14, AceMQ's OSSeva platform backports CVE fixes past community end of life, packaged as RPM, DEB or tarball builds. We support those versions with incident response and mitigation while the upgrade is planned, then run the migration: pg_upgrade for a fast in-place move where a window exists, or logical replication to a new cluster for a near-zero-downtime cutover. Moves between self-managed PostgreSQL and Amazon RDS, Aurora, Azure Database or Cloud SQL are covered by the same team, including the extensions such as PostGIS and pg_partman that have their own version matrix, and the application driver changes that usually cause the surprises.

No. AceMQ provides PostgreSQL enterprise support for the community PostgreSQL you already run, whether it comes from the PGDG apt and yum repositories, your Linux distribution's packages, container images or a managed cloud service. There is no migration to a proprietary fork and no licence change: PostgreSQL stays under the PostgreSQL License, and the contract pays for the engineers who answer at 3 a.m., not for the software.

Yes. A base backup plus continuous WAL archiving is what makes point-in-time recovery possible, and most failures sit in the parts nobody tests: an archive_command that fails and lets WAL pile up in pg_wal, retention that expires the WAL a restore needs, or a backup that has never been restored. We configure and review pgBackRest or Barman, set retention against your recovery point objective, and run timed restore drills so recovery time is measured.

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.