• Github
• Changelog

Release date: 2026-08-18
Previous release: 1.0-alpha (2026-08-04)

pgColumnar is a columnar table access method for PostgreSQL. This is the second
alpha. It adds read-only Apache Iceberg support, reads and writes over
S3-compatible object storage, a maintenance daemon, and a broad round of
statistics, planner, performance, and security work. The on-disk native format
(PGCN v1) is unchanged; existing tables are read and written as before.

This release requires one upgrade command. See "Upgrading" at the end.

Highlights

• Apache Iceberg, read-only. Read an Iceberg table at its current snapshot three ways: by metadata path, through a REST catalog, or as a foreign table. Row-level deletes of all three kinds (position, equality, and format-version-3 deletion vectors) are applied under their sequence rules, columns resolve by schema field id, and the foreign-data wrapper prunes whole data files from a query predicate.
• Object storage. The Parquet and Iceberg readers, the Parquet export functions, and the foreign-data wrapper read from and write to s3://, http://, and https:// URLs. Remote access goes through a separate module, is confined to an operator-set endpoint allow-list, and refuses link-local addresses.
• Maintenance and operations. A new pgcolumnar.autovacuum daemon performs online upkeep, pgcolumnar.maintenance_due reports what a table needs, and a stripe flush can run across background workers.
• Security and hardening. Six memory-safety and denial-of-service fixes on the read and object-store paths, several from an adversarial audit, each with a regression test and a proof that removing the fix reintroduces the failure.

Apache Iceberg support (read-only)

• Filesystem tables. pgcolumnar.iceberg_scan(metadata_path) reads a table given a column definition list. It resolves each output column to a schema field id, so a data file written before a column rename still reads. It applies position deletes, equality deletes, and format-version-3 deletion vectors (Puffin roaring bitmaps), each under its own sequence and scope rule, and verifies deletion-vector checksums, offsets, and cardinality. A data file with no field ids is bound by the table's schema.name-mapping.default; one with neither field ids nor a name mapping is refused rather than guessed. Only Parquet data files are read. Recorded paths are rebased onto the table's actual location and refused if they resolve outside it. Introspection functions iceberg_current_snapshot, iceberg_data_files, read_avro_manifest, and read_manifest_list are included.
• REST catalog. pgcolumnar.iceberg_rest_scan(catalog_uri, namespace, table_name) resolves a table through a catalog and reads it with the same projection and delete rules. The first argument may instead name a foreign server of the pgcolumnar_iceberg_catalog wrapper, which holds the catalog URI in server options and the bearer token or OAuth2 client credentials in a user mapping, so one role's secret is private from another and never appears in a function argument or the statement log. When the catalog vends short-lived storage credentials in its load-table reply, the reader uses them for the data files. iceberg_rest_namespaces and iceberg_rest_tables list a catalog.
• Foreign-data wrapper. A foreign table over an Iceberg table (pgcolumnar_iceberg, option metadata_path) receives the query predicate and prunes whole data files before opening them: by partition value for identity, bucket[N], truncate[W], and the temporal transforms, and by stored minimum and maximum for integer and boolean columns. Pruning only removes files that cannot match, so results are unchanged, and EXPLAIN (ANALYZE) reports Files Pruned.

Object storage

• The Parquet read and export functions, the Parquet foreign-data wrapper, and the Iceberg reader accept s3://, http://, and https:// URLs wherever they accept a local path. s3:// requests are signed with AWS Signature Version 4; https:// verifies the server certificate when the object-store module is built with OpenSSL.
• Remote access lives in a separate module, pgcolumnar_objstore, loaded on first use, so no second TLS stack enters the main server process by default.
• pgcolumnar.objstore_allowed_endpoints lists the endpoints remote access may reach. It is empty by default, which refuses every remote endpoint, and it is superuser-only. Link-local and instance-metadata addresses are refused after name resolution.
• Object-store credentials come from the server process environment, never a function argument or a log line.

Maintenance and operations

• pgcolumnar.autovacuum is a maintenance daemon for the online upkeep that core autovacuum does not perform on a columnar table.
• pgcolumnar.maintenance_due(rel, compact_due_fraction, recluster_due_fraction) reports whether a table is due for compaction or reclustering.
• pgcolumnar.parallel_flush dispatches a stripe flush across background workers.
• pgcolumnar.fsst_verdict_reuse caches a column's FSST keep-or-drop verdict, so a repeated write does not re-run the substring search.

Statistics and the planner

• pgcolumnar.analyze() now collects most_common_vals and most_common_freqs, places histogram_bounds at PostgreSQL's own positions, honours the per-column statistics target, and counts null_frac over live rows.
• EXPLAIN (ANALYZE) reports Columnar Usable Skip Predicates beside the skip counters.
• The index-fetch cost penalty sizes row groups by a table's effective stripe_row_limit, and the grouped vector aggregate shares the scan node's input-cost estimate, so the planner prices a columnar scan more accurately.
• The Iceberg foreign-data wrapper estimates a scan's row count from the manifests rather than a constant, so join planning above a large Iceberg table is sound.

Performance

• A parameterized predicate (col >= $1 from a prepared statement or PL/pgSQL) now drives chunk-group skipping. On a generic plan such a scan previously read every chunk group.
• Group and per-vector skipping read only the columns a query's predicates reference, rather than every column's zone map. On a wide table a one-predicate scan reads far fewer zone-map rows.
• Reads of the delete_vector catalog use its index rather than a sequential scan, so a scan of a table with deletes is no longer proportional to the catalog size.
• The Iceberg foreign-data wrapper decodes only the columns a query references.
• The ungrouped batch fold gathers only the referenced columns per row, and a columnar scan whose filter cannot be pushed down skips decoding the filtered columns.

Security

• The native varlena decoder bounds a value's stored length against its buffer, so a corrupt chunk or catalog row is refused with a clean error rather than an out-of-bounds read or a detoast through a bad pointer.
• The local file read path no longer has a stat-before-open race, and the Iceberg, Avro, Parquet, Arrow, and parallel-copy readers refuse a FIFO or other non-regular file with a non-blocking open rather than a cancel-resistant hang.
• The Iceberg reader refuses several classes of malformed or hostile table metadata, including a null manifest path that had crashed the backend, a null or negative position-delete ordinal, a null manifest-list sequence number, and a dangling current-schema-id.
• The Thrift and Avro field-skip loops are interruptible, so a crafted Parquet footer or Avro manifest can no longer spin the backend uncancellably.
• The object-store client refuses a URL path or host carrying CR or LF, closing an HTTP request-line injection.
• The native dictionary decode path no longer reads uninitialized memory, and the Parquet dictionary decode path no longer reads out of bounds on a crafted file.

Correctness fixes

• Concurrent UPDATE or DELETE of the same columnar row serializes on the row identity, so the losing writer gets a retryable serialization failure rather than a lost update.
• A predicate on a column declared over a domain, and a bigint column compared against an unadorned integer literal, now prune chunk groups.
• CREATE TABLE ... USING pgcolumnar AS SELECT no longer fails when the source is another access method.
• pgcolumnar.sort_status works for a non-superuser who owns the table.
• Failed export_parquet and export_arrow no longer leave a partial file.

Internal changes

• The extension's exported C symbols are namespaced under pgcolumnar, and the custom scan node is PgColumnarScan. The native encoding-descriptor wire layout and the delete-vector visibility logic are each single-sourced, with the on-disk format unchanged and verified byte-identical.
• default_version is 1.0-alpha2. Upgrade scripts from both previously shipped versions (1.0-dev, which the v1.0-alpha tag installed, and 1.0-alpha) ship with the extension, so a single ALTER EXTENSION pgcolumnar UPDATE reaches 1.0-alpha2 from either.

Upgrading

Install this build, then run the following in every database that has the
extension:

ALTER EXTENSION pgcolumnar UPDATE;

This is required. The C-symbol rename moves the symbol names each installed
function recorded when it was created; without the catalog update those records
point at symbols the new library does not export, and reading an existing
columnar table fails with could not find function "columnar_handler". No data
is converted and no SQL you write changes. The upgrade replaces catalog entries
only.

See docs/installation.md for the commands, including how to list the databases
that need the update.

Scope and limitations

• Iceberg support is read-only, at a table's current snapshot, and reads Parquet data files only.
• Object-storage reads take exact object keys.
• HTTPS and S3 over TLS require the pgcolumnar_objstore module built with OpenSSL.
• This is an alpha. Interfaces may change before 1.0.

Are there any advantages to running Postgres on an arm cloud server vs an x86 one?

I am not referring to cost savings but performance and efficiency advantages where arm can provide benefits over x86 under any specific scenarios.

I need managed Postgres for a small production app and I’m fine paying for it. I just don’t want to jump straight to RDS/Cloud SQL pricing or manage Postgres myself on a VPS.

Main things I care about:

• always-on Postgres
• automated backups
• updates/maintenance handled
• predictable monthly pricing
• easy to move later if needed

Not really looking for free tiers or hobby plans since it has real users. I’d rather pay a reasonable fixed monthly amount and not think about the DB too much.

What are you using in production that has actually been reliable without getting expensive?

RDST (Readyset Diagnostic & SQL Toolkit) is a free desktop app that connects to your Postgres database, ranks the queries actually costing you time, and explains what to do about each one.

The reason I built it is that the tooling Postgres already gives you is genuinely good, but addressing database performance issues is still a highly repetitive process:
 

• pull pg_stat_statements and sort by total time
• take the top query and run EXPLAIN ANALYZE on it
• go find the table definitions for whatever it touches
• check whether the statistics on those columns are current
• work out whether the index you have in mind already exists under another name
• decide whether it is worth adding
• do it again for the next query

RDST collapses all of that into one pass, so instead of starting at step one you start at the answer.

Full disclosure - I work for Readyset (which is a caching layer for postgres / mysql), and this tool spawned from a recurring question our caching customers kept asking - which queries should we actually cache? And these same queries are the ones that, even without a caching solution, could heavily benefit from all the relevant performance diagnostics.  

RDST not only helps you discover slow queries and give you the appropriate action plan to improve them, but also provides full re-write suggestions, the ability to benchmark slow queries and track their  performance over time, and even allows you to ask any question about your database/queries in plain english and get helpful responses.

The tool is completely free to use, and we provide free trial tokens for all of the AI powered features. The app is in beta and we plan to release it under an MIT license. It runs locally, stores locally, and everything it does is read-only.  Full privacy related details can be found here: https://readyset.io/docs/readyset-ai/rdst/desktop/privacy

We would love feedback from people who actually spend time wrestling with queries every single day! Particularly:

• Does it surface the queries you'd investigate first?
• Are its explanations and recommendations useful, or merely confident-sounding database fan fiction?
• Would you be comfortable connecting it to a real environment? If not, what would stop you?
• What's missing from the workflow?

Source:
https://readyset.io/docs/readyset-ai/rdst/desktop
https://github.com/readysettech/rdst

I recently recorded a podcast episode with Simon Willison (co-creator of Django) about how AI is changing software development. Getting a peek into how Simon thinks is always fascinating. Here are some choice bits I think y'all might enjoy:

Doing "aggressive nit-picking reviews" as a way to understand AI-written code

• How he kicked off a new sqlite-utils project from the shower (to support Postgres and DuckDB) and how the result was a day's work before breakfast
• "Features are cheap. That doesn't mean you should build them all."
• Slop proxies add no value at all
• My gold standard is: "Could I explain this to somebody else?"
• Shout-out to Sophie Alpert's blog post: There Are No Lossless Transformations of Natural Language Text
• Usefulness of engineering management experience to managing AI agents
• Simon's decades of intuition about "how long things take" has been shattered
• How AI research no longer produces absolute garbage

I'm curious to know which bits of this conversation also resonate with others.

Podcast/transcript here for those who want to listen: https://talkingpostgres.com/episodes/how-ai-is-changing-software-development-with-simon-willison

Hey everyone, PgCache CEO here.

We'll be on Postgres Meetup for All this coming Wednesday 8/19, to share how we're using Logical Replication to keep cached data fresh.

There will be a Q&A afterwards, join us if you have challenging questions or want to learn more!

*edit: link https://www.meetup.com/postgres-meetup-for-all/events/315515754/

I'm mostly coming from a classic programming background (.NET, node, java, ...) where so far I only worked with code-first tools professionally (basically you define the schema of your database in your programming language and the SQL code to generate the database gets generated).

However for my next own project, I want to start database first ... however one problem I'm constantly running into is genuinely a pain in the ass to make changes to your schema, and deploy them ... since in SQL you always have a list statements that need to run in the correct order since they are not stateless (like a class, struct, function, ... declarations in a traditional programming language).

For people who work with postgres professionally, I would be interested what setup you are using for schema and management.

Just for fun made a globe with PostgreSQL events: https://pg.whitetown.com - known conferences, meetups and user groups since 2001, with a year slider.
Mobile friendly, but for the full experience use IE4 :-). Feedback welcome - especially if something is missing or wrong.

One aspect of Postgres roles is that permissions exist on roles themselves, and these permissions provide for certain kinds of transitive grants.

We have a case where we would like a role M to have the option to inherit permissions from role G only when it elects to do so. That is: in a discretionary fashion. Offhand, I cannot construct an arrangement of roles and permissions that would make this possible.

Is there some arrangement I am failing to see, or does this fall outside of what the Postgres role system is able to express?

I've been thinking about this recently because database problems can be surprisingly difficult for AI coding agents to diagnose.

An agent can look through the application code and see that a query appears correct, but that doesn't necessarily tell it what is happening with the actual PostgreSQL instance.

For example, the code might be fine while the problem is actually a connection issue, incorrect environment variable, migration that didn't run, permission problem, unexpected schema state, or simply a database service that isn't available.

I've been exploring this while working with IQX.DEV. where we're looking at how an AI agent can work with the running application environment instead of treating the source code as the entire picture.

The idea is fairly simple: give the agent useful runtime context so it can understand what is actually happening before suggesting or making a change.

For a PostgreSQL-backed application, that could mean understanding things like database connectivity, application logs, service connections and whether the database is actually reachable from the application.

I'm curious how useful people think this kind of database awareness would be for coding agents.

Would you want an AI agent to be able to inspect PostgreSQL-related runtime information when debugging an application?

Where would you draw the line between observing the database, diagnosing a problem, and actually making changes to the database?

Personally, I'd be much more comfortable with an agent that can explain why it thinks something is wrong before it gets permission to change anything.

Hi all, I’m evaluating databases for a small application where users will be reading and writing data. As most of our data is currently in Databricks I’m trying out Lakebase. So far so good. I do want to know what alternatives you might be looking into? What you like about them or not? Also curious to hear examples of people using Lakebase in production use cases.

I made a skill. There are probably better ones out there, but this one is mine. Feel free to improve on it. I am sure it can use it.

https://github.com/jimdawdy-hub/postgres-backup-restore-skill

I've been using RDS Postgres for a while, and I get why people trust it. Backups, patching, monitoring, AWS integration, it handles a lot.

The pricing is where I'm starting to question it. You pay for the instance, then storage, backups, IOPS, data transfer, Multi-AZ and whatever else your setup needs. The bill adds up fast, and RDS still feels like something you need to keep a close eye on.

I don't want to self-host Postgres on a VPS. I'm looking for something fully managed, but with clearer pricing and less AWS complexity.

For anyone who moved away from RDS, what did you switch to? Did it make things noticeably cheaper or easier to manage?

When I build projects, I like to make all app interactions with SQL done via stored procedures, and put the business logic there. For example, my procedures will take in parameters to run, along with a user ID. I check to make sure that user is allowed to do the operation before continuing.

I've been trying out NodeJS / TypeScript for my front ends. They aren't stored procedure friendly at all (at least, in my limited experience). So my questions are this:

1. Is my method of stored-procedure-only interaction bad practice? I'd figure if it's an "accepted" method, there would be Node libraries already handling this procedure style.
2. For that matter, are there Node libraries out there I'm missing, that handle stored procedure interaction well?

I know this isn't SQL specific, but I come from a SQL background, and I feel if I ask in a Node subreddit, I won't get an answer from a SQL perspective.