[cevheri]

Continues #424 Phase 0. Stacked on #503 (Apache Doris) — that PR's commit is the parent
here, so review or merge it first and this diff reduces to its own commit.

Two engines probed, one entry

Engine	Verdict	Probed
Garnet 2.1.5	registered full via redis	ghcr.io/microsoft/garnet:2.1.5
QuestDB 10.0.1	measured and refused a row	questdb/questdb:10.0.1

Both called surface by surface through the real provider, then read again in real Chrome
against bun run build && bun run start.

QuestDB is the reason this PR exists

Everything short of a browser said "register it": QuestDB speaks the PostgreSQL wire protocol
on 8812, and through the provider SELECT country, count() c FROM probe_orders returns three
rows. So it looks exactly like a third query-editor-only relative beside Materialize and
RisingWave.

In the product the editor cannot run anything. Pressing Run answers
500 unknown function name: pg_backend_pid() — the editor always attaches a queryId, and
the provider then issues SELECT pg_backend_pid() before the statement. Measured both ways at
the provider boundary so the cause is established rather than inferred:

provider.query(sql)                 -> OK, 3 rows
provider.query(sql, [], "editor-1") -> FAIL unknown function name: pg_backend_pid()

A query-editor-only tier claims exactly one thing, and that is the thing that does not work.
This is the Cloud Spanner case already recorded in this repo, found the same way, so it is
handled the same way: no registry entry, and the number is the finding in
docs/providers/README.md under Measured, and refused a row. The unit test and the e2e hint
assertion both pin the absence, because QuestDB is the most re-addable name on that list —
and the questdb compose service stays under the compat profile so the refusal can be
reproduced instead of trusted.

Recorded there too, because it is the trap for whoever revisits this: QuestDB is not the
Materialize/RisingWave case of an absent catalog. information_schema.tables lists the table
and pg_catalog.pg_class answers with 36 columns. The object browser fails on two independent
causes of ours — the schema query's AS MATERIALIZED CTEs are a syntax error there, and
with the keyword removed the same query dies on pg_total_relation_size() — so fixing either
one alone changes nothing.

Garnet

Every Redis surface answers, so full by this registry's own definition, with the wrong numbers
recorded as caveats the way Citus's are. Browser-verified: tree user:* 50, session:* 20,
queue:* 1; a {"command":"GET","args":["user:1"]} run returned the value; Monitoring showed
7.4.3, Connections 0 / no limit published, Tables 71 / 0 indexes.

What makes its row different from the three Redis relatives already here:

• its own version was available and went unread — INFO carries garnet_version:2.1.5 and
  server_name:garnet, and the overview shows Redis 7.4.3. Valkey and DragonflyDB publish only
  an emulation level and KeyDB nothing at all, so on those three the displayed version is the best
  reading available; here it is not;
• two readings are absences wearing a value, both checked against Redis 8.10.0 in the same
  pass: no used_memory, so every size reads 0 B; no keyspace_hits / keyspace_misses, so the
  cache hit ratio reads 100% — and the dashboard rates it Excellent, which is D14's fallback
  being graded;
• fixture note: it is in-memory with no persistence, measured — dbsize 71 before a docker stop,
  0 after.

D31, found while chasing the QuestDB tree

A connection whose POST /api/db/schema/list fails leaves the previous connection's tables on
screen as its own. Measured with the network captured: probe_customers 3 and probe_orders 2.0k
— Doris's tables, Doris's row counts — under a header reading QuestDB 10.0.1 (probe), while
QuestDB's own questdb_only_marker never appeared and QuestDB has no probe_customers at all.

fetchSchema in src/hooks/use-connection-manager.ts toasts and returns without touching
schema; Studio.tsx clears it only when the active connection becomes null. Storage is not
involved — /api/storage/config answers serverMode: false and libredb_schema_snapshots was
empty. Worse than an empty tree, because it attributes real objects with real row counts to a
database that does not contain them and the tables are clickable. Hits every engine whose object
browser fails: CockroachDB, Materialize, RisingWave, QuestDB.

Filed as D31, not fixed — the fix is a hook change with its own coverage, not a line inside a
labelling PR. One observation is parked in the entry rather than filed separately: a single
connection selection issues the same schema/list read two or three times.

Counts

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

Verification

format · lint · typecheck · knip · build · tests/run-core.sh (351 files) ·
tests/run-components.sh (33 groups). Browser pass on the built app: hero reads
Plus 21 wire-compatible engines and names Garnet and Apache Doris but not QuestDB; the
PostgreSQL hint names CockroachDB and not QuestDB; the Redis hint names Garnet with no tier
suffix; the MySQL hint names Apache Doris.

[cevheri]

Rebased onto origin/main after #503 merged (208011fb), and one docs edit was added rather than carried over: main also gained #505, which made docs/providers/redis.md name its three relatives explicitly. Garnet is the fourth, so that section is now Valkey, DragonflyDB, KeyDB and Garnet and three of its paragraphs say what Garnet does differently — the unread garnet_version, the two absent INFO fields behind the 0 B size and the 100% cache ratio, and the fact that CLIENT LIST itself answers correctly so the divergence is in the counters above it, not the session row. No conflict produced this; nothing I touched overlapped, which is exactly why it needed looking for.

[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