#Runtime Graph Database Evaluation

The current decision is do not adopt a runtime graph database. The measured rationale and reopening gates are authoritative in ADR 0003.

#Scope

This evaluation covers operational application data only. It is separate from Graphify repository analysis, which documents a developer tool that produces a repository/source-code knowledge graph.

The candidate traversal is:

Client
  -> Project
     -> Ticket
        -> Calendar event
     -> Deadline

The repository schema represents every edge above with an indexed foreign key. The proof uses a bounded CTE over those existing table/column names. It does not introduce production DDL, a core service, or an endpoint.

#Reproduce The Evidence

Both commands use an isolated in-memory SQLite database and cannot access a runtime tenant database:

vendor/bin/phpunit --bootstrap tests/Support/isolated-tenant-bootstrap.php tests/Unit/Search/Graph
php tools/benchmarks/graph-sql-impact.php

The benchmark seeds 15,200 records across five relationship tables, varies the client over 250 traversals, and reports p50/p95/max rather than a single sample. The accepted 2026-08-20 run returned 75 rows per client at 0.480 ms p50, 0.571 ms p95, and 2.152 ms maximum.

Machine, database engine, and load affect absolute timing. This benchmark is an architecture comparison fixture, not a production capacity claim. A future proposal must repeat it with production-shaped cardinality and the tenant's supported SQL engine.

#Decision Matrix

No Neo4j container, extension, Composer dependency, credentials, contracts, or tenant configuration should be added on the strength of the current use case.

#Discovery evidence — 2026-09-13

Discovery adds a module-owned SQL graph for approved need/feature/product, topic/article and content/document relationships. Four synthetic relevance cases improve nDCG@10 from 0.70973 with documents/vectors to 0.94620 with the reviewed graph. That contribution does not establish acceptable serving cost.

The isolated scale fixture has 10,000 content records, 100,000 real Qdrant points and 200,000 SQL edges. The initial graph/retrieval p95 was 1,262.46/4,769.42 ms, exceeding the 100 ms / one-second targets. Query-plan inspection found corpus-wide scans for concept frontiers, ordered adjacency and immutable-point generation lookup. Migration Version20260913234500 and bounded exact-term branches remove those scans while preserving tenant/locale predicates, global identity order and current evidence checks. UNION also deduplicates collation-equivalent terms on MySQL.

After remediation, the repeated fixture records graph p50/p95 of 20.48/31.03 ms and full retrieval p50/p95 of 314.46/367.09 ms, excluding embedding. All 50 traversals return the expected product. MySQL 8.4.11 separately verifies the SQL query results, accent-insensitive term deduplication, concurrent human review and data-preserving index down/up; it is not a MySQL throughput measurement.

The repeated vector IO takes 387.06 s, graph seed 706.15 s, direct repair 38.98 ms and ten-point cleanup 15.36 ms. Graph seeding overlapped separate chat diagnostics on the host and is not a clean ingestion before/after comparison. SQL uses 636,645,376 allocated bytes; Qdrant collection apparent size is 781,616,055 bytes. These are in-memory SQLite / synthetic canonical-owner measurements with one repeated real vector, not fresh-model throughput, production-owner SQL capacity or steady-state storage estimates. Methods and both baselines live in modules/Discovery/src/EVALUATION.Discovery.md and tools/benchmarks/evidence/discovery-scale-remediation-20260913.json.

Keep the module-owned SQL graph. Its measured warm fixture serving costs now meet the starting budgets; no second stable graph consumer, supported-engine capacity comparison or complete external graph cost/recovery evidence satisfies ADR 0003's reopening conditions. No external graph engine or core graph promotion follows from this result.