Support and versions

What stays stable, for how long, and how you hear about a change

QueryAPIGate is pre-1.0 and already keeps a written compatibility promise. Here is what it covers, which versions are supported, and how a change reaches you before it reaches your deployment.

Latest release{{ relText }}
Security fixes
On the latest release
Python
3.11 – 3.14
Status
Pre-1.0, with a written promise
What it covers

The compatibility promise

Covered

Changes only with notice

REST endpoints and response shapes, CLI commands and flags, environment variables, the on-disk storage format, API-key and role grant fields, the saved-query format, the MCP tool contract, and error codes.

Not covered

May change in any release

The Console's internal markup, exact wording of messages and log lines, and Python modules not re-exported from queryapigate.

Experimental

Labelled wherever you meet it

Outside the promise until they graduate. Today: H2, JDBC and MongoDB connections, OpenTelemetry tracing, and secrets and credentials from AWS. Live events and secrets from files and Vault graduated in 0.34. Marked in the docs, in /openapi.json, in the Console and in the startup log.

Versioning

Releases and deprecations

Patch{{ patchEx }}

Never breaks a covered surface. Fixes and security fixes.

Safe to take
Minor{{ minorEx }}

Before 1.0, may break a covered surface, rarely, and always under its own Breaking note in the changelog. Never silently.

Read Breaking first
1.0 and aftersemver

Semantic versioning: breaking changes only in a major release.

Coming with 1.0

The life of a deprecation

  1. 1Announced

    Only once its successor ships: a Deprecated note in the changelog and a callout in the docs.

  2. 2While deprecated

    A Deprecation header (RFC 9745) and a Link: rel="successor-version" header on every response, deprecated: true in OpenAPI, and a log warning on first use.

  3. 3Removed

    Before 1.0, no sooner than the next minor release; from 1.0, not before the next major. Always listed under Breaking.

Support

What is supported

Security

Fixes on the latest release

Security fixes are made against the latest released version, announced under Security in the changelog. Upgrading is designed to be routine: see below.

Trust center
Python

3.11 and later

Each Python version is supported until its upstream end of life; CI runs 3.11, 3.12, 3.13 and 3.14. Dropping one is a minor release, called out under Breaking.

Databases

Tier 1 and experimental

Tier 1, under the promise: PostgreSQL, MySQL, SQLite, DuckDB and ClickHouse, each tested against the real database. Experimental: H2, generic JDBC and MongoDB, with the gaps the support matrix lists.

Support matrix
Dependencies

Oldest versions tested

CI runs the suite on the lowest version allowed of every core dependency and of the mcp, jwt and redis extras, so a minimum in the package metadata is one that actually works.

Upgrades

Upgrading is routine, and tested

Guide 34: Upgrade safely →
  • Every 0.x store upgrades automatically when a newer version starts, or refuses with a clear message. Tested in CI with real stores from earlier releases.
  • Rolling upgrades on several instances: the previous release keeps serving beside the new one on the upgraded store, tested in CI on every change.
  • The Helm chart is upgraded from the previous release on a real cluster with requests running, failing on a single failed request.
  • Each release's changelog entry starts with Upgrading: schema changes, settings to add, and anything to do first.
Help

Getting help

Questions and bugs

Open an issue on GitHub. Include the version (queryapigate --version or /health) and the request id from the response's X-Request-Id.

Open an issue

Security issues

Privately, through GitHub's Report a vulnerability form. Never in a public issue.

Report a vulnerability

Contributing

Fixes, guides and new connection types are welcome. The contributing guide covers the tests, the release process and how features graduate.

Contributing guide