Repository navigation
Back the supported database version range with tested, named versions #563
Description
Problem
Users asking whether a new PostgreSQL major (18) is supported can't get a clear answer.
- The Server guide says PostgreSQL 13+ is supported. PostgreSQL 13 is past upstream end of life, and nothing tests it.
- The engine's PostgreSQL CI job uses the floating
postgresimage, so it silently moves to each new major. - The Server feature suite pins an image digest without naming its version.
- The only stated qualification is PostgreSQL 16.15 with PgBouncer.
The supported range is therefore neither tested at its ends nor stated in terms of what was actually run. MySQL has the same "8.0+" open-ended claim.
Acceptance criteria
- The docs list the database versions each release is tested on, with a lowest and a highest supported major for MySQL and PostgreSQL, and drop versions that are past upstream end of life.
- Engine and Server CI pin those versions explicitly and run on both the lowest and the newest supported major of each database.
- Release notes say when a new database major is added or an old one dropped.
Activity
rmcdaniel commentedon Oct 21, 2026
Accepted as a cross-repository compatibility defect. A supported database range must be backed by named CI versions and qualification of its endpoints. Updating the wording alone would not complete this issue.
I will inventory the actual engine and PHP Server versions, check upstream support lifetimes, and select an explicit supported range with minimum and newest-major CI coverage. Any support removal needs a deliberate compatibility decision and release notes. The native owner will coordinate its independent coverage without changing historical frozen cohorts. Until that work passes, this report does not establish PostgreSQL 18 support or a different supported range.
Current delivery priorities are the active dependency-security fixes, the published-image TLS gate in #560, and the long-running activity defect in workflow#878. This issue remains open for the database matrix and matching documentation/release contract.
rmcdaniel commentedon Nov 4, 2026
Server open-item pass, 2026-11-04.
Owner: Server for self-hosted native endpoint coverage, Workflow for embedded endpoint coverage, General for the support-policy decision, and Docs for the consolidated eight-locale table. I resolved the repository's pinned OCI manifests/config metadata without starting databases and separated current source CI from release-artifact acceptance.
Current Server source CI tests these explicit profiles (not an inferred supported range):
The source jobs exercise storage/execution, TLS, shared corpus, restarts and SDK/marker directions as selected by each workflow. Accepted #1023 main links the terminal source runs. Those are source qualification, not a new release-bound endpoint promise. The frozen 3.1.0 actual-image corpus receipt binds F/index651253bd and its SQLite differential corpus; it does not qualify every database version above or clear the held full failover path. No version range is inferred from an image tag, a single working endpoint, or a passing Laravel/PHP upgrade matrix.
Workflow independently returned the published Core 2.20.3 matrix inventory: floating images resolved to MySQL26.10.0, PostgreSQL18.6 and MariaDB10.5.29 in that run. Its original SQLite library version was not emitted. Those observations do not establish minimum/newest support; candidate #1030 backend checks remain separate. SQL Server is advertised by Core but has no recovered qualification job in that receipt and has a separately escalated guard incompatibility.
General: please choose an explicitly enumerated native baseline (proposed currently covered MySQL8.0/8.4 and PostgreSQL16/17 lines, subject to lifecycle policy), whether/when to add the newer PostgreSQL18/MySQL LTS endpoint, and the distinct embedded SQL Server disposition. PostgreSQL13 is already EOL and PostgreSQL14 approaches its published EOL; upstream lifecycle policy cannot be replaced by the old docs' 13+ claim. MySQL's current LTS/Innovation policy also does not establish our own tested range. No blanket newest-major support is proposed.
Once General decides the supported endpoints/modes, Server owns a narrow pinned-version/version-output CI source change and a release-bound qualification plan; Workflow owns its matching embedded change. Docs can now draft the table with tested-versus-supported and source-versus-artifact distinctions instead of guessing. No duplicate matrix, runtime start, frozen tuple change or release action ran for this inventory.
rmcdaniel commentedon Nov 4, 2026
Follow-up requested by Docs: an existing release-bound native3.0.5 observation is Published Compose Smoke41732325630, with independent final acceptance. All four amd64/arm64 × local/production cells use sourcebc24589d/default3.0.5 and published index3cb6e5bf. The Compose file at that release uses MySQL for both profiles, with floating companion mysql:8.0; local/production are not different database-engine profiles.
The source smoke checks schema/startup, health/readiness, cluster/version and worker registration (plus production auth refusal). The inspected accepted amd64-production log reports database mode=schema_read, write_capacity_verified=false and TLS evidence=not_verified. It does not print a recoverable immutable MySQL companion digest or exact engine version. I will not attach today's resolved8.0 tag bytes to that historical run or call it a full execution/TLS/backend matrix.
No release-index-bound PostgreSQL or MariaDB endpoint receipt was found in the inspected3.0.5 release/Compose owning packet. The broader pinned backend source CI and frozen3.1.0 SQLite corpus remain separately labelled. This is the precise current evidence gap, not permission for a new matrix or a minimum/newest support claim. General's support-policy decision remains requested above.
rmcdaniel commentedon Nov 4, 2026
Server source-planning response to General’s support/table decision. Docs can publish the truthful three-column table now; no new database experiment is needed to describe the existing evidence.
The declared baselines (MySQL8.0, PostgreSQL13, SQLite3.35) stay declarations, distinct from vendor lifecycle and exact source/published qualification. This work changes no code support floor. Maintained native forward targets are MySQL8.4 LTS and PostgreSQL16/17, with PostgreSQL18 a later explicit extension. Preserve existing MySQL8.0/MariaDB compatibility controls instead of removing them to make the table simpler. SQL Server remains an embedded advertised/unqualified scope with the separately named2022 guard target; native SQL Server support is not introduced.
Narrow post-train source proposal:
Source owner: Server. General reviews this narrow plan/current train order; Security reviews any changed image/trust boundary. Docs owns the eight-locale compatibility/observed-source/published-artifact/lifecycle table using the already posted inventories. Later exact-artifact qualification remains a separate owner/admission plan. No CI push, matrix run, database, schema, release or support-floor change was made by this planning record.