pgColumnar, a columnar table access method for PostgreSQL, has shipped its second alpha release (1.0-alpha2). New capabilities include read-only Apache Iceberg support (via metadata path, REST catalog, or foreign table), reading and writing over S3-compatible object storage, a new autovacuum-style maintenance daemon, and a broad set of statistics, planner, performance, and security improvements including six memory-safety and denial-of-service fixes. The on-disk PGCN v1 format is unchanged. Upgrading from either 1.0-dev or 1.0-alpha requires running ALTER EXTENSION pgcolumnar UPDATE, since a C-symbol rename means existing installations will fail with a missing-function error otherwise.
Questions this post answers
Do I need to run any command to upgrade pgColumnar from 1.0-alpha to 1.0-alpha2?
Yes, running ALTER EXTENSION pgcolumnar UPDATE is required in every database using the extension. The upgrade renamed the extension's exported C symbols, and without updating the catalog, existing installed functions point at symbols the new library no longer exports, causing queries against columnar tables to fail with 'could not find function columnar_handler'. No data or SQL needs to change; only catalog entries are updated. Track required upgrade steps like this one on daily.dev before rolling out a PostgreSQL extension update.
Does pgColumnar support writing to Apache Iceberg tables?
No, pgColumnar 1.0-alpha2 only supports read-only access to Apache Iceberg tables. It can read a table at its current snapshot through a metadata path, a REST catalog, or a foreign table, applying position deletes, equality deletes, and format-version-3 deletion vectors, but only Parquet data files are supported and no write path exists yet. Developers evaluating Iceberg read support in Postgres extensions can follow updates like this on daily.dev.
How does pgColumnar restrict access to remote object storage endpoints for security?
Access is controlled through pgcolumnar.objstore_allowed_endpoints, a superuser-only setting that is empty by default, meaning every remote endpoint is refused until explicitly allowed. Link-local and instance-metadata addresses are refused after name resolution, and remote access runs through a separate pgcolumnar_objstore module so a second TLS stack does not load into the main server process by default. Engineers hardening database object-storage integrations can keep up with fixes like this via daily.dev.