Serverless 数据层选型：D1、Turso、Neon、Supabase 与 Upstash

D1   ：Cloudflare 的分布式 SQLite，绑定 Workers，edge 就近
Turso：libSQL（SQLite 分支），多地域副本，HTTP API

共同点：
  1. SQLite 内核 → 轻量、零配置
  2. 数据副本部署到边缘 → 就近读
  3. 写需要协调（单主或多主）→ 写延迟高于读

Neon    ：Serverless Postgres，按需冷启动、分支管理、存储计算分离
Supabase：Postgres + Auth + Storage + Realtime 一体

共同点：
  1. 完整 Postgres 功能（事务/复杂查询/扩展）
  2. 自动休眠/唤醒（serverless 计费）
  3. 连接是「有状态」的 → 需要连接池/HTTP 接口

需要低延迟边缘读 + 简单数据模型  → D1 / Turso
需要完整 SQL/事务/复杂查询      → Neon / Supabase
边缘读为主、写少                → 边缘 SQLite
写多、强一致、跨区域            → 托管 Postgres

Cloudflare KV：
  全局复制的键值存储，最终一致
  适合：配置、会话元数据、静态映射、缓存

Upstash Redis：
  云 Redis，通过 HTTP/REST 访问（无 TCP 连接占用）
  适合：计数器、排行榜、实时数据、Pub/Sub、TTL 缓存

// Cloudflare KV
await env.KV.put('config:feature-x', 'true', { expirationTtl: 3600 })
const v = await env.KV.get('config:feature-x')

// Upstash Redis（HTTP）
import { Redis } from '@upstash/redis'
const redis = new Redis(env.UPSTASH_REDIS_REST_URL, env.UPSTASH_REDIS_REST_TOKEN)
await redis.incr('counter:orders')         // 原子自增
await redis.zadd('leaderboard', { score: 95, member: 'user1' })

KV 最终一致无法保证「强一致状态」
DO：边缘上的有状态单实例 → 强一致、可做状态机
适合：WebSocket 状态、协调器、强一致计数器

问题：每个函数实例都想连数据库，但 Postgres 连接数有限
      函数冷启动 + 建连 = 双重延迟
方案：
  1. 连接池（Neon/Supabase pooler / PgBouncer）
  2. 函数级复用：模块级全局连接（不每次请求新建）
  3. HTTP 接口（Supabase REST / Turso HTTP）免连接池

// 模块级连接复用（Serverless 最佳实践）
// lib/db.ts
const pool = new Pool({ connectionString: DATABASE_URL })  // 模块级 → 实例内复用

export async function query(sql: string, params?: any[]) {
  return pool.query(sql, params)
}
// 注意：每次冷启动会重新建池 → 用连接池 + 预热减轻

三层延迟：
  ① 函数冷启动（运行时拉起）
  ② 数据库建连（TCP+TLS 握手）
  ③ 跨区域网络往返（边缘到数据库所在地）

优化：
  ① 预热 + 轻运行时
  ② 连接池/HTTP 免握手
  ③ 数据放边缘（D1/Turso）或 CDN 缓存

1. 应用层限流：并发控制（并发池）
2. 数据库层：连接池 / max_connections 配置
3. 架构层：读走副本、写走主库

核心业务数据  → Neon/Supabase（Postgres，事务与复杂查询）
边缘高频读    → D1/Turso（就近）或 CDN 缓存
实时/计数器   → Upstash Redis
会话/配置     → Cloudflare KV
文件/图片     → R2/S3 对象存储
向量检索      → 向量库（Pinecone/Weaviate 或 Postgres pgvector）

方案：
  pgvector（Postgres 扩展）→ 与业务数据同库，简化架构
  独立向量库（Pinecone/Weaviate/Cloudflare Vectorize）→ 规模大
  Turso/D1 暂不适合大规模向量

-- pgvector 示例
CREATE EXTENSION vector;
ALTER TABLE products ADD COLUMN embedding vector(384);
SELECT id FROM products ORDER BY embedding <-> $1 LIMIT 10;  -- 余弦距离

R2/S3：静态资源、图片、上传文件
配合 CDN：边缘缓存、免出口流量（R2 特色）
图片处理：Cloudflare Images / Vercel Image 服务

结构化业务数据 → Postgres
向量/语义       → pgvector / 向量库
文件/模型权重   → R2/S3
Prompt/会话     → KV/Redis

读多写少（内容站/推荐）    → 边缘副本 + CDN 缓存
写多读少（订单/日志）      → 中心主库 + 队列削峰
实时数据（排行榜/计数）    → Redis
时序数据（监控/事件）      → 时序库 / Redis 聚合

强一致（金额/库存）   → Postgres 事务
弱一致（阅读数/热度）  → KV/Redis + 异步回写
最终一致（社交时间线） → 边缘 SQLite 副本 + 同步

请求 → 边缘 KV/缓存（命中即回）→ 边缘 SQLite 副本（就近读）
     → 中心 Postgres（权威写）→ Redis（实时/计数）→ 对象存储（文件）

1. 高频读用缓存（KV/CDN）→ 省数据库请求
2. 写密集用批处理/队列合并
3. 边缘 SQLite 减少跨区网络费
4. Postgres 用 Neon 休眠省计算时间
5. 监控请求量级，设预算告警

场景：SaaS 应用（用户/订单/内容/实时）

数据分层：
  ┌─ Cloudflare KV ── 会话/配置/特性开关（最终一致可接受）
  ├─ Upstash Redis ── 排行榜/计数器/PubSub（实时强一致）
  ├─ D1/Turso ────── 内容/帖子（读多写少，边缘就近）
  ├─ Neon/Supabase ─ 订单/用户/权限（强一致，事务核心）
  ├─ R2/S3 ───────── 图片/文件（对象存储 + CDN）
  └─ pgvector ────── 向量检索（AI 搜索/推荐）

写路径：函数 → Postgres（事务）/ 队列削峰
读路径：边缘缓存 → 边缘 SQLite → Postgres