feat(compat): Apache Doris is a partial MySQL relative, and the fork we shipped was the wrong half (#424)

[cevheri]

Closes nothing; ticks Apache Doris in the Phase 0 list of #424.

Why this engine, and why it was missing

StarRocks is a fork of Apache Doris, and this registry had the fork while missing the
original. That gap was found by an audit of #424's body on 2026-08-26, not by a probe -
six of the candidates named in that audit appear nowhere in this repository at all. Doris
is the highest-value one: MySQL wire, a single all-in-one container, real demand, and a
registered relative whose measured failure modes are the prior for it.

A prior is not an inheritance, which is the point of the numbers below.

What was measured

Probed against apache/doris:all-in-one-4.1.3 (doris version doris-4.1.3-rc02-7126cf65d96),
every surface called separately through createDatabaseProvider, then read again in real
Chrome against bun run build && bun run start.

Thirteen of fifteen surfaces answer. Where Doris and its fork part company is the data:

	Apache Doris	StarRocks (registered)
Row count, 2000-row table	2000	0
Table size	10187 bytes (SHOW DATA: 9.948 KB)	0 B
Cancel a running query	works - 8s sleep died at 1513 ms	not probed
Monitoring dashboard	six tabs answer	six panels, sessions carries the refusal
version()	fictitious 5.7.99, real build in @@version_comment	fictitious 5.1.0, real build in current_version()
Indexes	none ever (information_schema.statistics empty)	none ever
EXPLAIN FORMAT='json'	does not parse	does not parse

Also measured: permission errors arrive as the right class with the server's own sentence,
a SELECT_PRIV role saw only its granted table, Analyze works while Optimize and
Check do not exist in the grammar, and a declared foreign key is invisible and
unenforced - SHOW CONSTRAINTS lists it, information_schema.KEY_COLUMN_USAGE is
empty, and an order row referencing customer 424242 inserted successfully.

Gate 7 passes. A plan run captured 2 tables (ctx_adf7) and drafted
SELECT c.country, COUNT(o.id) ... LEFT JOIN ... over the real objects; run unmodified it
answered TR 667, DE 667, US 666.

The two failures are ours, and they are filed rather than fixed

getOverview() and getHealth() send SHOW STATUS LIKE '...', which is
mismatched input 'LIKE' in the Doris grammar - while a bare SHOW STATUS is accepted
and answers zero rows. So the filter we add for our own convenience is the difference
between a panel that renders absence and a panel that renders an error.

Filed as D30. Not fixed here on purpose: it changes what two panels read on every
MySQL-wire engine (MySQL, MariaDB, TiDB, Vitess, OceanBase, SingleStore, StarRocks, Doris),
so it needs its own probe pass rather than a by-the-way edit inside a labelling change.

What only the browser found

The provider's boundary is not the product's - the U14 lesson from Cassandra:

• the header badge reads Slow, and Monitoring's Overview tab carries This database
  could not answer this panel with Doris's own sentence beneath it - one panel, not the
  dashboard;
• Tables reads 2 / 2.0K rows / 12.60 KB with the correct per-table numbers,
  Storage shows DB Size N/A above a populated tablespace list, Sessions lists 7,
  and Performance, Queries and Pool read N/A with Not measured rather than
  a fabricated zero;
• creating the connection takes two clicks of Establish Connection. Test Connection
  answers Connected, but this server answered no health data: ...; the first Establish
  reports that and stores nothing, the second stores it. That is the D9 contract
  working on an engine it was never tested against;
• one reading is recorded as suspect rather than claimed healthy: the Tables card
  summarises Vacuum 0 / OK on an engine with no vacuum-like operation.

The connection dialog's hint and the login hero both pick the engine up from the registry
with no per-engine code: the hero reads Plus 20 wire-compatible engines and the dialog
shows Apache Doris (verified on Apache Doris 4.1.3-rc02-...) - partial support.

Counts

Relatives 19 -> 20, published figure 33 -> 34, both re-derived from
connectableProductCount() (14 external drivers + 20 relatives). The shipped half does not
move - no new driver, no new dependency.

Three stale claims corrected along the way

README.md and DOCKERHUB.md still told a reader that a ScyllaDB connection "has to be
seeded or admin-managed", that SingleStore "loses five surfaces", and that StarRocks loses
its monitoring panel. D9 (#472), D8 (#476) and the per-panel degradation (#477) had already
overtaken all three. docs/providers/README.md was correct; only the front-door prose was
behind.

Verification

format · lint · typecheck · knip · build · tests/run-core.sh (351 files) ·
tests/run-components.sh (33 groups). Registry, docs table and compose fixture land
together, so the existing tests that hold each of those to the others stayed green - the
compose-service test and the docs-table test both failed first, which is how the entry was
driven in.

[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