PgColumnar 1.0 Alpha 2 于 2026 年 8 月 18 日发布，距离上一版 1.0-alpha 只有两周。这一版的重点已经不只是列式表本身，而是把 PgColumnar 接入更大的数据平台：它开始支持只读 Apache Iceberg，能够通过 S3 兼容对象存储读写数据，并加入维护守护进程，同时继续推进统计信息、查询规划器、性能和安全方面的改进。
对已有用户来说，一个重要信号是：PGCN v1 原生磁盘格式没有变化，现有表仍可按原方式读写。不过，版本仍处于 Alpha 阶段，新能力更适合在隔离环境中验证，而不是直接承担关键生产负载。
这次发布改变了什么
只读 Iceberg 支持
PgColumnar 现在可以读取 Apache Iceberg 数据。这个能力的价值在于，PostgreSQL 查询可以直接接触由数据湖或湖仓系统管理的表，而不必先把全部数据复制到 PostgreSQL 的本地表中。
“只读”是这里的关键边界：当前摘要只确认了 Iceberg 的读取能力，因此不应把它理解为 PostgreSQL 可以直接修改 Iceberg 表。实际落地时，应把 Iceberg 当作外部数据源，并明确数据写入仍由原有数据管道负责。
S3 兼容对象存储读写
除了本地磁盘，PgColumnar 现在支持通过 S3 兼容接口读取和写入数据。这覆盖了公有云对象存储、私有化对象存储以及本地 S3 兼容服务等场景。
对象存储带来的收益很直接：数据容量不再受单台 PostgreSQL 主机磁盘限制，冷数据也可以放到更适合长期保存的介质上。但它同时引入了网络延迟、凭证管理、请求失败重试和对象存储一致性等新的运行时问题。列式扫描通常会读取较大的数据块，连接超时和带宽上限需要在压测中确认。
维护守护进程
新版本加入维护守护进程，说明部分后台整理工作开始从一次性的人工操作转向持续运行的服务。对于列式存储，维护任务可能影响压缩、文件组织、统计信息或存储回收，因此部署时应关注它的生命周期、权限、日志和资源上限。
摘要没有给出具体启动参数或服务名。实际安装时应以对应版本的变更记录和安装包文档为准，不要直接套用其他 Alpha 版本的命令。
PGCN v1 不变，升级风险相对集中
PGCN v1 原生磁盘格式保持不变，意味着升级的主要关注点不在“是否需要重写所有已有表”。已有表仍可按原方式读写，这降低了格式迁移带来的风险。
但格式不变并不等于升级没有风险。新版本同时调整了统计信息、规划器、性能和安全相关逻辑，可能改变查询计划、资源消耗或访问权限行为。升级验证至少应覆盖以下几类场景：
- 对现有 PgColumnar 表执行典型扫描、聚合和过滤查询。
- 比较升级前后的
EXPLAIN计划与执行时间。 - 验证对象存储凭证、网络策略和最小权限配置。
- 检查维护守护进程是否会与备份、扩缩容或发布流程互相影响。
- 设计对象存储不可用、网络抖动和凭证过期时的恢复测试。
可以这样搭建一个最小验证环境
下面的命令是一个可改造的验证模板。它假设你已经安装了对应版本的 PgColumnar 扩展，并且 PostgreSQL 可以访问一个 S3 兼容对象存储。扩展的实际 SQL 对象名、对象存储配置项和维护进程参数，应根据安装包文档替换。
先准备环境变量，避免把访问密钥直接写进 SQL 或脚本：
export PGHOST=127.0.0.1
export PGPORT=5432
export PGDATABASE=analytics
export PGUSER=postgres
export S3_ENDPOINT="https://s3.example.internal"
export AWS_ACCESS_KEY_ID="replace-me"
export AWS_SECRET_ACCESS_KEY="replace-me"
export AWS_DEFAULT_REGION="us-east-1"
连接 PostgreSQL，确认扩展版本，并保存一组基线计划：
psql -X -v ON_ERROR_STOP=1 <<'SQL'
CREATE EXTENSION IF NOT EXISTS pgcolumnar;
SELECT extname, extversion
FROM pg_extension
WHERE extname = 'pgcolumnar';
EXPLAIN (ANALYZE, BUFFERS)
SELECT customer_id, sum(amount)
FROM sales_columnar
WHERE event_date >= DATE '2026-01-01'
GROUP BY customer_id;
SQL
如果当前版本提供了将表或外部数据源映射到 S3 的专用 SQL，可以把配置放入单独的迁移脚本，例如：
-- 示例模板：请按实际版本替换对象名和参数名。
-- 不要在生产环境中直接执行未经版本文档确认的配置。
--
-- SELECT pgcolumnar.configure_object_storage(
-- endpoint => current_setting('app.s3_endpoint'),
-- bucket => 'analytics-data',
-- prefix => 'columnar/');
验证 Iceberg 时，建议单独建立测试数据库或测试 schema，只执行读取查询，并记录结果集、查询计划和网络耗时。不要把只读支持误用为写入接口，也不要在没有回滚方案时修改现有业务表的存储路径。
上线前的检查清单
PgColumnar 1.0 Alpha 2 适合用来验证新的存储架构，尤其是 PostgreSQL 与对象存储、数据湖之间的组合方式。采用时可以遵循这份清单：
- 先用副本或非关键数据验证，不直接替换生产主表。
- 固定测试数据量、查询集合和对象存储区域，比较升级前后结果。
- 为 S3 访问配置最小权限、短期凭证和可审计的轮换流程。
- 为维护守护进程设置独立的运行身份、日志采集和资源限制。
- 为网络失败、凭证失效、对象缺失和部分读取失败准备告警。
- 把查询计划变化纳入升级验收，而不仅仅比较 SQL 是否返回正确结果。
这次 Alpha 2 的方向很清晰：PgColumnar 正从 PostgreSQL 内部的列式访问方法，扩展为能够连接对象存储和 Iceberg 数据的组件。原生格式保持不变让已有用户拥有较好的升级起点，但新引入的网络、权限和后台维护边界仍需要通过真实压测与故障演练来确认。