Postgres Summit US 2026 将于 9 月 30 日至 10 月 2 日在纽约 Convene 举行。这项活动此前名为 PGConf NYC，EDB 将以金牌赞助商身份参会，并由 PostgreSQL 专家、核心贡献者和技术创新者带来一系列通过 Call for Papers 入选的分享。已披露的议题跨度很大，从云原生转型、战略与架构，到数据库内部机制，核心问题却相当一致：PostgreSQL 每年增加约 200 项功能和改进，团队应该如何把持续演进转化为可控的生产能力？
功能增长不等于架构自动升级
每年约 200 项变化意味着 PostgreSQL 仍在快速演进，但生产系统不会因为升级了主版本就自动获得更好的架构。新功能能否创造价值，取决于团队是否回答了几个具体问题：
- 它解决的是查询性能、运维复杂度，还是高可用问题？
- 它是否改变复制、备份、扩展或连接管理方式？
- 应用驱动、ORM、代理和扩展是否兼容？
- 上线后用什么指标判断收益，并在异常时回退？
因此，评估 PostgreSQL 新版本时，不宜只阅读功能列表。更实用的方法是建立“业务问题—数据库能力—验证指标”的对应关系。例如，连接数膨胀应关注连接池和会话模型；分析查询拖慢交易负载，则要检查索引、执行计划、资源隔离以及是否需要拆分工作负载。
来源摘要还提到，尽管 PostgreSQL 持续增加大量能力，仍有少数重大里程碑尚未完成。这提醒架构团队区分两类决策：已经成熟、可以进入生产验证的能力，以及仍需等待社区演进或依靠外围组件补足的能力。不能把路线图当作当前版本的承诺。
云原生转型的难点在状态管理
把 PostgreSQL 放进容器并不等于完成云原生转型。数据库拥有持久状态，还涉及复制拓扑、故障转移、备份恢复、升级窗口和 I/O 延迟。真正需要评估的是控制面能否可靠管理这些状态变化。
一个可落地的评审清单包括：
- Pod 或虚拟机被替换后，实例身份和数据卷如何恢复；
- 主库故障时，由谁判定并执行切换，如何避免双主；
- 备份是否存放在独立故障域，是否定期执行恢复演练；
- 滚动升级是否覆盖扩展、系统目录和应用兼容性；
- 监控是否同时观察数据库指标、存储延迟和编排事件。
这也解释了为什么大会同时关注战略架构与数据库内部机制。云平台负责调度资源，但慢查询、锁竞争、WAL 堆积和膨胀仍然发生在 PostgreSQL 内部。平台工程师需要理解数据库行为，数据库管理员也需要理解编排系统的故障模型。
可以这样实践：建立一个可重复的版本评估实验
下面的实验不是大会官方示例，而是一种可以直接改造的评估方法。它使用 Docker 启动 PostgreSQL，预加载 pg_stat_statements，生成简单负载并找出最耗时的语句。运行前需要安装 Docker；可将镜像标签 postgres:17 攓成团队准备评估的版本。
set -euo pipefail
CONTAINER=pg-summit-lab
PASSWORD=postgres
docker rm -f "$CONTAINER" >/dev/null 2>&1 || true
docker run --name "$CONTAINER" \
-e POSTGRES_PASSWORD="$PASSWORD" \
-p 5432:5432 \
-d postgres:17 \
-c shared_preload_libraries=pg_stat_statements
until docker exec "$CONTAINER" pg_isready -U postgres >/dev/null 2>&1; do
sleep 1
done
docker exec -i "$CONTAINER" psql -U postgres <<'SQL'
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE TABLE orders (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
customer_id bigint NOT NULL,
amount numeric(12,2) NOT NULL,
created_at timestamptz NOT NULL DEFAULT now()
);
INSERT INTO orders (customer_id, amount, created_at)
SELECT
(random() * 10000)::bigint,
round((random() * 1000)::numeric, 2),
now() - random() * interval '90 days'
FROM generate_series(1, 200000);
ANALYZE orders;
SELECT customer_id, sum(amount)
FROM orders
WHERE created_at >= now() - interval '7 days'
GROUP BY customer_id
ORDER BY sum(amount) DESC
LIMIT 20;
SELECT calls,
round(total_exec_time::numeric, 2) AS total_ms,
round(mean_exec_time::numeric, 2) AS mean_ms,
rows,
left(query, 100) AS query
FROM pg_stat_statements
WHERE query NOT LIKE '%pg_stat_statements%'
ORDER BY total_exec_time DESC
LIMIT 10;
SQL
实验不应止于“查询跑通”。下一步可以添加候选索引，再用 EXPLAIN (ANALYZE, BUFFERS) 比较执行计划：
CREATE INDEX orders_created_customer_idx
ON orders (created_at, customer_id)
INCLUDE (amount);
ANALYZE orders;
EXPLAIN (ANALYZE, BUFFERS)
SELECT customer_id, sum(amount)
FROM orders
WHERE created_at >= now() - interval '7 days'
GROUP BY customer_id
ORDER BY sum(amount) DESC
LIMIT 20;
评估时应记录执行时间、共享缓冲区命中与读取、索引大小和写入开销。索引可能改善读查询，却会增加写放大和存储占用；只比较单次查询延迟容易得出片面结论。
实验结束后可删除容器：
docker rm -f pg-summit-lab
把会议信息转化为团队决策
面对横跨云原生、架构战略和数据库内部机制的议程，最有效的参会方式不是收集最多的幻灯片，而是带着生产问题寻找证据。可以在会前整理三张清单：当前最昂贵的数据库故障、下一次主版本升级的阻塞项，以及平台自动化仍需人工介入的环节。
听完相关分享后，把结论分成“立即实验”“继续观察”和“不适用”三类。对于准备采用的能力，应补齐基准测试、故障注入、备份恢复和回滚验证。PostgreSQL 的快速演进提供了更多工具，但成熟的采用策略仍然依赖明确的问题、可复现的实验和对边界条件的诚实判断。