【Rust日报】2026-10-20 一张图列出 20 个 Rust 数据库项目
内容提要
本期汇总四则Rust动态：社区图列出20个Rust数据库项目，评论认为Postgres、SQLite仍是多数场景首选；Rust编译器年度盘点称下一代trait solver、Polonius、并行前端等长期投入开始见效；Ante语言用place实现零成本循环可变；mbrotli压缩库将并行任务交回调用方调度。
延伸解读
Rust 数据库生态图：选项多，但选型仍看场景
图中列出 20 个 Rust 数据库项目，但评论普遍认为 Postgres 和 SQLite 仍是多数场景的起点。有评论指出，这些项目多面向 OLAP 或向量检索等特定场景，与 Postgres 并非同类竞争。对读者而言，这张图更适合当作生态概览，而非选型清单；实际决策仍需结合可靠性、运维成本和具体负载来判断。
编译器年度盘点：长期投入进入收获期
文章将下一代 trait solver、Polonius、并行前端等列为长期投入，并称 2026 年多项工作同时走到后期阶段。其中 LLVM 23 的性能变化被明确描述为正向，而 MIR move elimination 等优化尚在推进。读者可关注这些项目对编译时间、async Rust 限制和代码通过率的影响，但部分目标（如 Polonius 对内部引用的作用）时间仍不确定。
Ante 的 place 设计：静态检查循环可变，但非全新思路
Ante 用 place 替代 lifetime 来跟踪引用失效，实现零成本循环可变，示例中无需 GhostToken 或运行时检查。不过评论区指出 Polonius 已使用接近 place 的模型，作者也承认原先判断有误。这说明该设计的主要价值在于零成本循环可变的具体实现，而非 place 概念本身的首创性。读者应区分这两点。
mbrotli 的调度取舍：把线程控制权交给调用方
mbrotli 不自行起线程，而是返回任务队列，由调用方调度执行。作者明确提醒，调度器设计不佳时容易死锁，调用方必须保证任务被执行。这种设计适合已有线程池的程序，可避免与 rayon 或 tokio 的线程管理冲突；但若调用方缺乏调度能力，则可能增加使用负担。评论建议提供兼容 rayon 的迭代器，让并行与否由调用方决定。
Q&A
那张列出20个Rust数据库项目的图里都有哪些项目？
图中20个项目包括：上排 Apache DataFusion、Neon、RisingWave、GreptimeDB、SurrealDB；左侧 Polars、ParadeDB、HelixDB、LanceDB、Qdrant；右侧 slatedb、Databend、turbopuffer、Turso、TiKV；下排 SmithDB、HydraDB、readyset、SedonaDB、influxdb。
社区评论对Rust数据库生态和Postgres、SQLite的关系怎么看？
评论认为多数场景下Postgres仍是首选，可靠性最重要；SQLite适合本地连接和少运维；图中项目多面向OLAP或向量检索等特定场景，与Postgres类别不同，并非直接竞争。
Rust编译器2026年有哪些长期投入开始见效？
下一代trait solver重写类型系统近10年，修复健全性错误并解开async Rust和impl Trait限制；Polonius借用检查能让更多代码通过编译；并行前端接近稳定；LLVM 23性能明确正向；MIR move elimination减少拷贝；polymorphization实验推进；cargo check和build共享产物使target目录缩小5%-30%。
Ante语言如何用place实现零成本循环可变？
Ante用place代替lifetime，place是引用可能借自的一组具体位置。对a!的引用在修改a时失效。循环可变用带place参数的Rc 'p t，Rc.get返回的内部引用同时带上外层不稳定place和共享place，检查全静态，无需GhostToken或运行时检查，且不再需要克隆Rc。
mbrotli压缩库为什么把并行任务交回调用方？
mbrotli知道如何拆分压缩任务，但执行交给调用方：ParallelCompressor::writer返回写入端和任务队列，库自身不起线程。这样对已有线程池（如rayon或tokio）的程序更合适，避免库再起一套线程造成冲突；但调用方需保证任务被执行，调度不佳易死锁。
Ante的place设计与Polonius有什么关系？
评论中有人问Ante的新部分是什么，因为Polonius已用接近place的模型。作者回复原先以为把lifetime做成place是Polonius之外的工作，但回顾Polonius文章后认为该判断不对；文章主要贡献仍是零成本循环可变。
