HeliosDB Release and Capability Matrix: Reference Terms

Change log

1. Purpose

1.1 HeliosDB publishes a Release and Capability Matrix (the "Matrix") that states, for each HeliosDB edition, what is released and supported, and records the versions on which the evidence for each statement was obtained. Contracts, orders, support and partner materials refer to the Matrix instead of repeating capability statements. This document explains how the Matrix is built, what its statuses mean, and how it binds HeliosDB.

1.2 The Matrix includes the HeliosDB Compatibility Matrix, which lists database engines, protocols and open-source drivers for HeliosDB Nano, HeliosDB Lite and HeliosDB Full, per edition, driver package and tested version.

2. Structure

2.1 The Matrix records its evidence in rows: one row per edition, capability and tested version, and for the Compatibility Matrix one row per edition, engine, driver package and tested driver version. Each row states, where relevant: the protocol or API version; the driver package name, language, upstream source and licence; the tested driver and runtime versions and the HeliosDB versions or builds on which the evidence was obtained; the date last tested; connection, authentication and TLS settings; supported operations; known limitations and workarounds; and the test evidence, including HeliosDB's own production use.

2.2 The Matrix is published in a readable form and in a machine-readable form. Each published version carries a version identifier and a date. A version that HeliosDB designates as frozen also carries the SHA-256 fingerprint of its machine-readable file and is never changed afterwards.

2.3 The Matrix states its statuses per edition and capability, as clause 3.4 describes. The versions and builds recorded in the rows are the evidence for a status.

3. Statuses

3.1 Each capability, and each row of the Matrix, has one of these statuses:

3.2 The Matrix lists a database engine, protocol or driver for an edition only with one of these statuses, and one that it does not list for an edition is not offered or supported in that edition. HeliosDB's own interfaces (its REST and HTTP APIs, the embedded library and the MCP endpoint) are described in HeliosDB's product documentation; the Matrix gives one of them a status where HeliosDB's production use recorded in the Matrix covers it.

3.3 Release readiness is shown separately. A Generally Released version is one designated as generally released in the Matrix; preview, nightly, release-candidate and source-build-only versions are not Generally Released.

3.4 Statuses are not tied to a release. The status of a capability for an edition is the highest status that HeliosDB's evidence supports on any version or build of that edition, published or internal, including HeliosDB's own use of the edition in production; while HeliosDB's own production use of a capability is recorded as failing and none as working, the capability is In preview. The Matrix does not name a release that its statuses are based on, and a status does not state that every version of the edition works as it describes.

3.5 A status describes the edition; it does not state that a particular version was tested. The rows record the versions and builds behind each status, and HeliosDB confirms them on request, together with the known limitations of a particular version. A document or order that refers to the Matrix for a particular version, such as the version in use, refers to the status of the edition, subject to the known limitations of that version that HeliosDB states on request.

3.6 Operations are given their own status where they differ from the row, and operations that do not apply to an engine are marked as not applicable rather than implying support.

4. How the Matrix binds HeliosDB

4.1 Only rows with the status Available or Available with limitations describe supported capability. Support under the HeliosDB Support Policy and the HeliosDB Transaction Durability Commitment applies only within those rows.

4.2 An order identifies the frozen Matrix version that applies to it. A later edit of the Matrix does not reduce what an order already identifies. Removing supported behaviour follows clause 5.

4.3 Driver compatibility does not mean complete feature parity with the original database engine, or compatibility with every application, extension or administrative tool. It does not imply any endorsement or certification by the owners of those engines or drivers.

4.4 Statements counting engines or drivers per edition are made only where the Matrix supports them, and only in the form the Matrix states.

4.5 Requested capabilities beyond the Matrix are handled through a scoped evaluation or a separate development order, not as support.

5. Changes and deprecation

5.1 HeliosDB gives at least 90 days' notice before removing a supported row or operation in a new version, except where a legal or security reason requires faster action; in that case it gives notice as soon as possible with a mitigation plan.

5.2 HeliosDB keeps the history of published Matrix versions and makes each frozen version available.

6. Release series and lifecycle

6.1 Where HeliosDB designates a supported release series for an edition, the Matrix states its first release date, the period for which security fixes will be provided and its end-of-support date. HeliosDB gives at least 90 days' notice before the end of support, with a commercially reasonable upgrade route.

7. Draft and frozen versions

7.1 The status of each Matrix version (draft or frozen) and of each release series is shown with the Matrix. A draft version is informational only: no order can rely on it, or on an engine or driver count derived from it, until HeliosDB freezes that version and an order identifies it.

Annex A: Status summary on the effective date of this version

Informational summary of the draft Matrix on the effective date of this version (clause 7.1). Each status is the highest that HeliosDB's evidence supports on any version or build of the edition (clause 3.4), so no release is named. The first table lists every database engine that an edition lists, with its protocol, including every engine that HeliosDB's tests or its own production use show working on any version; a dash means that the edition does not list the engine. The second table lists HeliosDB's own interfaces to which the Matrix gives a status because HeliosDB's production use recorded in the Matrix covers them (clause 3.2). Individual drivers, operations, limitations and the versions behind each status are stated in the Matrix itself.