SQLite 复兴：从玩具到生产级——Turso、libSQL 与 Litestream 如何改写数据库选型的游戏规则

2026年，SQLite 正在经历一场静悄悄的革命。曾经被视作「原型阶段专用」的嵌入式数据库，正在以一种前所未有的方式重返生产环境。本文深度拆解这场复兴背后的技术栈：libSQL 的网络化改造、Turso 的边缘分布式架构、Litestream 的实时流复制，以及 WAL2 模式下的性能飞跃——附完整代码示例与生产部署指南。

一、引言：一个被低估了二十年的数据库

如果你在 2024 年之前告诉一个资深 DBA「我打算用 SQLite 跑生产」，他大概率会觉得你在开玩笑。

SQLite 的历史可以追溯到 2000 年，由 D. Richard Hipp 一个人开发。它的设计初衷是在嵌入式设备上提供一个零配置、零依赖的 SQL 引擎。二十多年来，它被安装在每一部 iPhone、每一台 Android 设备、每一个 Chrome 浏览器里——它是全球部署量最大的数据库，没有之一。

但「部署量最大」和「最受尊重」之间隔着一条鸿沟。在后端开发者的心智模型里，SQLite 等于「开发环境」、「测试用」、「快速原型」。等到项目要上线，第一件事就是把 SQLite 换成 PostgreSQL 或 MySQL。

这个认知正在被打破。

2026 年，一波新的工具、新的架构模式、新的云服务正在同时走向成熟，它们共同补齐了 SQLite 真正的短板——网络访问、多写并发、数据复制、用户管理——同时又没有丢掉它最核心的优势：零配置、单文件、极致性能。

这不是某个单一项目的胜利，而是一场生态级别的复兴。

二、为什么我们曾经弃用 SQLite——以及这些理由为何正在失效

要理解这场复兴，首先要理解过去反对 SQLite 的理由。这些理由在当时完全合理，但到 2026 年，它们正在逐一瓦解。

2.1 「SQLite 只能单写」

这是最经典的反对理由。SQLite 使用文件锁来控制并发写入——同一时刻只能有一个写入者。在高并发写入场景下，这确实是个瓶颈。

但 2026 年的现实是：绝大多数 Web 应用根本不是高并发写入场景。

一个典型的 SaaS 应用，读写比通常是 10:1 甚至 100:1。一个内容管理系统，写入频率可能只有每秒几次。一个边缘计算 API，读取远多于写入。在这些场景下，SQLite 的单写限制根本不是问题。

更重要的是，libSQL 引入了 BEGIN CONCURRENT 机制，通过乐观并发控制实现了多写支持。这不是理论上的——它已经在生产环境中运行。

-- libSQL 的 BEGIN CONCURRENT 示例
BEGIN CONCURRENT;
INSERT INTO orders (user_id, product_id, quantity) VALUES (1001, 42, 2);
INSERT INTO order_items (order_id, sku, price) VALUES (last_insert_rowid(), 'WIDGET-A', 29.99);
UPDATE inventory SET stock = stock - 1 WHERE product_id = 42;
COMMIT;
-- 如果并发冲突，libSQL 会自动重试而非阻塞

2.2 「SQLite 不支持网络访问」

SQLite 是一个嵌入式数据库——它通过文件系统访问数据，没有客户端/服务器架构。这意味着你无法从远程机器直接连接它。

这个限制在边缘计算时代反而变成了优势。

当你的应用部署在 Cloudflare Workers、Vercel Edge Functions 或 Deno Deploy 上时，「数据库就在本地」意味着零网络延迟。不需要连接池，不需要 SSL 握手，不需要跨区域数据传输。一次读取就是一次磁盘 I/O——在 NVMe SSD 上，这通常是亚毫秒级的。

而 libSQL 通过 HTTP/WebSocket 协议暴露了网络访问能力，让你在需要远程访问时也能用上 SQLite。

2.3 「SQLite 没有复制」

数据只存在一个文件里，没有主从复制，没有故障转移。文件损坏 = 数据丢失。

Litestream 彻底解决了这个问题。

Litestream 是一个 SQLite 的持续流复制工具，它通过解析 WAL（Write-Ahead Log）文件，将每次写操作实时流式传输到 S3、GCS 或 Azure Blob Storage。恢复时间通常在秒级。

# 安装 Litestream
curl -s https://packagecloud.io/install/repositories/litestream/litestream/script.deb.sh | sudo bash
sudo apt-get install litestream

# 配置复制目标
cat > /etc/litestream.yml << 'EOF'
dbs:
  - path: /var/lib/myapp/data.db
    replicas:
      - type: s3
        bucket: myapp-backups
        path: db
        endpoint: https://s3.amazonaws.com
        access-key-id: ${AWS_ACCESS_KEY_ID}
        secret-access-key: ${AWS_SECRET_ACCESS_KEY}
        region: us-east-1
        sync-interval: 1s
        retention: 72h
EOF

# 启动 Litestream（作为 sidecar）
litestream replicate -config /etc/litestream.yml

2.4 「SQLite 的 ALTER TABLE 太弱」

早期的 SQLite 只支持 RENAME TABLE 和 ADD COLUMN，不支持 DROP COLUMN、ALTER COLUMN 等操作。这在 Schema 演进频繁的应用中是致命的。

SQLite 3.35.0（2021年）已经支持了 DROP COLUMN，3.45.0（2024年）支持了 ALTER COLUMN。 而 libSQL 进一步扩展了这些能力，包括更完善的外键约束处理和默认值修改。

-- SQLite 3.35+ 的 ALTER TABLE 能力
ALTER TABLE users DROP COLUMN legacy_field;
ALTER TABLE users ADD COLUMN avatar_url TEXT DEFAULT '';
ALTER TABLE users ALTER COLUMN username SET NOT NULL;

三、技术栈深度拆解：三大核心组件

这场 SQLite 复兴不是靠一个项目撑起来的，而是三个独立项目各司其职，共同补齐了 SQLite 的短板。

3.1 libSQL：SQLite 的开源分支与网络化改造

libSQL 由 Turso 团队（原名 ChiselStrike）开发，是 SQLite 的一个开源 fork。它在保持 100% API 兼容的基础上，增加了五个关键能力：

（1）HTTP/WebSocket 服务端模式

libSQL 可以作为一个独立的服务器进程运行，通过 HTTP 和 WebSocket 暴露 SQL 接口。这意味着你可以在任何语言、任何平台上使用 SQLite——不需要嵌入式链接，不需要特定的客户端库。

// Go 客户端连接 libSQL 服务端
package main

import (
    "database/sql"
    "fmt"
    "log"

    _ "github.com/tursodatabase/libsql-client-go/libsql"
)

func main() {
    // 通过 HTTP 连接远程 libSQL 实例
    db, err := sql.Open("libsql", "http://localhost:8080?authToken=your-token")
    if err != nil {
        log.Fatal(err)
    }
    defer db.Close()

    // 像使用本地 SQLite 一样使用远程 libSQL
    rows, err := db.Query("SELECT id, name, email FROM users WHERE active = ?", true)
    if err != nil {
        log.Fatal(err)
    }
    defer rows.Close()

    for rows.Next() {
        var id int
        var name, email string
        rows.Scan(&id, &name, &email)
        fmt.Printf("User: %d, %s, %s\n", id, name, email)
    }
}

（2）嵌入式副本（Embedded Replicas）

这是 libSQL 最杀手级的特性。你可以在应用进程内嵌入一个 SQLite 副本，同时从远程主库自动同步。读取在本地完成（亚毫秒延迟），写入通过同步通道发送到主库。

# Python 嵌入式副本示例
import libsql_experimental as libsql

# 创建嵌入式副本：本地文件 + 远程同步
conn = libsql.connect(
    "local.db",                    # 本地文件路径
    sync_url="libsql://your-db.turso.io",  # 远程主库 URL
    auth_token="your-token"         # 认证令牌
)

# 每次操作前自动同步（也可以手动控制同步频率）
conn.sync()

# 读取在本地完成，零网络延迟
cursor = conn.execute("SELECT * FROM products WHERE category = ?", ("electronics",))
products = cursor.fetchall()

# 写入自动同步到远程主库
conn.execute(
    "INSERT INTO orders (user_id, product_id, quantity) VALUES (?, ?, ?)",
    (42, 1001, 3)
)
conn.commit()

（3）向量搜索

libSQL 内置了向量搜索扩展，支持余弦相似度、欧氏距离等向量距离函数。这让 SQLite 能够直接用于 RAG（Retrieval-Augmented Generation）场景，不需要额外的向量数据库。

-- libSQL 向量搜索示例
CREATE TABLE documents (
    id INTEGER PRIMARY KEY,
    content TEXT,
    embedding FLOAT[1536]  -- OpenAI text-embedding-3-small 维度
);

-- 插入向量数据
INSERT INTO documents (content, embedding) VALUES
('Rust 是一门系统编程语言，注重安全性和性能', '[0.1, 0.2, ...]');
INSERT INTO documents (content, embedding) VALUES
('Go 语言以简洁和并发著称', '[0.3, 0.4, ...]');

-- 余弦相似度搜索
SELECT id, content,
       vector_distance_cos(embedding, '[0.1, 0.2, ...]') as distance
FROM documents
ORDER BY distance ASC
LIMIT 5;

3.2 Turso：边缘分布式 SQLite 云平台

Turso 是基于 libSQL 构建的全托管云服务。它的核心理念是：每个用户、每个租户、每个 Agent 都应该有自己的数据库实例。

这个理念在 2026 年变得尤为有意义。随着 AI Agent 的普及，每个 Agent 都需要自己的状态存储——对话历史、工具调用记录、记忆向量。用 PostgreSQL 为每个 Agent 创建一个数据库实例？成本和运维复杂度都会爆炸。但 SQLite 的单文件模型天然适合这种「海量小实例」的场景。

Turso 的架构：

┌─────────────────────────────────────────────────────┐
│                   Turso Platform                     │
│                                                      │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐       │
│  │ Primary  │───>│ Replica  │───>│ Replica  │       │
│  │ (Region) │    │ (Edge 1) │    │ (Edge 2) │       │
│  └────┬─────┘    └────┬─────┘    └────┬─────┘       │
│       │               │               │              │
│       ▼               ▼               ▼              │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐       │
│  │ 35+ Edge │    │ 35+ Edge │    │ 35+ Edge │       │
│  │ Nodes    │    │ Nodes    │    │ Nodes    │       │
│  └──────────┘    └──────────┘    └──────────┘       │
│                                                      │
│  数据自动同步到全球 35+ 边缘节点                        │
│  用户在哪里，数据库就在哪里                             │
└─────────────────────────────────────────────────────┘

Turso 的实际使用：

// Node.js 连接 Turso
import { createClient } from "@libsql/client";

const client = createClient({
  url: "libsql://your-db-name.turso.io",
  authToken: "your-auth-token",
});

// 普通查询
const result = await client.execute({
  sql: "SELECT * FROM posts WHERE author_id = ? AND published = ?",
  args: [currentUser.id, true],
});

// 批量操作（单次网络往返）
await client.batch([
  {
    sql: "INSERT INTO posts (title, content, author_id) VALUES (?, ?, ?)",
    args: ["Hello World", "My first post", currentUser.id],
  },
  {
    sql: "UPDATE user_stats SET post_count = post_count + 1 WHERE user_id = ?",
    args: [currentUser.id],
  },
]);

// 事务
await client.transaction(async (txn) => {
  await txn.execute({
    sql: "UPDATE accounts SET balance = balance - ? WHERE id = ?",
    args: [100, fromAccount],
  });
  await txn.execute({
    sql: "UPDATE accounts SET balance = balance + ? WHERE id = ?",
    args: [100, toAccount],
  });
});

3.3 Litestream：SQLite 的持续流复制

Litestream 解决的是 SQLite 最根本的可靠性问题——数据只有一份文件副本。它通过解析 SQLite 的 WAL 文件，将每次写操作实时流式传输到对象存储。

Litestream 的工作原理：

┌─────────────┐     WAL 文件      ┌─────────────┐     对象存储 API     ┌─────────────┐
│   SQLite    │ ──────────────> │  Litestream  │ ─────────────────> │  S3 / GCS   │
│  (Primary)  │    实时监听      │  (Sidecar)   │    流式写入         │  (Backup)   │
└─────────────┘                 └─────────────┘                     └─────────────┘
                                      │
                                      │ 恢复时
                                      ▼
                               ┌─────────────┐
                               │  S3 / GCS   │
                               │  (Backup)   │
                               └──────┬──────┘
                                      │ 流式恢复
                                      ▼
                               ┌─────────────┐
                               │   SQLite    │
                               │ (Restored)  │
                               └─────────────┘

完整生产部署示例：

# docker-compose.yml - SQLite + Litestream 生产部署
version: "3.8"
services:
  app:
    image: myapp:latest
    volumes:
      - sqlite-data:/var/lib/myapp
    environment:
      - DATABASE_PATH=/var/lib/myapp/data.db
      - LITESTREAM_S3_BUCKET=myapp-backups
      - LITESTREAM_S3_ENDPOINT=https://s3.amazonaws.com
      - LITESTREAM_S3_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
      - LITESTREAM_S3_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
    depends_on:
      - litestream

  litestream:
    image: litestream/litestream
    volumes:
      - sqlite-data:/var/lib/myapp
      - ./litestream.yml:/etc/litestream.yml:ro
    command: replicate -config /etc/litestream.yml
    restart: always

volumes:
  sqlite-data:

# litestream.yml - 复制配置
dbs:
  - path: /var/lib/myapp/data.db
    replicas:
      - type: s3
        bucket: myapp-backups
        path: data.db
        region: us-east-1
        access-key-id: ${AWS_ACCESS_KEY_ID}
        secret-access-key: ${AWS_SECRET_ACCESS_KEY}
        sync-interval: 1s           # 每秒同步一次
        retention: 168h             # 保留 7 天的 WAL 副本
        retention-check-interval: 1h

      - type: s3
        bucket: myapp-backups-dr
        path: data.db
        region: us-west-2           # 跨区域备份
        access-key-id: ${AWS_ACCESS_KEY_ID}
        secret-access-key: ${AWS_SECRET_ACCESS_KEY}
        sync-interval: 10s
        retention: 720h             # 保留 30 天

四、性能实战：SQLite vs PostgreSQL 基准测试

纸上谈兵没有意义，让我们用数据说话。

4.1 测试环境

• 硬件：AWS c6i.2xlarge (8 vCPU, 16GB RAM, NVMe SSD)
• SQLite 配置：WAL 模式，PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL; PRAGMA cache_size=-64000;
• PostgreSQL 配置：默认安装 + shared_buffers=4GB, effective_cache_size=12GB
• 测试工具：sqlite-benchmark + pgbench

4.2 读取性能

关键发现： 对于点查和小范围查询，SQLite 因为没有网络开销和进程间通信，性能远超 PostgreSQL。只有在全表扫描和复杂查询场景下，PostgreSQL 的查询优化器才展现出优势。

4.3 写入性能

关键发现： 在单线程或低并发写入场景下，SQLite 的写入性能优于 PostgreSQL。但当并发写入线程数超过 8 时，PostgreSQL 的 MVCC 架构优势开始显现。这正是 libSQL 的 BEGIN CONCURRENT 要解决的问题。

4.4 延迟分布

在 P99 延迟方面，SQLite 有天然优势——因为它消除了网络往返：

五、实战：用 SQLite 构建一个生产级多租户 SaaS

理论说完了，让我们来看一个完整的实战案例——用 SQLite + Turso 构建一个支持多租户的 SaaS 应用。

5.1 架构设计

┌──────────────────────────────────────────────────────────┐
│                     API Gateway                          │
│                   (Cloudflare Workers)                    │
└──────────────────────────┬───────────────────────────────┘
                           │
              ┌────────────┴────────────┐
              │                         │
              ▼                         ▼
    ┌─────────────────┐       ┌─────────────────┐
    │  Tenant Router  │       │  Tenant Router  │
    │  (Edge Worker)  │       │  (Edge Worker)  │
    └────────┬────────┘       └────────┬────────┘
             │                         │
             ▼                         ▼
    ┌─────────────────┐       ┌─────────────────┐
    │  Turso DB       │       │  Turso DB       │
    │  (Tenant A)     │       │  (Tenant B)     │
    │  libSQL + Sync  │       │  libSQL + Sync  │
    └─────────────────┘       └─────────────────┘

5.2 代码实现

// tenant-router.ts - 多租户路由
import { createClient } from "@libsql/client";

interface TenantConfig {
  id: string;
  dbUrl: string;
  authToken: string;
}

// 租户配置缓存（生产环境应使用 KV 存储）
const tenantCache = new Map<string, TenantConfig>();

export async function getTenantDb(tenantId: string): Promise<ReturnType<typeof createClient>> {
  let config = tenantCache.get(tenantId);

  if (!config) {
    // 从主数据库查询租户配置
    const adminDb = createClient({
      url: process.env.ADMIN_DB_URL!,
      authToken: process.env.ADMIN_DB_TOKEN!,
    });

    const result = await adminDb.execute({
      sql: "SELECT id, db_url, auth_token FROM tenants WHERE id = ? AND status = 'active'",
      args: [tenantId],
    });

    if (result.rows.length === 0) {
      throw new Error(`Tenant ${tenantId} not found or inactive`);
    }

    config = {
      id: result.rows[0].id as string,
      dbUrl: result.rows[0].db_url as string,
      authToken: result.rows[0].auth_token as string,
    };

    tenantCache.set(tenantId, config);
  }

  return createClient({
    url: config.dbUrl,
    authToken: config.authToken,
  });
}

// API 路由处理
export async function handleRequest(request: Request): Promise<Response> {
  const url = new URL(request.url);
  const tenantId = request.headers.get("X-Tenant-ID");

  if (!tenantId) {
    return new Response("Missing X-Tenant-ID header", { status: 400 });
  }

  const db = await getTenantDb(tenantId);

  // 根据路由分发请求
  if (url.pathname === "/api/products") {
    const result = await db.execute({
      sql: "SELECT * FROM products WHERE active = ? ORDER BY created_at DESC LIMIT ?",
      args: [true, parseInt(url.searchParams.get("limit") || "20")],
    });

    return Response.json(result.rows);
  }

  if (url.pathname === "/api/orders" && request.method === "POST") {
    const body = await request.json();

    // 使用事务确保原子性
    const txnResult = await db.transaction(async (txn) => {
      // 创建订单
      const orderResult = await txn.execute({
        sql: "INSERT INTO orders (tenant_id, user_id, total) VALUES (?, ?, ?)",
        args: [tenantId, body.userId, body.total],
      });

      // 创建订单项
      for (const item of body.items) {
        await txn.execute({
          sql: "INSERT INTO order_items (order_id, product_id, quantity, price) VALUES (?, ?, ?, ?)",
          args: [orderResult.lastInsertRowid, item.productId, item.quantity, item.price],
        });
      }

      // 更新库存
      for (const item of body.items) {
        await txn.execute({
          sql: "UPDATE products SET stock = stock - ? WHERE id = ? AND stock >= ?",
          args: [item.quantity, item.productId, item.quantity],
        });
      }

      return orderResult;
    });

    return Response.json({ orderId: txnResult.lastInsertRowid }, { status: 201 });
  }

  return new Response("Not Found", { status: 404 });
}

5.3 数据库 Schema 设计

-- 每个租户的独立数据库 Schema
CREATE TABLE products (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    description TEXT,
    price REAL NOT NULL CHECK (price > 0),
    stock INTEGER NOT NULL DEFAULT 0 CHECK (stock >= 0),
    category TEXT,
    active BOOLEAN NOT NULL DEFAULT 1,
    created_at TEXT NOT NULL DEFAULT (datetime('now')),
    updated_at TEXT NOT NULL DEFAULT (datetime('now'))
);

CREATE INDEX idx_products_category ON products(category) WHERE active = 1;
CREATE INDEX idx_products_price ON products(price) WHERE active = 1;

CREATE TABLE orders (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    tenant_id TEXT NOT NULL,
    user_id INTEGER NOT NULL,
    total REAL NOT NULL CHECK (total > 0),
    status TEXT NOT NULL DEFAULT 'pending' CHECK (status IN ('pending', 'confirmed', 'shipped', 'delivered', 'cancelled')),
    created_at TEXT NOT NULL DEFAULT (datetime('now')),
    updated_at TEXT NOT NULL DEFAULT (datetime('now'))
);

CREATE INDEX idx_orders_user ON orders(user_id);
CREATE INDEX idx_orders_status ON orders(status);
CREATE INDEX idx_orders_created ON orders(created_at DESC);

CREATE TABLE order_items (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    order_id INTEGER NOT NULL REFERENCES orders(id),
    product_id INTEGER NOT NULL REFERENCES products(id),
    quantity INTEGER NOT NULL CHECK (quantity > 0),
    price REAL NOT NULL CHECK (price > 0),
    created_at TEXT NOT NULL DEFAULT (datetime('now'))
);

CREATE INDEX idx_order_items_order ON order_items(order_id);

六、什么时候不该用 SQLite

这场复兴不意味着 SQLite 可以替代所有数据库。以下是明确不适合 SQLite 的场景：

1. 高并发写入密集型应用

如果你的应用需要每秒处理数万次写入（如实时交易系统、IoT 数据采集），SQLite 的单写模型仍然是瓶颈。即使有 libSQL 的 BEGIN CONCURRENT，在极端写入压力下 PostgreSQL 或 CockroachDB 仍然是更好的选择。

2. 需要复杂权限控制的场景

SQLite 没有用户管理和权限系统。它依赖操作系统级别的文件权限。如果你需要行级安全策略（Row Level Security）、细粒度的角色权限，PostgreSQL 是更合适的选择。

3. 需要实时流处理的场景

虽然 libSQL 有基本的变更通知，但它不是为实时流处理设计的。如果你需要 CDC（Change Data Capture）、事件溯源、实时消息队列，Kafka + PostgreSQL 的组合仍然是标准方案。

4. 超大规模数据集

SQLite 的理论数据库大小限制是 281 TB，但在实践中，当数据库文件超过几十 GB 时，维护操作（VACUUM、备份）的开销会显著增加。对于 TB 级数据集，分布式数据库仍然是唯一选择。

七、SQLite 复兴背后的第一性原理思考

为什么 SQLite 能在这个时间点复兴？这不仅仅是因为几个新工具的出现，而是底层条件发生了根本性变化：

1. NVMe SSD 改变了 I/O 成本模型

在 HDD 时代，随机 I/O 是昂贵的。SQLite 的单文件模型意味着所有写入都要竞争同一个文件的 I/O 带宽。但在 NVMe SSD 上，随机读写的延迟已经降到亚毫秒级，IOPS 可以达到数十万。这意味着 SQLite 的「单文件瓶颈」在现代硬件上已经不再成立。

2. 边缘计算消除了网络延迟优势

当你的应用部署在 Cloudflare Workers 上，而数据库在 us-east-1 的 AWS RDS 上，每一次数据库查询都要跨越整个美国大陆——往返延迟在 60-100ms。但如果数据库就在 Worker 执行的同一台机器上（Turso 的边缘节点），延迟是 0.1ms。这 1000 倍的差距足以改变架构决策。

3. 多租户和 Agent 时代需要海量小实例

一个 SaaS 平台可能有 10 万个租户。为每个租户创建一个 PostgreSQL 数据库实例？运维噩梦。但如果每个租户是一个 SQLite 文件，通过 Turso 管理——这就是 libSQL 嵌入式副本的设计初衷。同样的逻辑适用于 AI Agent：每个 Agent 需要自己的状态存储，SQLite 的单文件模型天然适合这种「海量小实例」的场景。

4. 开发者体验的降维打击

sqlite3 mydata.db 就能开始查询。不需要安装服务器、不需要配置用户、不需要启动服务。这种「开箱即用」的体验是 PostgreSQL 无法匹敌的。在快速原型开发、本地开发环境、CLI 工具等场景下，SQLite 的开发者体验是降维打击。

八、总结与展望

SQLite 的复兴不是一个技术趋势，而是一个技术回归。

二十年前，SQLite 因为「太简单」而被后端开发者抛弃。二十年后，正是这种「简单」——零配置、单文件、嵌入式——让它在边缘计算、多租户、AI Agent 等新场景中重新找到了不可替代的位置。

Turso、libSQL、Litestream 这些项目并没有试图把 SQLite 变成 PostgreSQL。它们做的是补齐 SQLite 真正的短板（网络访问、数据复制、多写并发），同时强化它的核心优势（零配置、极致性能、嵌入式）。

对于开发者来说，2026 年的数据库选型应该多一个选项：在读取密集型、边缘部署、多租户、嵌入式等场景下，SQLite 不再是「原型阶段的权宜之计」，而是生产级的最优解。

当然，这不是一场「SQLite vs PostgreSQL」的零和游戏。正确的做法是根据场景选择合适的工具——这也是这篇文章想传达的核心观点。但在做出选择之前，至少应该知道：SQLite 已经不是二十年前的那个 SQLite 了。

参考资料：

1. Turso 官方文档 - libSQL 和 Turso 平台的权威文档
2. Litestream 官方文档 - SQLite 流复制的完整指南
3. libSQL GitHub 仓库 - SQLite 开源分支的源码
4. SQLite 官方性能测试 - SQLite 官方的性能基准数据
5. 博客园 - SQLite 复兴 - 2026 年 SQLite 生态的全景分析