How to Consolidate Open Source Database Support Contracts Without Migrating Anything

The short answer

Consolidating open source database support is a contract project, not a migration project. You keep the binaries and the data you run today and change who answers when something breaks. The work runs in five steps: an inventory of every cluster and version, a calendar of every support renewal, a map of where contracts overlap and where nothing covers you, a short list of requirements for the single vendor, and a transition that picks up each technology as its current contract ends.

The requirement most teams miss is coverage for end-of-life versions. If the new vendor supports only what upstream still maintains, consolidation turns into an upgrade programme before it can start. Ask for patched, signed builds of the lines you actually run.

Why contract sprawl happens

Nobody plans five database support contracts. They arrive one at a time: a PostgreSQL subscription when the first critical service went live, a cache vendor when Redis became part of checkout, a broker contract after a RabbitMQ outage, and self-support for everything else. Each made sense on the day it was signed. Together they produce several renewal dates a year, several pricing units (per core, per node, per GB of memory, per vCPU hour), and incidents where three vendors each confirm their own piece is healthy while your team runs the investigation.

The second cost is patch toil. When nobody ships fixes for an older line, your engineers track CVEs, rebuild packages and argue with scanners. That time rarely appears on an invoice, which is why the database support cost calculator asks for it alongside contract costs, using only your own figures.

Step 1: inventory what you run

List every cluster, not every product. For each one record:

• Engine and exact version, for example PostgreSQL 13.23, MySQL 8.0.46, Redis 7.0.15 or RabbitMQ 3.13.7.
• Where it runs: bare metal, VMs, which Kubernetes distribution, which cloud account, or a managed service.
• Whose binaries: community packages, a vendor distribution, a container image from a public registry, or a managed engine.
• Extensions, plugins and operators: PostGIS, pgvector, Patroni, Redis modules, RabbitMQ plugins, the Kubernetes operator in use.
• Business owner and the services that depend on it.

Version and binary source matter most. A cluster on community PostgreSQL 14 can change support vendor next month. A cluster that depends on features in one vendor's own distribution cannot, and should stay where it is until that dependency is planned out.

Step 2: put every renewal date on one calendar

Pull each contract and record the renewal date, the notice period for non-renewal, whether it renews automatically, the pricing unit and what the contract says about versions. Then add the upstream end-of-life date for every version in the inventory. The end-of-life tracker has the dates for each engine, and the MySQL 8.0 end-of-life page covers the date most MySQL estates are dealing with this year.

The calendar tells you the order of work. A contract whose notice period closes next month goes first; a contract that renews in eleven months can wait.

Step 3: map overlaps and gaps

Step 4: what to require from a single vendor

One contract is only an improvement if it covers more than the contracts it replaces. Put these requirements in the request for proposal:

• End-of-life coverage. Patched builds for the versions in your inventory that upstream has stopped fixing, with the vendor's own end date for each.
• Signed builds. Packages and images signed by the vendor, delivered through your own repository manager or registry.
• SBOMs and CVE records. A software bill of materials per build and a record of which CVEs each build fixes, in a form your auditors accept. SBOMs for end-of-life components and the audit evidence checklist cover what auditors ask for.
• Escalation. One path for incidents that cross the database, the cache and the broker, a stated P1 response time and named engineers.
• The runtime layer. Erlang/OTP, the JVM and the coordination services such as ZooKeeper and etcd that the engines depend on.
• Your infrastructure. Support for where you run today, without a platform or operator you must adopt first.
• A pricing unit that does not punish growth. Per-core or per-GB pricing makes every capacity increase a contract event.

Step 5: move support, not data

A support transfer does not touch the data directory. The new vendor needs read access to configuration, monitoring and logs, a copy of your runbooks, and the open ticket history from the outgoing vendor. Its first builds install the way a minor release does, replicas first, during your normal maintenance windows. Switching PostgreSQL support vendors without migrating walks through the handover in detail.

Sequence the transfers by renewal date, so you never pay two vendors for the same cluster for long and never leave a gap between contracts.

The risk of consolidation, and how to reduce it

Putting every engine with one vendor creates concentration risk: if that vendor has a bad year, every part of your data stack feels it. Reduce it with terms, not by keeping extra contracts:

• Stay on open source binaries. Community builds, or patched builds of them, keep the exit open. Any vendor can support them, and so can your own team.
• Own the artefacts. Builds, SBOMs, runbooks and the inventory live in your repositories, not only in the vendor's portal.
• Write an exit clause. Ask for a handover period, export of ticket history and a statement that patched builds already delivered remain yours to run.
• Check engine depth. Ask to meet the engineers who will handle PostgreSQL, MySQL and RabbitMQ incidents, not only the account team.
• Keep an internal owner per engine. Someone on your side should still understand each technology well enough to judge the vendor's advice.

Consolidation is the wrong move for some engines. If one depends on a vendor's proprietary distribution, such as Oracle-compatible PostgreSQL or Redis Software's Active-Active replication, that engine should stay with the vendor that builds it.

Where OSSeva fits

OSSeva puts PostgreSQL, MySQL, MariaDB, Redis, Valkey, RabbitMQ, Kafka, MongoDB, Elasticsearch, ZooKeeper and the Erlang/OTP runtime under one contract, one renewal date and one escalation path. It ships patched, signed builds for lines upstream has dropped, including PostgreSQL 11 to 14, MySQL 5.7 and 8.0, MariaDB 10.4 to 10.6, Redis 6.2 and 7.0 and RabbitMQ 3.x, so consolidation does not force an upgrade first. OSSeva Assure adds SBOMs and CVE remediation records. OSSeva Operate adds 24/7 operations with a 15-minute P1 response, and patches Critical CVEs (CVSS 9.0 and above) within 48 hours and High within 7 days. Pricing is per cluster, not per core, per GB or per node. Open source database support consolidation describes the offer; book a discovery call for a quote.

Frequently asked questions

What is database vendor consolidation?

Replacing several support contracts for different database engines with fewer, ideally one, that covers the engines, caches and brokers you run. Done well, the software and data stay where they are and only the support relationship changes.

Do we have to upgrade before consolidating support?

Only if the new vendor supports current versions alone. A vendor that ships patched builds for end-of-life lines can take over the cluster on its current version and leave the upgrade to your own schedule.

How long does consolidation take?

As long as your renewal calendar. Each technology moves when its current contract ends, so the full transition usually spans one contract year. The inventory and the requirements can be finished in weeks.

Is one vendor for every database a single point of failure?

It concentrates risk on one supplier. Keeping open source binaries, owning your builds and runbooks, and writing an exit clause make the vendor replaceable, which is the protection that matters.

What is third-party database support?

Support from a company other than the one that sells or maintains the database. For open source engines it is normal: the code is public, so a support vendor can build, patch and support it without the original author's involvement.

How do we compare the cost of one contract with several?

Add the contracts, any commercial licences you would like to leave and the engineering time spent on patches and vendor tickets. The support cost calculator does that sum with your own numbers.