分布式 SQLite / libSQL——全球 40+ 区域副本、嵌入式副本本地微秒读、原生向量搜索，AI 时代的 Edge 数据库
过去十年，数据库选型的默认答案是 Postgres/MySQL——中心化、通过连接池访问。但 Edge 时代让这套模型很痛苦：函数在北京冷启动，要连美东数据库，一次查询 300ms 延迟基本就废了。Neon/Planetscale 推 HTTP API 把"每次 RTT"从 TCP 握手简化成单次 HTTP，但跨洋的 200ms 物理延迟是光速问题无法消除。
Turso 从根上换思路：把数据库搬到离用户最近的地方。基于 SQLite（单文件、读极快）+ libSQL（Turso fork 的协议兼容版本），它做了两件事：① Edge 多区域副本——全球 40+ 节点各持一份数据，写去 primary、读就近副本；② 嵌入式副本（Embedded Replicas）——直接把 SQLite 文件同步到你的应用进程里，读延迟 < 1ms，不再需要任何网络。
本教程 10 章从零到精通：Turso 架构、CLI 与数据库管理、libSQL SDK（JS/Rust/Python）、嵌入式副本、与 Drizzle/Prisma 集成、事务与 ACID、向量搜索、迁移、备份、生产运维清单。
六大特性让 Turso 成为 2026 年的 Edge 数据库首选
一条命令添加区域副本，读写就近路由，跨洋查询从 200ms 降到 20ms。
SQLite 文件直接同步到应用进程内——读取 < 1ms，适合 Mobile/Electron。
100% SQL 兼容 SQLite，迁移几乎零成本；驱动完全开源，可自建。
F32_BLOB + vector_top_k，不必叠加 pgvector/Pinecone 就能做 RAG。
免费档 500 个数据库 / 9GB 存储 / 10亿行读，中型 SaaS 足够用。
Cloudflare Workers / Vercel Edge 无 TCP 限制，libsql-client HTTP 直连。
10 章从架构到生产，覆盖 libSQL SDK / 嵌入式副本 / 向量搜索
SQLite 基础、libSQL 为什么 fork、Turso 的 primary-replica 模型、Fly.io 底层与边缘节点。
turso auth、db create/destroy/list、shell、token、locations、groups、organizations 组织账户。
@libsql/client 安装、createClient、execute/batch/transaction、Node vs Edge 驱动差异、TypeScript 类型。
Embedded Replicas 原理、syncUrl、sync() 手动同步、连续同步、冲突解决、适用场景（Mobile/Desktop）。
drizzle-orm/libsql driver、schema 定义 SQLite 类型、生成迁移、关系查询、部署 Cloudflare Workers。
BEGIN/COMMIT、read-write transaction、interactive tx、副本写延迟、读自己写 (read-your-writes)。
F32_BLOB 列、vector_top_k、libsql_vector_idx 索引、余弦距离、1536 维 embedding、用 Turso 做 RAG。
手写 SQL 迁移、drizzle-kit push/migrate、CI 自动迁移、多租户 DB-per-tenant 策略。
turso db dump、point-in-time restore、branch（从某时刻 fork 出新 DB）、灾备策略。
监控 / 配额 / 连接限制、价格模型、Turso vs Neon/D1/PlanetScale、自建 sqld 开源方案。