Open Source Support RFP Template: A Vendor Questionnaire for Database and Messaging Support

The short answer

A good RFP for open source support does three things. It gives every vendor the same inventory of what you run, it states requirements the vendor must answer in writing, and it asks questions that a weak offer cannot answer without showing the gap. The gaps that matter most are coverage for end-of-life versions, fix targets by severity, who builds the binaries, evidence for auditors, escalation across engines and the terms for leaving.

The template below is ready to copy into a document. Change the bracketed parts, delete what does not apply, and send the same version to every vendor on the shortlist.

How to use this template

• Send one document to every vendor and ask for answers in the same order, so you can compare line by line.
• Attach your inventory. Vendors cannot answer coverage questions about versions they have not seen.
• Ask for written answers, not a call. A call is useful later, once you know which answers need explaining.
• Ask for samples: one SBOM, one CVE remediation record and one support case history with the customer details removed.
• Score the answers with the rubric at the end before anyone sees the prices.

Section 1: your environment

Give the vendor one row per cluster. Clusters, not products, because two clusters of the same engine can sit on different versions and different infrastructure.

Section 2: requirements

State each requirement as a sentence the vendor must accept, qualify or decline. Mark each one Must or Should.

Coverage

1. [Must] The vendor supports every engine and version in Section 1, or lists each one it excludes.
2. [Must] For each version upstream no longer maintains, the vendor ships fixes and states the date its own coverage ends.
3. [Should] The runtime under each engine (Erlang/OTP, the JVM) and the coordination services (ZooKeeper, etcd) are covered by the same contract.
4. [Must] Support applies on our infrastructure as listed, with no platform, operator or distribution we must adopt first.

Fixes and builds

5. [Must] Security fixes are delivered as built, signed packages or images, not only as advice or source patches.
6. [Must] Fix targets are stated per severity, with the event that starts the clock.
7. [Should] Builds stay on the same major version, so installing one does not change the data directory or configuration.
8. [Should] Builds are delivered through our own repository manager or registry.

Evidence

9. [Must] Each build comes with a software bill of materials.
10. [Must] Each build comes with a record of the CVEs it fixes and the CVEs assessed as not applicable, with the reason.
11. [Should] The vendor states how it signs builds and how we verify the signature.

Support and escalation

12. [Must] Response targets are stated per severity, with the hours they apply.
13. [Must] One escalation path covers incidents that cross engines, for example database, cache and broker together.
14. [Should] We can name and meet the engineers who handle each engine.
15. [Should] Optional 24/7 operations are available for clusters we choose.

Commercial terms

16. [Must] The pricing unit is stated, and the vendor explains what changes in the price when we add cores, memory, nodes or replicas.
17. [Must] Renewal uplift is capped in the contract.
18. [Should] The vendor can start each technology when its current contract ends, so we do not pay twice for long.

Exit

19. [Must] On termination, builds already delivered remain ours to run.
20. [Must] The vendor provides a handover period and an export of ticket history and runbooks.
21. [Should] Nothing in the service requires our data to leave our infrastructure.

Section 3: questions that expose gaps

Requirements tell you what the vendor accepts. These questions tell you what it actually does. The right column shows the kind of answer that should lower the score.

Section 4: scoring rubric

Score each area from 0 to 3, multiply by the weight, and add up. The weights below suit an estate where several versions are past upstream end of life. Move weight from coverage to operations if most of your estate is current and the main goal is night and weekend cover.

Score before you open the price sheets. Then compare price against score, and against what you spend today. The database support cost calculator totals current contracts, licences and patch work from your own figures.

How OSSeva answers this template

OSSeva covers 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 and MariaDB 10.4 to 10.6, as DEB and RPM packages, tarballs and container images through your own repository. OSSeva Assure adds SBOMs and CVE remediation records. OSSeva Operate adds 24/7 operations and 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. Send us the template with your inventory, or book a discovery call for a quote.

Frequently asked questions

Should we send the RFP to managed database platforms too?

Only if hosting is on the table. A managed platform runs the database for you on its own version calendar; a support contract covers software you run. Mixing the two in one RFP makes the answers hard to compare.

How many vendors should be on the shortlist?

Three to five. Fewer gives you no comparison; more turns scoring into a project of its own.

Why ask about a specific incident instead of escalation policy?

Every vendor has a policy. A real incident, described in detail, shows whether the policy works when the problem crosses product lines.

Can the same template cover messaging and streaming?

Yes. RabbitMQ, Kafka and ZooKeeper fit the same sections. Add the runtime row, because Erlang/OTP and the JVM are where coverage gaps hide.

What should we check once the contract is drafted?

The terms that turn answers into obligations: renewal, uplift, coverage definitions, credits and termination. The support contract checklist covers them.