feat(compat): Vitess and Apache Cloudberry, measured on a pinned image (#424)

[cevheri]

Phase 0 of #424. Both engines were probed on 2026-08-20 and ticked in the issue as measured, and neither existed in the code: no registry entry, no docs row, no compose service. This lands all three together and moves the published count from 27 to 29 (14 shipped drivers + 15 verified relatives, from verifiedEngineCount()).

Engine	Connect as	Tier	Probed version
Vitess	mysql	full, 15 of 15 surfaces	8.0.43-Vitess (Vitess 24.0.2)
Apache Cloudberry (incubating)	postgres	partial, 12 of 15	PostgreSQL 14.4 (Apache Cloudberry 2.1.0-incubating)

The probe was re-run, not inherited, and three recorded results changed

The Vitess image was not reproducible. The earlier run used the rolling vitess/vttestserver:mysql80 tag, which today serves a 25.0.0-SNAPSHOT built from main. A snapshot is not a version anyone can reproduce, so this re-probed the pinned release v24.0.2-mysql80, and the compose service names it.

Cloudberry's recorded "gate 7 passes" is refuted. Both acquisition paths refuse. As the cluster's own gpadmin the execution profile reads a superuser as too broad; with a least-privilege role the grounding capture is refused at 289 rows against a 200-row budget, 282 of those rows belonging to Cloudberry's own gp_toolkit and 7 to the user's two tables. Reproduced independently as gpadmin: 481 rows, 470 of them gp_toolkit. That is B52's shape on a second engine, and Cloudberry is a fork rather than an extension, so B52 is amended to say the server's own catalogs rather than an extension's; what generalises is narrower than the first measurement suggested.

One Vitess caveat is dropped rather than repeated. "A sharded keyspace refuses DML" was untestable here: show vitess_shards returns probe/0, so this instance is unsharded and no claim is made about a sharded one.

Three findings replace it:

• Cancelling a running query does nothing. vtgate refuses KILL QUERY with VT07001, and a 5 second SLEEP ran its full 5003 ms. The same call cancels successfully on a real MySQL 9 control.
• Per-index sizes read 0 bytes, and that one is ours. Filed as D6: the size query matches information_schema.INNODB_TABLES.NAME against '<database>/%', and Vitess names the InnoDB table after the physical shard database, so the rows are vt_probe_0/orders. The lookup then swallows the mismatch in a catch commented "INNODB_SYS tables not available", which makes zero matched rows indistinguishable from a server with no such catalog. A wrong number, not a missing one.
• No permission-error class could be measured at all, and the reason is the fixture rather than the engine: vttestserver grants any credential full rights (user=nobody with a wrong password read the table) and CREATE USER is a vtgate parse error. Stated that way in the caveat so it cannot be read as a claim about Vitess.

Verified in a browser, not only through the harness

• Vitess explorer: 2 objects for 2 user tables, 500 and 2000 rows; GROUP BY country answered 667/667/666; a plan run captured "2 tables, fingerprint ctx_3ce0" and drafted a statement grounded in the real orders.country and amount.
• Cloudberry explorer: 4 objects for 2 user tables, the extras being pg_ext_aux.pg_pax_fastsequence and pg_ext_aux.pg_pax_tables; row counts correct after ANALYZE; the monitoring page fails with query plan with multiple segworker groups is not supported verbatim; the plan run refuses.
• The Explain panel was checked against a real MySQL control before anything was called a defect: its summary tiles read 0 there too, so the panel is not degraded on Vitess and no caveat claims it is.

Two wording facts the browser exposed are recorded in the docs row rather than glossed: the Cloudberry agent refusal tells the user the engine offers no read-only execution profile when it is the role that was refused (a live instance of B47), and the three failing panels report a planner error as a connection error.

TDD

The new test is an invariant nothing enforced before: every registry entry must have a service in the compat profile of database-compose.yml, which is exactly what the docs already promise ("Reproduce any row with the compat profile"). It passed at 13 entries, failed on the 2 added here, and passes again once their services exist. redis shipping as a published engine with no compose service at all, fixed in #426, was this same gap.

Gates

format · lint · typecheck · knip · build · tests/run-core.sh (326 files) · test:components (30 groups) · coverage 39204/39204 lines (100.00%).

Gate 5 exemption, recorded by name as #424 requires: no Playwright spec is added for either engine. CI has no Vitess or Cloudberry instance, and both are compat-profile fixtures rather than services the E2E lane starts; everything a spec would assert was driven by hand in a browser instead, as listed above.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud