Back

认识 Turso:基于 Rust 的 SQLite 进化版

OpenReplay Team OpenReplay Team

Apr 12, 2026 · 2 min read

认识 Turso:基于 Rust 的 SQLite 进化版

如果你曾经使用 SQLite 构建过应用,你一定了解它的优势:零配置、单文件、快速读取,并且可以在任何地方运行。但你可能也遇到过它的瓶颈——不支持并发写入、同步 API 与异步运行时冲突,以及缺乏清晰的边缘或分布式部署路径。

这正是 Turso 旨在填补的空白。

核心要点

  • Turso 生态系统有两大支柱:libSQL(一个生产就绪的基于 C 的 SQLite 分支)和 Turso Database(一个处于 beta 阶段的全新 Rust 重写版本,原代号”Limbo”)
  • Rust 重写版本带来了内存安全、异步优先的 API、原生向量搜索以及基于 MVCC 的并发写入——这些能力很难在 SQLite 的 C 代码库中改造实现
  • libSQL 和 Turso Cloud 支持诸如”每用户一个数据库”配合嵌入式副本等模式,使其成为当今边缘计算、无服务器和多租户架构的实用选择
  • Rust 重写版本尚未达到生产就绪状态,但它标志着该生态系统的长期发展方向

Turso Database 到底是什么?

Turso 不是单一的产品,而是一个围绕扩展 SQLite 以适应现代应用架构而构建的生态系统。要清楚地理解它,你需要了解两个相关但不同的技术:

libSQL 是 SQLite 的一个分支——用 C 编写,目前已达到生产就绪状态,是 Turso Cloud 的基础。它增加了复制、嵌入式副本和基于 HTTP 的访问功能,使得在边缘运行 SQLite 风格的数据库并与远程主库同步成为可能。如果你现在正在使用 Turso Cloud,你使用的就是 libSQL。

Turso Database(原代号”Limbo”)是从零开始用 Rust 完全重写的 SQLite。它目前处于 beta 阶段。目标是用 Rust 全新实现 SQLite 的文件格式和 SQL 引擎,从一开始就内置现代化能力——而不是后期添加。

这两个项目共享名称和使命,但它们处于不同的成熟阶段。libSQL 是目前支撑生产部署的版本,而 Rust 重写版本则是生态系统的未来方向。

为什么要用 Rust 重写 SQLite?

SQLite 是用 C 编写的,这使得安全地扩展它变得困难。它的测试套件是闭源的,因此外部贡献者无法像核心团队那样有信心地验证更改。而且该项目根本不接受外部贡献,这意味着改进进展缓慢。

Rust 重写直接解决了这些问题:

  • 无需垃圾回收器的内存安全 — Rust 的借用检查器消除了 C 代码库中常见的整类 bug
  • 异步优先的 API — 与 SQLite 的同步接口不同,Turso 的 API 设计为在异步运行时和浏览器环境中自然工作
  • 原生向量搜索 — 为 AI 和 ML 工作负载内置,无需外部扩展
  • 用于并发写入的 MVCC — SQLite 的写锁定是一个已知瓶颈,Turso 的架构从根本上针对这一问题
  • 开放的贡献模式 — 该项目已经吸引了不断增长的贡献者社区

以下是 Rust API 中基本查询的示例:

use limbo_driver::Builder;

#[tokio::main]
async fn main() -> Result<(), anyhow::Error> {
    let db = Builder::new_local("test.db").build().await?;
    let conn = db.connect()?;
    let rows = conn.query("SELECT * FROM users", ()).await?;
    Ok(())
}

注意: Turso Database (Limbo) API 仍在演进中,确切的 crate 名称和方法签名可能在稳定版本发布前发生变化。请始终查看官方仓库获取最新的使用示例。

异步接口是一个重要的转变。这意味着 Turso 设计为可以在阻塞 I/O 不可行的环境中运行,包括边缘运行时和 WebAssembly 目标。

libSQL vs SQLite:对 Web 开发者有什么不同?

对于前端和全栈开发者来说,当今 Turso 生态系统中最实用的部分是 libSQL 和 Turso Cloud。它支持的一个常见模式如下:

  • 每个用户或租户可以拥有自己的 SQLite 风格数据库
  • 该数据库作为嵌入式副本在靠近用户的位置运行——在边缘或应用本地
  • 读取快速且本地化,写入同步回远程主库

这种”每用户一个数据库”的模式非常适合无服务器环境、多租户 SaaS 应用,以及需要隔离、轻量级存储而无需为每个会话启动完整 Postgres 实例的 AI 代理。

实际应用已经在发生。Spice.ai 将 Turso 与 DuckDB 一起用作加速器,并报告在某些查询模式下相比其 SQLite 实现有性能提升。

Turso 当前的定位

场景推荐方案
需要 SQLite 的边缘或无服务器应用libSQL + Turso Cloud(生产就绪)
具有远程同步的本地优先应用libSQL 嵌入式副本
评估 Rust 重写版本Turso Database beta(尚未生产就绪)
具有隔离存储的 AI 代理libSQL 每代理数据库模式

Rust 重写版本仍在演进中,尚不能作为生产环境中 SQLite 的直接替代品。

结论

Turso 代表了 SQLite 生态系统的真正进化,而不仅仅是一个分支。libSQL 解决了当今的分布式 SQLite 问题。Rust 重写正在为下一步构建基础:一个完全开放、异步原生、边缘就绪的数据库,将 SQLite 的简洁性带入现代基础设施。

如果你已经在使用 SQLite 并想知道它的未来方向,Turso 是目前最具体的答案之一。对于生产工作负载,从 libSQL 和 Turso Cloud 开始,并在 Rust 重写版本走向稳定的过程中保持关注。

常见问题

Rust 重写版本不行。它仍处于 beta 阶段,尚未打算成为 SQLite 的生产就绪直接替代品。但是,libSQL 已经生产就绪并且与 SQLite 基本兼容。对于大多数应用,libSQL 配合 Turso Cloud 是当今推荐的起点。

libSQL 是基于 C 的 SQLite 分支,增加了复制、嵌入式副本和 HTTP 访问功能。它是当今 Turso Cloud 的支撑。Turso Database(原代号 Limbo)是用 Rust 全新重写的独立版本。它目前处于 beta 阶段,目标是作为长期替代方案实现异步原生、内存安全的操作。

SQLite 使用单写入者锁,这限制了写入并发性。Rust 重写版本旨在支持基于 MVCC 的并发写入,但该功能仍在开发中。libSQL 继承了 SQLite 的写入模型,因此生产环境的 Turso 部署尚不支持并发写入。

可以。Rust 重写版本专为 WebAssembly 和边缘运行时等不允许阻塞 IO 的环境设计。libSQL 也通过 Turso Cloud 的嵌入式副本模型支持边缘部署,该模型保持读取本地化并将写入同步到远程主库。

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.

OpenReplay

More articles from OpenReplay Blog