Postgres Weekly — 2026-04, Week 14
Editor’s Note
PostgreSQL continues expanding its capabilities with native temporal SQL support arriving in version 19, while practitioners grapple with long-standing collation stability challenges that have quietly corrupted indexes since 2018. This week also brings attention to filesystem abstractions, kernel-level performance regressions, and emerging Protobuf serialization alternatives.
Top Stories
PostgreSQL 19 Introduces Native Temporal DML Operations
PostgreSQL 19 might add UPDATE/DELETE FOR PORTION OF syntax, enabling developers to perform temporal updates and deletes directly on range and multirange columns. Committed by Peter Eisentraut on April 1st, this implementation brings SQL:2011 temporal features into core PostgreSQL without requiring extension dependencies. The feature extends standard DML commands to operate on time-bounded data segments, simplifying architectures that track valid-time or application-time periods within the database layer. The change has been documented with implementation details for early adopters.
Collation Instability Threatens Index Integrity Across PostgreSQL Deployments
A glibc update released in 2018 altered Unicode collation behavior, silently invalidating text indexes in existing PostgreSQL installations that rely on OS-provided sorting rules. PostgreSQL 17 introduced a built-in locale provider that eliminates this dependency, offering stable collation semantics independent of system library changes. However, PostgreSQL 18 still defaults to glibc, leaving many production systems vulnerable to index corruption when underlying libraries are updated. Practitioners should evaluate the --locale-provider=builtin configuration option to ensure long-term collation stability, particularly in environments with OS-managed package updates. Further analysis details the scope of the issue.
TigerFS Mounts PostgreSQL as FUSE Filesystem
The TigerFS project demonstrates PostgreSQL’s extensibility by implementing a FUSE-based filesystem layer directly on top of the database. This approach abstracts file operations into SQL storage primitives, enabling use cases where file metadata and content benefit from transactional semantics and query capabilities. While not suitable for high-throughput file workloads, the project illustrates PostgreSQL’s adaptability beyond conventional database patterns. The implementation is available on GitHub for evaluation.
Linux 7.0 Triggers PostgreSQL Performance Regression
AWS engineering has identified a 50% performance degradation in PostgreSQL workloads running on Linux kernel 7.0. Kernel mailing list discussions suggest the fix will require substantial changes, indicating potential deployment delays for production systems planning kernel upgrades. Teams operating PostgreSQL on recent kernel versions should monitor upstream development and consider deferring upgrades until patches are integrated. The issue was initially reported with confirmation from AWS contributors.
Performance and Benchmark Insights
The pgproto extension for native Protobuf support in PostgreSQL reports 65% storage reduction compared to JSONB and 5.5x faster retrieval than relational JOINs for structured binary data workloads. The extension is available for review. Separately, PostgresBench offers a reproducible benchmarking framework for evaluating managed PostgreSQL services with standardized workloads and metrics, documented here.
Worth Reading
- Tuning Postgres VACUUM — Operational guidance for optimizing autovacuum behavior in production environments.
- Patroni Cascading Replication with Standby Cluster — Configuration patterns for multi-tier replication topologies.
- Three Years of Building a PostgreSQL Consultancy — Business and technical insights from consulting practice.