PGConf.Brasil 2026 将于 9 月 2 日到 4 日在巴西 Blumenau 举办。对 PostgreSQL 社区来说，这类会议不只是听演讲，更是把线上讨论拉回到工程现场的机会。今年 EDB 同事将带来 13 场分享，说明企业级 PostgreSQL、社区协作和实际运维问题仍然是开发者和 DBA 关注的核心。
这次会议为什么值得 PostgreSQL 团队关注
PGConf.Brasil 的重点不在“发布一个产品口号”，而在社区成员面对面交流 PostgreSQL 的真实使用方式。来源摘要只明确提到两件事：会议地点和时间，以及 EDB 同事会参与 13 场 session。即使不知道每场议题细节，这个信息本身也很有价值：EDB 会把相当多的工程经验带到巴西 PostgreSQL 社区现场。
对正在使用 PostgreSQL 的团队来说，会议前最值得做的不是泛泛浏览议程，而是把自己系统里的问题整理成可讨论的材料。比如：
- 查询延迟到底来自 SQL、索引、锁等待，还是 I/O？
- 备份恢复流程有没有定期演练？
- 版本升级卡在扩展、兼容性，还是停机窗口？
- 高可用架构是否真的覆盖了故障切换后的应用连接行为？
这些问题带到 PostgreSQL 会议上，比“我们该不该用 PostgreSQL”更容易得到有用答案。
13 场分享背后的信号：PostgreSQL 已经是生产系统议题
EDB 在 PostgreSQL 生态里长期围绕企业采用、数据库平台化、兼容性和运维能力做工作。摘要没有列出 13 场 session 的主题，所以不能直接推断具体内容。但可以确定的是：一个厂商在同一场社区会议投入 13 场分享，通常意味着讨论不会只停留在入门介绍。
对工程团队而言，这类会议最值得关注的通常是这些“边界问题”：
- PostgreSQL 在业务增长后如何保持可观测、可调优；
- 社区版本、企业发行版、托管服务之间如何做技术选择；
- 数据库团队如何把备份、升级、权限和审计变成日常流程；
- 开发者如何写出对 PostgreSQL 更友好的 SQL 和迁移脚本。
这些不是一次安装 postgres 就能解决的问题。它们往往在系统跑了几个月、数据量上来、业务不能停之后才暴露出来。
参会前可以这样实践：生成一份 PostgreSQL 健康检查材料
如果你的团队准备关注 PGConf.Brasil 2026，或者只是想借这个节点复盘自己的 PostgreSQL 使用情况，可以先跑一组只读 SQL，把问题带着数据去讨论。
下面示例假设你可以使用 psql 连接目标数据库，并且账号有读取系统视图的权限。运行前把 DATABASE_URL 改成你的连接串。
export DATABASE_URL="postgresql://postgres:postgres@localhost:5432/appdb"
psql "$DATABASE_URL" -v ON_ERROR_STOP=1 <<'SQL'
\echo 'PostgreSQL version'
SELECT version();
\echo 'Database size'
SELECT
current_database() AS database,
pg_size_pretty(pg_database_size(current_database())) AS size;
\echo 'Top 10 largest user tables'
SELECT
schemaname,
relname AS table_name,
pg_size_pretty(pg_total_relation_size(relid)) AS total_size,
n_live_tup AS estimated_rows
FROM pg_stat_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;
\echo 'Tables with many dead tuples'
SELECT
schemaname,
relname AS table_name,
n_live_tup,
n_dead_tup,
last_autovacuum,
last_vacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY n_dead_tup DESC
LIMIT 10;
\echo 'Indexes that may be unused'
SELECT
schemaname,
relname AS table_name,
indexrelname AS index_name,
idx_scan,
pg_size_pretty(pg_relation_size(indexrelid)) AS index_size
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY pg_relation_size(indexrelid) DESC
LIMIT 10;
SQL
这段脚本不会修改数据，但它能帮你快速形成几个可追问的问题：最大的表是否需要分区？死元组是否说明 autovacuum 配置偏弱？零扫描索引是冗余索引，还是刚创建还没被业务访问？
如果你的数据库启用了 pg_stat_statements，还可以再补一段查询，找出最耗时的 SQL。注意：这需要扩展已经安装并在配置中启用。
SELECT
calls,
round(total_exec_time::numeric, 2) AS total_ms,
round(mean_exec_time::numeric, 2) AS mean_ms,
rows,
left(query, 160) AS sample_query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;
这类输出很适合在会议 hallway track、BoF 讨论或 session Q&A 里使用。相比描述“数据库有点慢”，拿出具体指标更容易获得针对性建议。
面向团队的参会清单
PGConf.Brasil 2026 的时间已经明确：9 月 2 日到 4 日，地点在 Blumenau。对国内或远程关注者来说，即使不能到场，也可以用会议议题作为 PostgreSQL 技术盘点的触发器。
建议团队提前准备四件事：
- 列出当前 PostgreSQL 版本、扩展、部署方式和最大数据库体量；
- 整理最近 3 个线上数据库事故或性能问题；
- 标记最想了解的方向，例如升级、高可用、备份恢复、查询优化、权限治理；
- 会后把听到的建议转成小实验，而不是直接改生产配置。
边界也要说清楚：会议分享能提供经验、方向和案例，但不能替代你自己的压测、恢复演练和变更评审。尤其是数据库参数、索引删除、分区改造、高可用切换这类动作，都应该先在测试环境验证。把 PGConf.Brasil 2026 当成一次输入密度很高的工程复盘机会，会比单纯“听 13 场演讲”收获更多。