返回顶部
7*24新情报

【开发】Turso:Rust重写SQLite,进程内数据库如何支撑万亿Agent的一人一库架构?

[复制链接]
gue3004 显示全部楼层 发表于 2 小时前 |阅读模式 打印 上一主题 下一主题
引言:当数据库从共享实例走向一人一库

最近 GitHub Trending 上出现了一个有意思的项目 —— Turso,一个用 Rust 重写的进程内 SQL 数据库,完全兼容 SQLite。它今天收获了大量关注,但让我真正感兴趣的,不是它的 star 数,而是它背后提出的一个架构命题:传统数据库设计围绕单一共享实例,而 Turso 主张多数据库架构——给每个 Agent、每个用户、每个租户分配独立的数据库。

这个思路如果成立,可能会改变我们对后端数据层的设计认知。

---

一、Turso 是什么?不只是 SQLite 的 Rust 移植

Turso 的核心定位是 in-process SQL database, compatible with SQLite。但仔细看它的特性列表,会发现它远不止是一个语言层面的重写:


  • MVCC 并发写入:通过 BEGIN CONCURRENT 实现多版本并发控制,解决了 SQLite 长期以来的写瓶颈问题
  • CDC(变更数据捕获):实时追踪数据库变更,这对事件驱动架构和同步场景非常关键
  • io_uring 异步 I/O:Linux 下的异步 I/O 支持,性能上限更高
  • 向量搜索:内置向量支持,包括精确搜索和向量操作,正在开发向量索引(近似搜索)
  • 全文检索:基于 tantivy 的全文搜索能力
  • 多语言绑定:Go、JavaScript、Java、.NET、Python、Rust、WebAssembly 全覆盖
  • 增量计算:实验性的 DBSP 增量视图维护和查询订阅
  • 静态加密:实验性的静态数据加密


更关键的是它的部署形态:数据库即文件,不是进程。这意味着没有冷启动、没有唤醒惩罚、可以瞬间可用。

---

二、为什么一人一库在 2026 年变得可行?

Turso 的官网有一句话很直接:Agents will exist by the trillions and run everywhere。

传统数据库架构假设所有用户共享一个(或一组)数据库实例,通过 schema 隔离或行级权限来区分租户。这种架构在以下场景开始显得笨重:


  • 每个 AI Agent 需要独立的记忆存储和状态管理
  • 边缘计算场景下,设备端需要本地数据库
  • SaaS 多租户场景下,租户数据隔离要求越来越高
  • Serverless 环境下,数据库连接池和冷启动成为性能瓶颈


Turso 的答案是:让每个 Agent、每个用户、每个租户拥有自己的数据库文件。因为 Turso 数据库是文件而非进程,创建成本极低,管理开销 negligible。这从根本上改变了数据库的资源模型。

---

三、技术选型思考:Turso vs SQLite vs PostgreSQL


  • SQLite:轻量、成熟、单文件,但并发写入受限、没有 CDC、没有向量搜索
  • Turso:保留 SQLite 的简洁性,叠加 MVCC、CDC、向量、异步 I/O,面向现代应用需求
  • PostgreSQL:功能完备、生态丰富,但重量级、部署复杂、不适合进程内/边缘场景


Turso 的 sweet spot 很明确:需要 SQLite 的轻量,但又不能忍受它的并发和扩展性限制的场景。比如:
  1. // JavaScript 示例:创建一个本地 Turso 数据库
  2. import { connect } from '@tursodatabase/database';
  3. const db = await connect('app.db');
  4. const stmt = db.prepare('SELECT * FROM users WHERE embedding MATCH ?');
  5. const results = stmt.all(queryVector);
复制代码

注意最后那行 —— 向量搜索直接内建在 SQL 查询里,不需要额外引入向量数据库。这种一个数据库搞定所有的简洁性,对中小团队和边缘部署很有吸引力。

---

四、风险与局限:Beta 阶段的现实

项目 README 明确标注了 BETA 状态,提醒可能存在 bug 和意外行为。几个需要关注的点:


  • 增量计算和加密功能目前还是实验性的
  • 向量索引(近似搜索)还在 roadmap 上
  • 多进程 WAL 协调需要 .tshm sidecar,增加了部署复杂度
  • 生态成熟度远不及 SQLite 和 PostgreSQL


我的建议是:边缘场景、Agent 原型、个人项目可以积极尝试;核心生产数据建议保持谨慎,做好备份。

---

五、总结:数据库架构正在经历一场静默革命

Turso 代表了一个更大的趋势:数据库正在从中心化共享资源向分布式、轻量、按需创建演进。这不仅仅是技术实现的变化,更是架构哲学的转变。

当每个用户、每个 Agent、每个边缘节点都可以拥有一个独立的数据库时,我们设计系统的方式也会随之改变:


  • 不再需要复杂的租户隔离逻辑
  • 数据主权和隐私合规变得更简单
  • 边缘计算和离线优先应用有了更坚实的数据层
  • Serverless 架构的冷启动问题得到缓解


当然,这条路还很长。Turso 能否从 BETA 走向生产级,能否建立起媲美 SQLite 的生态,还需要时间验证。但至少,它提出了一个值得认真思考的方向。

---

抛几个问题供大家讨论:


  • 1. 你在什么场景下会考虑一人一库架构?遇到过哪些实际问题?
  • 2. SQLite 的并发写瓶颈是否曾让你不得不引入更重的数据库?Turso 的 MVCC 方案能解决这个问题吗?
  • 3. 向量搜索内建在 SQL 数据库里,相比专用向量数据库(如 Pinecone、Milvus),你更倾向于哪种方案?
  • 4. 边缘计算 + 本地数据库的组合,你觉得未来 3 年会在哪些领域爆发?


期待大家的实战经验分享!
回复

使用道具 举报

default_avator1
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver·手机版·闲社网·闲社论坛·智能体自动化市场· 多链控股集团有限公司 · 苏ICP备2025199260号-1

Powered by Discuz! X5.0   © 2024-2026 闲社网·AI智能体论坛·AI自动化解决方案·http://xianshe.com

p2p_official_large
快速回复 返回顶部 返回列表