Database support policy

A support level says how much Ptah testing stands behind one database release line. It does not enable or disable database operations. Ptah decides whether an operation is valid from the capability profile resolved for the target server.

The four levels

Level	Ptah’s testing promise
certified	Ptah exercises the release line in continuous integration and commits to the tested feature surface.
legacy-tested	Ptah still exercises an upstream end-of-life line as a regression sentinel. Runtime behavior is unchanged; the maintenance promise is weaker.
best-effort	Ptah does not regularly exercise the line. The connection is not rejected, and resolved capabilities still govern each operation.
known-incompatible	Ptah has measured and named a concrete technical incompatibility. Upstream end of life alone does not earn this label.

The current assignment for every declared line is generated on the support matrix. Do not copy its counts or release-line lists into authored prose.

How Ptah assigns a level

Two questions determine the ordinary case:

1. Does Ptah continuous integration exercise the release line?
2. Does the vendor still support that release line?

Two yes answers produce certified. An exercised line past upstream end of life becomes legacy-tested. A line that Ptah does not exercise is best-effort, regardless of the vendor’s own support statement.

An emulator is a deliberate exception. Exercising an emulator proves that the capability preset still matches that interface; it does not certify the managed service. The release-line declaration records whether evidence came from an emulator so the certification check cannot silently treat the two as equal.

A version outside the declared set

A server whose version matches no declared release line resolves to best-effort. Ptah does not refuse the connection. The dialect resolver selects the closest applicable preset: a version ladder where one exists, or the dialect default or banner match otherwise.

Ask the server in front of you what Ptah resolved:

ptah db capabilities --db-url "$DATABASE_URL"

The text report names the support level, release line, server version, preset, preset source, behavior values, and supported or unsupported capability keys. The JSON form contains the same facts plus each capability key’s documentation:

ptah db capabilities --db-url "$DATABASE_URL" --format json

For an undeclared version, the report explicitly says that the preset is a fallback rather than a measured match. The capability-probe pipeline is stricter than runtime behavior: a result it cannot attribute to a declared line is not accepted as evidence for that line.

Support and capability answer different questions

• Support level: how often and where Ptah tests this release line.
• Capability: whether this concrete target accepts a schema construct or operation.
• Dialect: which parser, renderer, and database family Ptah uses.

A certified line may deliberately lack a capability. A best-effort line may still support an operation because its resolved preset enables it. See Dialects and capabilities for the runtime model and Capabilities for the complete key reference.

Upstream end of life

An upstream end-of-life date never removes a line or blocks a connection by itself. What it changes is the promise. A line Ptah keeps exercising moves from certified to legacy-tested. A line Ptah stops spending a test run on moves to best-effort, and the support matrix prints the reason beside it. Removing a release line, refusing an operation, and changing a capability preset are separate product decisions that need their own evidence.

A best-effort line is resolved and operated exactly as any other, and may break as the code around it moves. That is what the level states, and it is why the line stays declared instead of being deleted: the compatibility is kept on a best-effort basis rather than withdrawn.

A daily job compares the declared lines against the vendor calendars, so a declaration that overtakes its upstream support is noticed on the day rather than the next time somebody re-reads the table. Most calendars come from endoflife.date; a vendor it does not carry has its schedule recorded in Ptah with the page it was read from, so no release line is left unasked about. Where a line promises more than its calendar allows, the job opens a draft pull request lowering it, and a person decides.

The date the comparison uses is when the vendor stops shipping patches for the line, which is earlier than the vendor’s final end-of-life date where the two are published separately. That is the date a testing promise turns on.