Neon serverless PostgreSQL

Neon 是一个 serverless PostgreSQL 平台：计算与存储分离，计算可自动伸缩并在空闲时 scale to zero，写时复制存储让数据库分支便宜到可以为每个 pull request 建一个。它运行社区 PostgreSQL——截至本次核对，17 和 18 等新大版本均可用——因此驱动、SQL 和大多数扩展行为符合预期。与其他平台的定位对比见云服务版图。

Neon 改变了什么

• 数据库分支成为一等工作流。 分支是数据和 schema 的写时复制克隆，秒级创建。预览环境、CI 运行和迁移演练都可以各拿一个完整数据库，而不必重复支付存储成本。
• Scale-to-zero 与自动伸缩。 空闲计算自动挂起，下一个连接到来时恢复；繁忙时计算在配置范围内伸缩。间歇性负载不再为空转容量付费。
• 池化与直连两套端点。 Neon 同时提供基于 PgBouncer 的池化连接串和直连连接串，二者用途和上限不同。
• 按用量计费。 计算按 CU-hour、存储按 GB·月计量，成本模型与按实例计费的服务不同；请用真实流量模式对照定价页估算。

数据库分支工作流

当前 Neon CLI 以 neon 命令安装（neonctl 仍是别名），核对日期 2026-08-06：

npm install -g neon
neon auth
neon projects create --name myapp
neon branches create --name feature/x --parent main
neon connection-string feature/x

典型的「一个特性一个分支」流程：

export DATABASE_URL=$(neon connection-string feature/x)
psql "$DATABASE_URL" -c "ALTER TABLE users ADD COLUMN beta_flag boolean DEFAULT false;"

# 分支不会自动合并——把评审过的 SQL 自己应用到 main
psql "$(neon connection-string main)" -f migrations/0042_add_beta_flag.sql

# 合并前比对 schema
neon branches schema-diff main feature/x

neon branches delete feature/x

关键的纪律在中间一步：Neon 分支在创建时复制数据和 schema，但没有自动的 schema 合并。迁移仍要走正常的评审和迁移工具流程，像任何变更一样应用到 main。

需要接受的差异

• 挂起后的冷启动。 开启 scale-to-zero 后，空闲期结束的第一个连接要等待计算恢复。对延迟敏感的生产服务应调大或关闭挂起超时，并实测驱动和连接池在唤醒期间的重试行为。
• 项目区域在创建时固定。 每个项目部署在单一 AWS 区域（Azure 区域正在逐步退出），创建后无法迁移区域——换区域意味着新建项目加数据搬迁。以当前区域列表为准。
• 扩展来自允许清单。 需要 OS 级访问或任意共享库的扩展不可用；在扩展文档中确认确切清单和版本。
• 分支数据治理由你负责。 分支默认复制生产数据。如果分支会进入 CI 或预览环境，需要规划脱敏，或从已匿名的父分支创建。

生产前验证

1. 经历真实空闲期后，用你实际的驱动、ORM 和连接池测量冷启动延迟。
2. 按工作负载决定池化还是直连，并在池化端点上测试 prepared statement 和 transaction pooling 行为。
3. 在分支进入共享环境之前，定好分支生命周期和数据脱敏规则。
4. 在所用套餐的恢复窗口内演练基于分支的恢复，并用 pg_dump 导出一次到独立 PostgreSQL 恢复。
5. 用一个真实流量周估算 CU-hour 和存储消耗，而不是按免费层形态估算。

池化、备份演练和监控等跨平台内容见生产环境技术栈。