第 1 章 · Turso 与 libSQL 架构

1.1 SQLite 是什么

SQLite 是一个嵌入式关系数据库——不是一个独立进程，而是一个 C 语言库，把整张数据库存成一个单文件（扩展名通常 .db/.sqlite）。它是世界上部署量最大的数据库：iOS/Android 每个 App、Chrome/Firefox、飞机航电系统里都有它。

单文件: 整个数据库、所有表、所有索引都躺在一个二进制文件里。可以 scp、git-lfs、压缩、加密。
零配置: 无需守护进程、无需 systemd、无需用户管理。打开文件就能用。
ACID 完整事务: 默认 rollback journal 或 WAL 模式提供原子提交与崩溃恢复。
极快的读: 无进程间通信、无网络，读一行几微秒。适合读多写少的工作负载（博客、文档站、分析视图）。
写有瓶颈: WAL 模式下可并发多读，但写仍是单点（全库一把锁）。高并发写场景需要分库或专用 RDBMS。

1.2 SQLite 的局限

SQLite 太适合"一个进程、一台机器"，但当代应用常常需要：

多台 Web 节点读写同一份数据
主节点挂了有备机
客户端延迟要低 < 50ms，但服务可能在另一洲
备份、回滚、时间旅行

传统 SQLite 没有这些能力——它是个库，不是服务。人们用 Litestream、rqlite 等工具补救，但都不够优雅。

1.3 libSQL：Turso 的 fork

libSQL 是 Turso 团队 2022 年从 SQLite 3.44 分出来的一个开源 fork。它并不打算"替代"SQLite，而是在保留 100% SQL 兼容的前提下，补上分布式时代需要的功能：

WebSocket / HTTP 协议：SQLite 本身没有线协议，libSQL 定义了一套 Hrana 协议，可以远程调用
嵌入式副本：客户端维护一份本地 SQLite 文件，通过 WAL 同步到远端
向量搜索：原生 F32_BLOB + vector_top_k 函数
自定义 WASM 函数：可以在数据库里跑 WASM UDF
自由软件协议：MIT，商用友好

libSQL 不是 fork SQLite 主干

SQLite 官方只接受邮件列表补丁、不接 PR。libSQL 用 GitHub 流程开发，核心基于 SQLite 但会积极合并新特性（如 STRICT 表）。两者的 .db 文件格式向后兼容：旧 SQLite 可以读 libSQL 写的，只要没用到 libSQL 独有扩展。

1.4 Turso：libSQL 的云服务

Turso 把 libSQL 包装成一个全球服务：

你在 Turso 后台创建一个 "database"——实际是一个 libSQL 实例
Turso 在 Fly.io 基础设施上为它挑选一个 primary 区域（如 ams、fra、nrt）
你可以一条命令加入更多 replica 区域——异步复制 WAL 日志
客户端连接时，读路由到最近副本、写转发到 primary
也可以不走服务：把数据库 嵌入到你的应用进程（第 4 章）

1.5 primary-replica 模型详解

                   ┌────────────────┐
                   │  Primary (ams)  │
                   │   can WRITE     │
                   └────────┬────────┘
           WAL frames async │ replicate
         ┌──────────────────┼──────────────────┐
         ▼                  ▼                  ▼
  ┌─────────────┐   ┌─────────────┐    ┌─────────────┐
  │ Replica fra │   │ Replica nrt │    │ Replica gru │
  │  read-only  │   │  read-only  │    │  read-only  │
  └─────────────┘   └─────────────┘    └─────────────┘

副本之间的复制是异步的——写提交到 primary 后立即返回给用户，再慢慢推给各副本。带来两个重要后果：

读副本可能看不到最新写（副本延迟通常几十 ms 到数百 ms）
"读自己写"（read your writes）需要特殊处理——第 6 章讲

1.6 存储层：SQLite 文件 + WAL

每个 Turso 数据库在 primary 节点上就是一个 libSQL .db 文件 + WAL（write-ahead log）日志。WAL 是复制的单位：primary 写入新 frame、replica 拉取并 apply。

这与 Postgres 流复制类似，但 SQLite 文件格式简单、WAL frame 结构简单，libSQL 实现只有几千行 Rust——也是它能稳定运行的原因之一。

1.7 Turso vs Neon / D1 / PlanetScale

产品	底层	区域复制	嵌入式副本	向量	HTTP API
Turso	libSQL（SQLite）	✅ 40+	✅	✅ 原生	✅
Neon	Postgres	❌（单区域）	❌	pgvector 扩展	✅
Cloudflare D1	SQLite	邻近只读副本	❌	Vectorize 单独服务	✅
PlanetScale	MySQL	✅（Vitess）	❌	❌	✅
Fly.io LiteFS	SQLite	✅	—	❌	❌

1.8 什么时候该选 Turso

强烈匹配：

读多写少的 Edge 应用（博客、文档、SaaS dashboard）
多租户 SaaS 每个客户独立数据库
需要本地/离线读的 Mobile/Desktop 应用（嵌入式副本）
小型 RAG 项目（向量 + SQL 元数据在同一张表）

不推荐：

高并发写（单 primary 写瓶颈）
需要 Postgres 特有功能：JSONB 查询、CTE 递归高级用法、数组类型、PostGIS
跨库复杂 JOIN / 全局二级索引需求

小结

Turso = libSQL（SQLite fork）+ 全球多副本基础设施 + 嵌入式副本 + 向量扩展。它在"SQLite 简单"与"分布式可用"之间找到了平衡点，尤其适合 Edge + 读多写少场景。下一章装 CLI，把第一个数据库创起来。