The Table Access Method API has been in PostgreSQL since version 12. For most of that time it has been a quiet piece of infrastructure with very little extension activity attached to it — the kind of API that gets a paragraph in the docs, an enthusiastic conference talk, and then five years of silence.
That is changing.
In the last month, two TAM-shaped extensions shipped substantial releases. storage_engine 1.0.7 adds column-oriented compressed and row-compressed access methods for PG 16–18. pg_sorted_heap 0.13.0 provides a physically sorted heap with zone-map pruning and a planner-integrated vector search hook. Neither is going to displace the default heap tomorrow. Both are doing something interesting enough to look at.
The Original Promise, and Why It Stalled
The original promise of the TAM API was that storage layouts could be swapped per-table without touching the rest of the planner and executor. The practical reality has been less clean.
The TAM interface assumes a tuple-shaped record at several points, which is fine for row-store variants and uncomfortable for columnar. Cost estimation does not, by default, know anything about your custom storage’s access patterns, so the planner happily produces sequential scan plans against layouts that should be doing zone-map pruning instead. Most early TAM extensions either accepted the planner cost (slow plans) or shipped extension-specific planner hooks (a maintenance burden, and one that breaks every major release). Neither outcome inspired a wave of follow-on work.
What is different now is that the cost of shipping a planner hook in an extension has dropped, and the appetite for it has gone up.
What pg_sorted_heap Is Actually Doing
The interesting thing about pg_sorted_heap is that it integrates a planner hook for both range and vector-similarity queries directly into the access method. The heap is physically sorted by a user-specified key. Zone maps over that key are maintained alongside the heap. The planner is told about both.
A range query on the sort key prunes whole zones at scan time without an index. A nearest-neighbor query in the vector domain uses the same machinery as a coarse first pass, then refines. This is a real architectural pattern — it shows up in DuckDB, ClickHouse, every modern Parquet reader, and the early pg_lake extension code — finally arriving in stock PostgreSQL via a TAM.
Whether the implementation is solid is a separate question. The 0.13.0 release is early. But the design is the right design.
What storage_engine Is Doing Instead
storage_engine 1.0.7 is doing something different and less novel, but more immediately useful. The colcompress access method packs columns into compressed runs and pays the unpacking cost on read. The rowcompress access method does block-level compression with a regular row layout on top.
Both are bounded experiments. Neither is going to be your primary OLTP table. Both are useful in specific places where heap and TOAST are not doing what you want. If you have wide append-mostly tables with high-cardinality varchar columns and you have been talking yourself into building a separate analytics replica, look at this before you do.
What Happens Next
The thing to watch over the next year is whether the in-core columnar work proposed for PG19 / PG20 and the TAM extension ecosystem converge or diverge.
The community direction is broadly toward more pluggability — finer-grained TAM hooks, planner integration points that do not require parsing every patch on pgsql-hackers, a real story for cost estimation that custom storage can plug into. The vendor direction (Snowflake, Databricks, Microsoft, all with bespoke storage layers underneath their Postgres-shaped products) is broadly away from it, because their differentiation lives below the TAM line and pluggability dilutes the moat.
Whichever side wins the next two years of architectural mindshare will decide what “Postgres” means in 2028. I have a preference. You can guess what it is.
Today the practical answer is: run the benchmarks. Both extensions have stable enough releases that you can. The TAM era is no longer hypothetical.