// Managed PostgreSQL
Managed PostgreSQL, on servers you control.
A managed Postgres database without moving into RDS, Azure or Cloud SQL.
OSSeva Operate is a managed PostgreSQL service for self-managed Postgres: our engineers run your clusters 24/7 on your own servers, cloud account or Kubernetes, under Patroni or repmgr, and OSSeva does not host them. You keep superuser access, the extensions you choose and the community binaries. Amazon RDS and Aurora, Azure Database for PostgreSQL and Cloud SQL run Postgres inside the provider's service and suit teams that want no servers at all. OSSeva covers PostgreSQL 11 to 18, with patched builds for 11, 12 and 13 now and for 14 after 12 November 2026, priced per cluster.
Trusted globally by enterprises
Why teams want Postgres managed on their own infrastructure
A cloud provider's managed Postgres is the right call for many teams. These are the reasons others keep their clusters and hand over the operations instead.
Managed services keep the superuser for themselves
On Amazon RDS the admin role is created NOSUPERUSER and there is no host OS access. On Azure Database for PostgreSQL only Microsoft is in the superuser role. On Cloud SQL customers cannot create or use users with the superuser attribute. Anything that needs superuser or the host has to be redesigned first.
Version support follows the provider's calendar
PostgreSQL 14 reaches community end of life on 12 November 2026. RDS standard support for 14 ends on 28 February 2027, and running it longer means paid RDS Extended Support from 1 March 2027. Self-managed servers can stay on 14 with patched builds while the upgrade runs at its own pace.
The data has to stay where it is
Residency rules, latency to applications in your own data centre and existing network approvals often decide where a database lives. Moving it into a provider's service changes all three at once.
Patroni and repmgr clusters need someone on call
Failover, replication lag, consensus store quorum, VACUUM and backups all need watching around the clock. Many teams run Postgres well in office hours and have no rota for the rest.
The dates that matter
2025-11-13
PostgreSQL 13.23 ships as the final community release for 13. OSSeva keeps 11, 12 and 13 patched.
2026-11-12
PostgreSQL 14 reaches community end of life with its final scheduled minor release.
2027-02-28
Amazon RDS end of standard support for PostgreSQL 14. Paid RDS Extended Support runs from 1 March 2027 to 28 February 2030.
2027-11-11
PostgreSQL 15 reaches community end of life.
What OSSeva delivers
24/7 Postgres operations
Replication and failover monitoring around the clock, Patroni, repmgr and consensus store quorum checks, VACUUM and analyze tuning, point-in-time recovery tests and quarterly capacity reviews. P1 incidents get a 15-minute response from engineers who know your clusters.
Patched builds, end-of-life versions included
Signed DEB and RPM packages, tarballs and container images that install like a minor release on the same data directory, for 11, 12 and 13 now and 14 after 12 November 2026. OSSeva Operate patches Critical CVEs (CVSS ≥ 9.0) within 48 hours and High within 7 days.
Upgrades and moves off a managed service
Major version upgrades run with your team, rolling minor updates replica by replica, and a planned route for estates moving from a cloud provider's managed Postgres back to self-managed servers, with OSSeva support from the day of cutover.
Your options, compared
| Option | What you get | Trade-off |
|---|---|---|
| Amazon RDS or Aurora PostgreSQL | AWS handles provisioning, patching, backup, recovery and failure detection. Aurora adds its own distributed storage. | No host access or PostgreSQL superuser. Versions follow the RDS calendar, with paid Extended Support after standard support ends. |
| Azure Database for PostgreSQL | A fully managed flexible server with automated patching, backups kept 7 to 35 days, zone-redundant high availability and built-in PgBouncer. | The superuser role belongs to Microsoft, and your admin role works through azure_pg_admin. |
| Cloud SQL for PostgreSQL | Google Cloud's managed PostgreSQL, with the cloudsqlsuperuser role for administration. | Customers cannot create or use users with the superuser attribute. |
| OSSeva Operate | 24/7 operations for self-managed Postgres on your servers, cloud account or Kubernetes, with full access and patched builds for 11 to 14. | You keep owning and paying for the infrastructure. Priced per cluster. |
Dates from the Amazon RDS for PostgreSQL release calendar and the PostgreSQL community schedule. Access and feature details from the AWS, Microsoft Learn and Google Cloud documentation. Checked 9 October 2026.
Frequently asked questions
Do you host PostgreSQL for us?
No. OSSeva does not host PostgreSQL. We operate the clusters you run on your own servers, VMs, cloud account or Kubernetes, through the access you grant, and the account and its data stay yours. If you want no servers at all and your workload fits a provider's options, a managed service such as RDS, Azure Database for PostgreSQL or Cloud SQL is the simpler choice.
How is this different from Amazon RDS or Aurora?
RDS and Aurora run Postgres inside AWS's service: AWS handles provisioning, patching, backup and failover, and you get no host access or PostgreSQL superuser. OSSeva Operate runs self-managed community Postgres wherever you put it, including EC2 in your own AWS account, with full access, and keeps end-of-life versions patched instead of moving them to paid RDS Extended Support.
What about Azure Database for PostgreSQL?
It is a fully managed flexible server with automated patching, backups and zone-redundant high availability, and it suits teams that are happy inside Azure's options. The superuser role stays with Microsoft. OSSeva can operate self-managed Postgres on VMs or Kubernetes in your own Azure subscription when you need full control.
Which PostgreSQL versions can OSSeva Operate run?
PostgreSQL 11 to 18. OSSeva ships patched builds for 11, 12 and 13 now and for 14 after 12 November 2026, and 15 is covered on Assure and Operate today. Versions 16, 17 and 18 still get community minor releases, and Operate runs them the same way.
How fast are PostgreSQL CVEs patched under managed operations?
OSSeva Operate patches Critical CVEs (CVSS ≥ 9.0) within 48 hours and High within 7 days. Fixes arrive as signed builds that install like a minor release, rolled through each cluster replicas first, then a switchover, then the former primary.
Can you move us off a managed Postgres service to self-managed servers?
Yes. We plan the route from RDS, Aurora, Azure or Cloud SQL to self-managed PostgreSQL on your servers, VMs or Kubernetes, and OSSeva support starts on the day of cutover. How long it takes depends on your estate, so it is sized after the discovery call.
Can you take over Postgres clusters we already run?
Yes. Support takeover with no migration is the normal starting point: you keep the binaries, data and Patroni or repmgr topology you run today. We inventory the clusters and write runbooks before taking the pager, then move you to patched OSSeva builds on your schedule.
How is managed PostgreSQL from OSSeva priced?
OSSeva Operate is priced per cluster, and PostgreSQL sits on one contract with the rest of your stack and one renewal date. The database support cost calculator compares your current spend using your own figures. Book a discovery call for a quote.
Keep your Postgres. Hand us the pager.
Discovery call, cluster inventory, then a quote priced per cluster.