🗄️ 数据库选型

01 数据库选型决策树

别上来就比特性。先回答这些问题，答案会直接指向你的数据库：

02 三大主流数据库深度对比

架构本质差异

最本质的区别：SQLite 运行在你的应用进程里。没有数据库服务器、没有 TCP 连接、没有认证。你打开一个文件，查询它。这意味着延迟可以降到微秒级——同样的主键查询，PostgreSQL 可能 2ms（含 0.5ms 网络往返），SQLite 只需 0.1ms。

SQL 特性对比

PostgreSQL 的 JSONB：一个数据库搞定两件事

PostgreSQL 的 JSONB 是它最被低估的特性。你可以在关系型表里存 JSON 文档，用 GIN 索引查询内部字段，让它同时充当文档数据库：

-- 混合关系 + 文档模型：事件表
CREATE TABLE events (
  id serial PRIMARY KEY,
  data jsonb NOT NULL,
  created_at timestamptz DEFAULT now()
);

-- 对 JSON 内部字段建索引
CREATE INDEX idx_events_type ON events USING GIN ((data -> 'type'));

-- 查询特定类型的事件（走索引，毫秒级）
SELECT data->>'user_id' as user_id, count(*)
FROM events
WHERE data @> '{"type": "page_view"}'
  AND created_at > now() - interval '7 days'
GROUP BY data->>'user_id'
ORDER BY count(*) DESC
LIMIT 10;

这意味着：你不需要 MongoDB。PostgreSQL 的 JSONB + GIN 索引能覆盖 90% 的文档数据库场景，同时你还能享受 ACID 事务、JOIN、和外键约束。

03 PostgreSQL：2026 年的默认选择

是什么

世界上最先进的开源关系型数据库。35+ 年历史，MVCC 并发模型，扩展系统让一个数据库引擎服务多种专业场景。

何时用

• ✅ 新项目的默认选择（没有特殊理由就不需要考虑别的）
• ✅ 需要复杂查询（多表 JOIN、窗口函数、CTE）
• ✅ 需要 JSONB 混合模型（关系 + 文档）
• ✅ 需要向量搜索（pgvector 扩展）
• ✅ 需要地理空间查询（PostGIS 扩展）
• ✅ 需要时序数据（TimescaleDB 扩展）

何时不用

• ❌ 单服务器嵌入式场景（SQLite 更简单）
• ❌ 需要全球边缘部署（Turso 更合适）
• ❌ 运维能力为零且不想学（Supabase 托管可以解决）

关键扩展

代码示例：SaaS 多租户基础设置

-- 方式 1：Row-Level Security (RLS) — 推荐中小规模
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

-- 应用层设置当前租户
SET app.current_tenant = '550e8400-e29b-41d4-a716-446655440000';

-- 之后所有查询自动过滤，无需手动加 WHERE
SELECT * FROM projects;  -- 只返回当前租户的数据

-- 方式 2：Schema 隔离 — 大规模或强隔离需求
CREATE SCHEMA tenant_acme;
CREATE SCHEMA tenant_beta;

-- 每个租户独立的表结构
CREATE TABLE tenant_acme.projects (...);
CREATE TABLE tenant_beta.projects (...);

04 MySQL：老牌但正在失去新项目

是什么

世界上部署量最大的开源关系型数据库。InnoDB 引擎提供 ACID 事务，聚簇索引在主键查询上有天然优势。

何时用

• ✅ 团队已有深厚 MySQL 经验
• ✅ 读多写少，且以主键查询为主（聚簇索引优势）
• ✅ 需要 PlanetScale 的分支工作流（基于 Vitess）
• ✅ 已有 MySQL 基础设施，迁移成本大于收益

何时不用

• ❌ 新项目（PostgreSQL 功能更全，生态更好）
• ❌ 需要复杂分析查询（窗口函数、CTE 性能不如 PG）
• ❌ 需要 JSONB 深度查询（MySQL JSON 索引太弱）
• ❌ 需要丰富的扩展生态

优劣对比

代码示例：PlanetScale 分支工作流

# 创建开发分支（类似 Git 分支，生产数据可复制）
pscale branch create add-user-avatar main

# 在开发分支上修改 Schema
pscale shell mydb add-user-avatar
> ALTER TABLE users ADD COLUMN avatar_url VARCHAR(512);

# 创建部署请求（类似 PR，团队审查 Schema 变更）
pscale deploy-request create mydb add-user-avatar

# 审查通过后部署到生产
pscale deploy-request deploy mydb 1

05 SQLite：被低估的生产级选择

是什么

世界上最广泛部署的数据库引擎。嵌入式、零配置、进程内运行。2024-2026 年经历「SQLite 文艺复兴」——Turso、Litestream、LiteFS 让 SQLite 从本地数据库进化为边缘就绪的分布式方案。

何时用

• ✅ 单服务器应用（大多数 SaaS 在达到 PMF 之前都是单服务器）
• ✅ 读多写少（博客、内容站、仪表盘）
• ✅ 零运维需求（无数据库服务器要管理）
• ✅ 延迟敏感（无网络往返，查询微秒级）
• ✅ CLI 工具、桌面应用、移动应用
• ✅ 边缘计算场景（配合 Turso）

何时不用

• ❌ 多服务器同时写入（WAL 只有 1 个写者）
• ❌ 高并发写入（>100 TPS 会开始争用）
• ❌ 需要 PostgreSQL 级别的高级查询特性
• ❌ 需要用户级别的权限控制（SQLite 无认证）

SQLite 文艺复兴：三个关键工具

代码示例：Litestream 持续备份

# 安装
curl -sSfL https://litestream.io/install.sh | sh

# 配置文件 litestream.yml
dbs:
  - path: /data/app.db
    replicas:
      - url: s3://my-bucket/app.db
        retention: 24h
        snapshot-interval: 1h

# 启动持续复制
litestream replicate

# 灾难恢复（从 S3 恢复到最新状态）
litestream restore -o /data/app.db s3://my-bucket/app.db

06 Turso / libSQL：SQLite 的边缘进化

是什么

Turso 是基于 libSQL（SQLite 的开源分支）的边缘数据库服务。libSQL 保持 SQLite 文件格式和 API 兼容，同时增加了 HTTP API、嵌入式副本、边缘同步等能力。

核心特性

• 嵌入式副本 (Embedded Replicas)：应用进程内持有本地 SQLite 副本，读操作零延迟，写操作异步同步到云端
• 边缘同步：数据库副本分布到全球 30+ 区域，用户访问最近的副本
• HTTP API：无需 TCP 连接，通过 HTTP 请求操作数据库，完美适配 Serverless/Edge 环境
• Schema DB：2025 年推出的全新架构，从零重写 SQLite 语义，支持真正的并发写入

何时用

• ✅ 全球用户的低延迟需求（边缘副本）
• ✅ Edge/Serverless 环境（HTTP API，无需持久连接）
• ✅ 离线优先应用（嵌入式副本支持离线读写）
• ✅ 已经熟悉 SQLite，想要云端管理 + 全球分布

何时不用

• ❌ 需要复杂 SQL（窗口函数、CTE 性能不如 PG）
• ❌ 高并发写入（libSQL 仍受单写者限制，Schema DB 逐步解决）
• ❌ 需要 PostgreSQL 级别的扩展生态

代码示例：嵌入式副本

// TypeScript: 嵌入式副本 — 本地读、远程写
import { createClient } from '@libsql/client';

const client = createClient({
  url: 'file:local.db',             // 本地副本
  syncUrl: 'libsql://mydb.turso.io', // 远程同步源
  authToken: process.env.TURSO_TOKEN,
});

// 首次启动：从远程拉取数据
await client.sync();

// 读取：从本地副本（零延迟）
const result = await client.execute('SELECT * FROM users WHERE id = ?', [userId]);

// 写入：发送到远程，异步同步回本地
await client.execute('INSERT INTO page_views (url, ts) VALUES (?, ?)', [url, Date.now()]);
await client.sync(); // 主动同步最新数据

07 Cloudflare D1：Workers 的原生数据库

是什么

Cloudflare 构建的 SQLite 兼容数据库，运行在 Cloudflare 的全球边缘网络上。专为 Workers 设计，无需额外基础设施。

优势

• 与 Workers 深度集成，零配置
• 全球边缘分布，自动就近路由
• 免费额度慷慨（5GB 存储 + 500 万读/天）
• SQLite 兼容：熟悉的 SQL 语法

劣势

• 锁定 Cloudflare 生态
• 单区域写入，跨区域有延迟
• 查询性能不如原生 SQLite（经过网络层）
• 缺少高级特性（无扩展、无 RLS）

代码示例

// Cloudflare Worker + D1
export default {
  async fetch(request, env) {
    // env.DB 是绑定好的 D1 数据库
    const { results } = await env.DB.prepare(
      'SELECT * FROM users WHERE tenant_id = ? LIMIT 20'
    ).bind(tenantId).all();

    return Response.json(results);
  },
};

// wrangler.toml 配置
// [[d1_databases]]
// binding = "DB"
// database_name = "my-saas-db"
// database_id = "xxxx-xxxx"

08 Supabase：PostgreSQL 的全托管体验

是什么

基于 PostgreSQL 的开源 Firebase 替代品。不只提供数据库——认证、存储、实时订阅、Edge Functions 全打包。2025-2026 新增数据库分支（Git-based 预览环境）、物理读副本、后台 Edge Functions、MCP Server 集成。

Supabase vs Firebase

代码示例：Supabase 实时订阅

// 前端：实时监听任务变更
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);

// 订阅当前租户的任务变化
supabase
  .channel('tasks')
  .on('postgres_changes', {
    event: '*',
    schema: 'public',
    table: 'tasks',
    filter: `tenant_id=eq.${tenantId}`,
  }, (payload) => {
    console.log('变更:', payload.eventType, payload.new);
    updateUI(payload);
  })
  .subscribe();

09 ORM 选型：类型安全 vs 灵活控制

ORM 不是必需的，但好的 ORM 能大幅提升开发效率。2026 年的 ORM 生态已经从「ORM vs 原生 SQL」的争论进化到「类型安全的查询构建器 vs 全功能 ORM」的选择。

三大 ORM 对比

Drizzle ORM：2026 年的新宠

// Schema 定义 — 纯 TypeScript，编译时类型检查
import { pgTable, uuid, varchar, timestamp, integer } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
  id: uuid('id').defaultRandom().primaryKey(),
  email: varchar('email', { length: 255 }).notNull().unique(),
  name: varchar('name', { length: 100 }),
  tenantId: uuid('tenant_id').notNull(),
  createdAt: timestamp('created_at').defaultNow().notNull(),
});

export const projects = pgTable('projects', {
  id: uuid('id').defaultRandom().primaryKey(),
  name: varchar('name', { length: 200 }).notNull(),
  tenantId: uuid('tenant_id').notNull(),
  ownerId: uuid('owner_id').references(() => users.id),
});

// 查询 — 完全类型安全，SQL 可预测
import { eq, and } from 'drizzle-orm';

const result = await db
  .select()
  .from(projects)
  .where(and(
    eq(projects.tenantId, tenantId),
    eq(projects.ownerId, userId),
  ));

// result 的类型自动推导为 Project[] — 不需要手动定义返回类型

Prisma：快速启动的选择

// schema.prisma — 声明式 DSL
model User {
  id        String   @id @default(uuid())
  email     String   @unique
  name      String?
  tenantId  String
  projects  Project[]
  createdAt DateTime @default(now())
}

model Project {
  id        String   @id @default(uuid())
  name      String
  tenantId  String
  ownerId   String
  owner     User     @relation(fields: [ownerId], references: [id])
}

// 查询 — 简洁但 SQL 不透明
const projects = await prisma.project.findMany({
  where: { tenantId, ownerId: userId },
  include: { owner: true },  // 小心 N+1
});

Kysely：SQL 高手的选择

// 类型定义 — 完全手动，完全控制
interface Database {
  users: {
    id: Generated<string>;
    email: string;
    name: string | null;
    tenant_id: string;
  };
  projects: {
    id: Generated<string>;
    name: string;
    tenant_id: string;
    owner_id: string;
  };
}

// 查询 — 写起来像 SQL，类型安全
const result = await db
  .selectFrom('projects')
  .innerJoin('users', 'users.id', 'projects.owner_id')
  .select(['projects.id', 'projects.name', 'users.email as owner_email'])
  .where('projects.tenant_id', '=', tenantId)
  .execute();

10 数据库迁移：Schema 变更的安全网

数据库迁移是把 Schema 变更纳入版本控制的核心实践。手动改数据库 = 定时炸弹。

迁移工具对比

迁移最佳实践

11 连接池：生产环境的必选项

数据库连接是昂贵的资源。PostgreSQL 每个连接 fork 一个进程，默认 100 个连接就会耗尽内存。Serverless 函数的短连接更是灾难——每个冷启动都新建连接，连接握手就要 50ms+。

连接池方案

代码示例：PgBouncer 配置

# pgbouncer.ini
[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
# 事务模式：事务结束就释放连接（最节省连接数）
pool_mode = transaction

# 连接池大小：每个数据库/用户对的最大连接数
max_client_conn = 1000
default_pool_size = 25

# 空闲连接超时
server_idle_timeout = 300

# 监听端口
listen_port = 6432
listen_addr = 0.0.0.0

12 场景推荐速查表

13 替代方案与补充

什么时候需要不止一个数据库？

大多数 SaaS 只需要一个 PostgreSQL。但以下场景可能需要补充：

14 关键链接