How to Switch PostgreSQL Support Vendors Without Migrating Your Databases

The short answer

If your clusters run community PostgreSQL, you can change support vendor without migrating anything. The new vendor supports the binaries and data you run today, learns your estate, and only later replaces packages with its own builds, during your normal maintenance windows, the way you would apply a minor release. A good takeover has five parts: an inventory, a version and extension map, agreed access, runbooks, and a first incident drill before the old contract ends. Start with the outgoing contract's notice period, because it sets the deadline for everything else.

We call this a support takeover with no migration: keep your binaries, change your support.

Why teams assume switching means migrating

Support vendors often arrive with their own distribution, packages, operator or platform, and the assumption sticks that a new vendor means re-platforming. For community PostgreSQL that is not true. The server you run is the PostgreSQL Global Development Group's code, and any competent vendor can support it as it stands. The exceptions are clusters built on a vendor's own server distribution or proprietary extensions, covered below.

Step 1: read the outgoing contract

Before you contact anyone new, find these in your current agreement:

The licensing row decides how simple the switch is. If everything you run is community PostgreSQL and open source extensions, nothing stops working when the contract ends. If some clusters run a vendor's own server or tools, list them separately; they need a plan of their own.

Step 2: build the inventory

Record every cluster, node and version, with where it runs and how it is managed:

-- On each cluster
SELECT version();
SHOW server_version_num;
SELECT datname FROM pg_database WHERE NOT datistemplate;

-- In each database
SELECT extname, extversion FROM pg_extension ORDER BY extname;

Add the HA layer (Patroni, repmgr or a Kubernetes operator) and the store it uses, the backup tool and where backups land, connection poolers, monitoring and the hosts' operating systems. The inventory is yours to keep; whoever supports you next will need it too.

Step 3: map versions and extensions

Put the end-of-life date next to every major version. PostgreSQL supports each major version for five years: 13 reached end of life on 13 November 2025, and 14's final release is due on 12 November 2026. For each version, record whether the new vendor will ship fixes after that date, and until when. For each extension, record who maintains it, whether the new vendor tests it against its builds, and who fixes security issues in the extension's own code. PostgreSQL vulnerabilities by version shows what each line is exposed to.

Step 4: agree access

Decide what the new vendor sees and does before day one:

• Read access to configuration files, logs and the monitoring stack.
• A named route into the hosts for incidents, through your bastion or privileged access tool, with session recording if you use it.
• Whether the vendor may apply changes itself or only advise, and who approves.
• How tickets are raised, by whom, and the response targets by severity.

Step 5: runbooks and a first incident drill

Write or check the runbooks for failover, backup and restore, minor updates and major upgrades against how your clusters actually run. Then run a drill before the outgoing contract ends: raise a realistic P1 to the new vendor, such as a replica that has stopped replaying WAL or a restore to a point in time, and time the response. A drill while you still have the old contract is far cheaper than discovering a gap during a real outage.

After the takeover: builds on your schedule

Once the new vendor knows the estate, it can replace community packages with its own builds where that adds something, usually fixes for end-of-life versions. For PostgreSQL this is a minor-release procedure: stop the server, replace the binaries, start it on the same data directory. Under Patroni the order is replicas first, then a switchover, then the former primary. No pg_upgrade, no dump and restore.

When switching is the wrong call

• Clusters on a vendor's own server distribution, such as Oracle-compatible PostgreSQL, where applications depend on features community PostgreSQL does not have. EDB alternatives covers that case.
• Estates that rely on a vendor's operator, tooling or managed service, and would have to replace it.
• A current vendor that fits well, where the reason for change is only price. A renewal negotiation may be the better project.

Where OSSeva fits

OSSeva for PostgreSQL takes over support for the community PostgreSQL you run today and keeps it on your infrastructure: bare metal, VMs, any Kubernetes or any cloud account. It ships signed patched builds for 11, 12 and 13 now and for 14 after 12 November 2026, as DEB and RPM packages, tarballs and container images that roll through Patroni or repmgr clusters like a minor update. Extensions such as PostGIS and pgvector are tested against each build; their own code stays with their maintainers, and we say which fixes we carry before you sign. OSSeva Assure adds migration planning to 17 or 18 and a compliance attestation package, and OSSeva Operate adds 24/7 replication and failover monitoring, a 15-minute P1 response and point-in-time recovery testing. PostgreSQL can sit under one contract with MySQL, Redis, RabbitMQ and Kafka, priced per cluster. Support takeover describes the offer; book a discovery call for a quote.

Frequently asked questions

Can we change PostgreSQL support vendor without a migration?

Yes, for community PostgreSQL. The new vendor supports the binaries and data you run, and any later move to its builds is a minor-release style package update on the same data directory.

What should we check in our current support contract before switching?

The renewal date, the notice period for non-renewal, whether it renews automatically, what software you may keep running after it ends, when repository and portal access close, and how to export ticket history.

How long does a PostgreSQL support takeover take?

Plan the inventory, version map, access and runbooks to finish before the outgoing contract's renewal date, with a drill in the last weeks. The notice period usually sets the real deadline.

Do we lose anything when the old contract ends?

Access to the old vendor's portal, knowledge base and package repository, and any software licensed only under that contract. Export what you need before the end date and check what you run against the licensing terms.

Who supports PostgreSQL?

The PostgreSQL Global Development Group maintains it and fixes each major version for five years. Commercial support for self-managed PostgreSQL comes from companies such as EDB, Percona, OpenLogic, Instaclustr and OSSeva, and the cloud providers support it inside their managed services. Multi-database support providers compares them.