Next steps for Postgres pluggable storage

Summary

PostgreSQL pluggable storage would let different tables in one database use storage engines optimized for transactional, analytical, or archival workloads, while allowing developers to build engines in an extensions-like model. PostgreSQL 12 added basic support through refactoring and expanding table access method APIs, initially to enable ZHeap, whose undo log showed promising results and addressed long-term table bloat, but work on ZHeap and TAM appears stalled. The current API has important gaps, including limited index flexibility, all-or-nothing index updates, and row-version identifiers tied to block and offset numbers; available options such as Citus Columnar Storage remain constrained by these limits. OrioleDB's upstreaming has reduced its fork's patchset from about 5,000 lines in PostgreSQL 14 to about 2,000 for PostgreSQL 16, raising the possibility that required changes could land in PostgreSQL 17.

Takeaways

1. 1

   PostgreSQL 12 introduced basic pluggable-storage support through table access method APIs, with ZHeap as the initial goal; ZHeap provided an undo log and addressed long-term table bloat.

2. 2

   The current TAM API limits index flexibility: index updates are all-or-nothing, and row versions must use a block-number and offset-number pair, preventing designs such as index-organized tables and undo-based versioning.

3. 3

   OrioleDB's required fork changes fell from about 5,000 lines for PostgreSQL 14 to about 2,000 for PostgreSQL 16; the remaining work could potentially land in PostgreSQL 17.