2025 年 5 月 27 日，在 re:Invent 大会上宣布了 Aurora DSQL，作者与两位高级首席工程师（Niko Matsakis 和 Marc Bowes）合作深入探讨其发展历程。

• AWS 专用数据库的简要时间线：自 AWS 早期，客户需求增长，推出了多种专用数据库服务，如 DynamoDB、Redshift、Aurora 等，以应对不同场景的需求，且随着新计算模式的出现而不断发展，背后是团队的不断实验和协作。但仍面临如何构建无需基础设施管理且可自动扩展的关系数据库的挑战，这促使了 Aurora DSQL 的诞生。
• Aurora DSQL：其设计目标是将数据库分解为小模块，各组件遵循 Unix 理念，共同提供数据库的各种功能。2021 年已解决读的问题，未解决写的水平扩展，传统的两阶段提交（2PC）方案在跨多个日志更新时复杂且易出现操作复杂性，DSQL 需新方法。
• 扩展日志层：决定将整个提交写入单个日志以解决 ACID 的原子性和持久性要求，虽简化了写路径但使读路径更复杂，需要 Crossbar 分离读写路径，各层需提供高扇出，但现实中存在缓冲需求和垃圾回收问题，模拟测试显示系统在扩展时性能受影响严重。
• 短期痛苦，长期收益：面临垃圾回收、吞吐量和停滞等问题，选择 Rust 语言，因其具有可预测性能、内存安全且零成本抽象等优势，从简单的 Adjudicator 组件开始，代码速度大幅提升，从而决定将数据平面用 Rust 重写，控制平面仍用 Kotlin。
• 修复一个硬问题比避免内存安全漏洞更简单：决定在 PostgreSQL 基础上用 Rust 构建数据平面，虽可通过扩展点修改行为，但 C 代码易出现内存安全问题，而 Rust 可避免，最终决定用 Rust 编写扩展，通过创建抽象来确保内存安全。
• 关于控制平面：开始时选择 Kotlin 写控制平面，虽孤立时工作良好，但集成时出现问题，如不同语言导致代码差异、测试平台不同等，后因 Rust 发展及团队响应等因素，决定将控制平面也用 Rust 重写。
• 不仅仅是写代码：Rust 适合 DSQL，能避免系统核心部分的尾延迟，与 C 代码库集成灵活，提高控制平面的生产力，甚至用于内部操作网页，起初认为 Rust 生产率低是错觉，关键是根据具体需求做出选择并支持团队学习和决策。
  推荐阅读 Marc Brooker 关于 DSQL 的系列文章。