方向判断我同意——对象存储上做图遍历，瓶颈确实在索引形态而不是在介质。但两个夸点要收回来，而且最值钱的那张表原帖没引。
一：页面是活的，数据不是
原帖夸「benchmark 页面是 live 的，不是论文里的静态图」。页面确实在前端跑了，但它的数据源 data/minio.json 里 captured 字段写的是 2026-08-12——到今天七周。图会动，快照不会。夸团队持续维护之前，先看这个日期。
二：同一份 JSON 里两套并发实验没对过账
matrix那一组：读吞吐在 8 个 worker 后基本见顶。multi_hop_rows/ 1 跳从 1 个 worker 的 1105 到 8 个的 3449，到 32 个反而落到 3338——按线性折算只有 9.4% 的并行效率。concurrency那一组：fanout=50 / 1 跳，报的是 32 个 worker 15843 qps，对 1 个 worker 的 2106 是 7.5 倍。
三：写那一侧，才是这篇里最硬的一条
原帖完全没提写入。原始数据里 create 的每秒操作数，在并发 1 / 4 / 8 / 32 上是：
- 227.5 / 228.3 / 225.6 / 224.1 ops
一句话：加 data node 换得来查询吞吐，换不来写入吞吐。原帖讲的「按需起 Data Node、不用就关掉」这套弹性，只成立于读侧；写密集的图（实时风控、CDC 同步、在线反欺诈）根本不该按这个逻辑选型。
四：每跳的代价不在中位数上，在尾巴上
fanout=50 时，hot_p50 从 1 跳的 451.9 微秒涨到 20 跳的 609.5 微秒（三成），而 hot_p95 从 651 涨到 3193（近五倍）。
原帖说「预封装索引把随机访问变成顺序读」——中位数确实压住了，这个功劳要记。但如果你的 SLA 是按 p95 定的，「跳数不敏感」这句话就不成立：20 跳的尾部延迟是 1 跳的 4.9 倍。
五：这是个「对象存储就在隔壁」的基准
机器是一台 15 核的 Apple Silicon，存储是同一台机器上 Docker 里的 MinIO。对象存储的网络往返基本没进这个数。结论往真云上搬之前，得先把这一项加回去——恰恰是它在真实部署里最贵。
下一根钉子
盯着那个写入曲线：把 data node 从 1 加到 N，写入 ops 从哪个 N 开始真的往上走。如果那个数是 0，那 HydraDB 的存算分离就只对只读图有意义，「图数据库也能存算分离」这个命题要加一句限定——分离的是读，不是写。