// For Procurement & Vendor Management
Open source support for procurement and vendor management.
One contract, one renewal date, one escalation path.
OSSeva puts PostgreSQL, MySQL, MariaDB, Redis, Valkey, RabbitMQ, Kafka, MongoDB and the runtimes under them in a single agreement, including versions upstream no longer patches. Pricing is per cluster, so the bill does not move every time engineering adds capacity.
Consolidating open source support contracts
One contract instead of several
Open source support tends to arrive one contract at a time: a PostgreSQL subscription, a cache vendor, a broker contract after an outage. One agreement replaces that contract sprawl with one supplier review, one security questionnaire and one escalation path.
Renewal dates on one calendar
List every contract's renewal date, notice period and auto-renewal clause. The contract whose notice deadline comes first moves first. OSSeva picks up each technology as its current contract ends, so you do not pay twice for long and never have a gap.
One pricing unit
Per-core, per-node, per-GB and per-vCPU-hour contracts each move with a different part of your infrastructure. OSSeva prices per cluster, so adding cores, memory or replicas does not change the support bill.
Evidence your auditors accept
Signed builds, a software bill of materials per build and CVE remediation records come with OSSeva Assure, so vendor risk and audit teams review one set of documents.
Open source database support consolidation describes the transition in detail.
What to require in an open source support contract
Put these six questions to every vendor in writing, OSSeva included, and compare the answers line by line.
Ask
Which of our exact versions do you ship fixes for, and until what date?
Why it matters
A vendor that supports only versions upstream still maintains will ask you to upgrade before it takes over. Ask for patched builds of the lines you actually run, with an end date for each.
Ask
What are the response and fix targets for each severity, when does the clock start, and what credit applies if a target is missed?
Why it matters
A single response time says little. For comparison, OSSeva Operate commits to a 15-minute P1 response and patches Critical CVEs (CVSS ≥ 9.0) within 48 hours and High within 7 days.
Ask
Who builds the binaries, how are they signed, and do we get an SBOM and a CVE record for every build?
Why it matters
Advice without builds leaves your engineers doing the patching. Signed artefacts and SBOMs are also what auditors ask for.
Ask
What handover period, ticket history export and runbook transfer do we get if we leave, and do delivered builds remain ours to run?
Why it matters
Exit terms make a single vendor replaceable. Open source binaries on your own infrastructure keep the data where it is whichever vendor you choose next.
Ask
What is the pricing unit, what cap applies to uplift at renewal, and what happens to the price when we add capacity?
Why it matters
The unit decides whether growth becomes a contract event. Write the uplift cap into the agreement rather than the proposal.
Ask
Which runtimes, extensions, plugins and operators are covered, and on which infrastructure?
Why it matters
Erlang/OTP under RabbitMQ and the JVM under Kafka are often nobody's responsibility. Bare metal, VMs, Kubernetes and cloud accounts should all be in scope if you use them.
How OSSeva prices
Support is priced per cluster, not per core, per GB or per node, in three tiers. Book a discovery call for a quote. To compare against what you pay today, the database support cost calculator totals your current contracts, licences and patch work from your own figures.
OSSeva Patch
Patched, signed builds for the versions you run, including lines upstream has dropped, with CVE notifications.
OSSeva Assure
Everything in Patch, plus upgrade and migration planning and compliance evidence: SBOMs and CVE remediation records.
OSSeva Operate
Everything in Assure, plus 24/7 operations, a 15-minute P1 response, and Critical CVEs patched within 48 hours and High within 7 days.
When another supplier is the better fit
You want the databases hosted for you
OSSeva supports software you run on your own infrastructure. A managed service from your cloud provider or a managed database platform fits better if you want the vendor to run it.
An engine depends on a proprietary distribution
Oracle-compatible PostgreSQL, MySQL Enterprise components or Redis Software's Active-Active replication belong with the vendor that builds them. Consolidate the rest around them.
Frequently asked questions
How do we consolidate open source support contracts?
Inventory every cluster with its exact version and where it runs, put every contract's renewal date and notice period on one calendar, mark where contracts overlap and where nothing covers you, set requirements for the single vendor, then move each technology as its current contract ends. The software and the data stay where they are; only the support relationship changes.
What should an open source support contract include?
Coverage for the exact versions you run, including end-of-life lines; response and fix targets by severity with credits; who builds and signs the binaries; an SBOM and CVE record per build; exit terms with a handover period; the pricing unit and an uplift cap; and the runtimes, extensions and infrastructure in scope.
How does OSSeva price support?
Per cluster, not per core, per GB or per node, in three tiers: OSSeva Patch, OSSeva Assure and OSSeva Operate. Book a discovery call for a quote.
Do we have to upgrade before we change support vendor?
Not with OSSeva. It ships patched, signed builds for end-of-life versions such as PostgreSQL 11 to 14, MySQL 5.7 and 8.0 and MariaDB 10.4 to 10.6, so support can move first and upgrades follow on your schedule.
Which technologies can one OSSeva contract cover?
PostgreSQL, MySQL, MariaDB, Redis, Valkey, RabbitMQ, Apache Kafka, MongoDB, Elasticsearch, ZooKeeper and the runtime layer underneath, such as Erlang/OTP. The technologies page lists every version.
What if we leave OSSeva later?
Your clusters run open source binaries on your own infrastructure, so another vendor or your own team can support them. Ask for exit terms in writing during the discovery call, as you would with any supplier.
One contract, one renewal date, one escalation path.
Bring your contract list and renewal dates to a discovery call. We will map a transition contract by contract and send a quote priced per cluster.