0.13.0

This release is about how many databases this product can actually be pointed at, and about
saying so in a way that survives checking. Four engines gained a driver, eighteen more were
measured through the drivers that already existed, and every count on every public surface now
states which set it counts.

Four more engines: fourteen drivers

• Apache Trino over its own client protocol, with no runtime dependency added - the
  provider speaks Trino's HTTP protocol directly, including its nextUri paging.
• Elasticsearch and OpenSearch as two engines over one shared SQL transport. They are
  two separate type-ids with two doc pages and two integration suites, because that is what a
  user picks, even though one module serves both.
• Apache Cassandra over CQL. Its statistics panels are left blank rather than filled with
  numbers Cassandra does not keep: a distributed store has no single row count to report, and
  printing a 0 there would be a measurement the engine never made.

Eighteen more engines, each one probed

Some engines speak a wire protocol we already ship, so they work through an existing driver
with no code of their own. Eighteen are now published, and none of them on the strength of the
protocol alone - each was connected to a live instance and every introspection surface was
called separately:

MariaDB, TiDB, Vitess, StarRocks, OceanBase, SingleStore, Citus, TimescaleDB, YugabyteDB,
AlloyDB Omni, Apache Cloudberry (incubating), CockroachDB, Materialize, RisingWave, Valkey,
DragonflyDB, KeyDB and FerretDB.

Fourteen drivers therefore reach thirty-two named products.

How much of the product you get differs per engine, and that is published per engine rather
than averaged into one word: full means every surface answered, partial means the editor
works while parts of the browser or the dashboard are blank, and query-only means the SQL
editor and nothing else. The connection dialog tells you which relatives the driver you just
picked serves, and the compatibility table in docs/providers/README.md records the exact
version probed and what was found broken or misleading on it - a Citus distributed table and a
TimescaleDB hypertable report row counts that are wrong rather than missing; YugabyteDB reads 0
until you run ANALYZE; Vitess cannot cancel a running query because vtgate refuses
KILL QUERY.

A name that was probed and did not earn an entry is not quietly omitted either: Cloud Spanner's
PostgreSQL dialect answered 1 of 15 surfaces, and that result is recorded beside the table with
the number that refused it.

Monitoring stops reporting an absence as a zero

Five panels printed a confident 0 for engines that keep no such counter - a number the engine
never produced, indistinguishable from a real zero. They now leave the field blank. An empty
panel that says nothing is worth more than a populated one that says something false.

Elsewhere

• The Redis schema explorer emits Redis commands, from a generator of its own, instead of
  SQL that cannot run there.
• OIDC logout resolves generic end-session URLs from the provider's discovery document
  rather than building one by hand.
• The query agent enforces single-drive ownership and refuses appends once a run has closed,
  and its rail answers first instead of narrating its steps.
• The container resolves its own bind address at startup, proving dual-stack with a
  throwaway listener rather than assuming IPv4. config.bindAddress overrules it.
• The login page publishes what the product actually connects to: fourteen engines named as
  engines, the eighteen relatives named beside them, and the embedded store marked as embedded
  rather than counted as a database you run.

Counts that state their own basis

Nine public surfaces still said "thirteen engines" after Cassandra shipped - an ArtifactHub
page, an OperatorHub listing, the apt and rpm package description, a marketplace draft. All are
corrected, and more usefully, the counts now say what they count: fifteen type-ids, fourteen
external engines, fourteen provider modules (Elasticsearch and OpenSearch share one), eighteen
relatives, thirty-two connectable products. Those are five different numbers about the same
product, and a count whose denominator is unstated is the kind that goes stale without anyone
noticing.

Helm chart: 0.1.44

No template change. Two things ride this release because the chart-version gate makes either one
cost a chart version of its own:

• cassandra was missing from the chart's keywords. ArtifactHub search matches on keywords,
  so the engine that shipped in 0.12.0 could not be found there.
• The artifacthub.io/changes annotation is written by hand for what this release gives an
  operator. As published on 0.1.43 it still described 0.1.42's IPv6 work; that chart version is
  in the live index and cannot be republished, so this is fixed forward.

containsSecurityUpdates is false, and that is a statement rather than a default. 0.13.0
does carry a dependency pin with a CVE attached - adm-zip held at ^0.6.0 for CVE-2026-39244,
outside what cassandra-driver's own range resolves to - but it arrives with
cassandra-driver rather than fixing anything 0.12.0 shipped. 0.12.0 has no cassandra-driver
and therefore no adm-zip, so upgrading removes no exposure a user of the previous release had.
The vulnerable path is unreachable from this product in any case: adm-zip has one consumer in
the driver, and it returns immediately unless a cloud option is set for Astra DB
secure-connect bundles, which no connection here sets.

Upgrading

Nothing to do. No configuration key changed meaning and no stored connection needs editing. If
your Service is dual-stack or IPv6 and you upgraded from a chart older than 0.1.42, read that
chart's note first: the container may begin answering on its IPv6 address, which a host that
firewalls only IPv4 will expose.

Full changelog: 0.12.0...0.13.0