一个叫 TurboKV 的 Rust 嵌入式键值存储，最近在 GitHub 上贴出了一份很敢写的跑分表：顺序批量写入吞吐是同类引擎 fjall 的 4.44 倍，随机单条写入也领先近一倍。这类嵌入式 KV 库通常安静地活在别的项目底层，很少有人会为它专门写一篇报道——但这份跑分表的写法，值得拆开看一眼。
TurboKV 当前是 0.6 版本，定位是异步、支持原子批量写入和有序范围扫描的嵌入式数据库，主打三档可调的持久化策略：fast（不写日志，最快但进程崩溃就丢数据）、durable（默认档，写日志但不逐次同步）、paranoid（每次写入都强制同步落盘，最慢但最稳）。README 本身没有给出任何性能数字，只讲了这套配置逻辑和 64MiB 默认内存表大小。跑分是仓库里单独放的一份对照材料。
跑赢fjall的4.44倍,算的是哪一段
官方测试用了 20 万条 20 字节的 key、400 字节的 value，在 Apple M4 上跑三次取平均。顺序单 key 写入达到 1,407,678 次/秒，是 fjall 的 485,252 次/秒的 2.9 倍；100 条一批的批量写入达到 2,272,259 次/秒，是 fjall 的 511,600 次/秒的 4.44 倍。延迟数据也很漂亮：顺序写 p50 只要 459 纳秒，100 键批量写 p99 也就 89 微秒。
问题在于，这些数字测的是"确认吞吐"——WAL 已经追加、调用方拿到成功返回，但数据未必已经物理落到磁盘。这恰好对应默认档 durable() 的语义：保证进程崩溃能恢复，不保证断电不丢数据。
同一份 0.6.0 测试数据显示，顺序写的确认吞吐在真正走完 flush 和 compaction 之后，会降到大约 29 万次/秒——只有头条数字的五分之一左右。这个落差，README 的三档持久化说明里完全没有提到，跑分表里也只字未提，得翻到旁边的原始 JSON 文件才能看到。
跑分表赢的是确认边界,不是磁盘边界。
那些被拿掉的变量
除了确认吞吐这层，测试条件本身也做了不少减法：压缩全程禁用、block cache 关闭、只用单个调用方，规模停在 20 万 key。这些设置都偏向让 TurboKV 在没有并发竞争、没有压缩解码开销的小规模场景里跑出最好成绩，跟真实生产环境常见的多线程并发写入、数据集远超内存、需要压缩省磁盘的情况有距离。
- 风险.写放大数据也提示了隐藏成本——首次顺序/随机填充约 2.14 倍，覆写场景写放大升到 3.19 倍，说明持续更新的工作负载代价比首次灌数据更高，这层开销跑分表的头条数字里看不出来。
更值得留意的是版本错位。仓库里唯一一份 compaction 和磁盘放大的详细数据，来自旧版本 0.5.0：约 76.7 万次活跃 key 操作/秒，固定 compaction 延迟 260.9 微秒，磁盘放大约 6.48 倍。这份材料没有随 0.6.0 更新，头条吞吐用的是新版本数字，compaction 代价用的是旧版本数字，两者拼不成一张完整的当前性能画像。
放进sled/redb/fjall的坐标系里看
Rust 嵌入式 KV 存储这个圈子并不新：sled 长期停留在"实验性"标签下、redb 靠 copy-on-write B-tree 换来强事务语义、fjall 主打 LSM 结构的写密集场景，再往上还有绑定 C++ 的 RocksDB，成熟度和调优空间最高。这些引擎的共同点是，都经过多年生产环境的独立验证和第三方复现测试。
TurboKV 目前只有仓库自己发布的一份跑分，没有同等量级的外部评测，也缺乏长期运行案例佐证它的崩溃恢复和长时间 compaction 行为。对正在选型的后端工程师来说，如果只是做缓存层或可重建数据、能接受 fast() 档的风险，TurboKV 的写吞吐确实有吸引力；但涉及强一致事务、大规模数据集、需要经过实战检验的运维工具链，redb 或 RocksDB 仍是更稳的选择。
接下来值得盯的，是 TurboKV 会不会补一份开启压缩、开启 block cache、多线程并发下的跑分，以及 0.5.0 遗留的 6.48 倍磁盘放大问题在新版本里是否已经改善——这两块空白补上之前，这份 4.44 倍的成绩单更适合当作参考，而不是选型依据。