Christophe Pettus highlights that PostgreSQL enforces a hard limit of 100 arguments for function calls. Increasing this threshold is not a simple configuration change; it necessitates recompiling and reinstalling every extension on the system to align with the new internal limits.
The 100-argument cap is a hard compile-time limit in PostgreSQL.
Changing the limit requires rebuilding all installed extensions.
Plan downtime and dependency checks before attempting this change.
Verify extension compatibility if you need more than 100 arguments.
The pg_vault_tde extension for PostgreSQL 17 and 18 has released version 1.7.1, addressing a critical authentication flaw in the encrypted_heap table access method. This update corrects the AAD derivation for out-of-line TOAST values, ensuring data integrity during decryption. Consequently, any tables containing TOAST data encrypted by version 1.7.0 or earlier will fail authentication checks until they are exported and re-imported.
pg_vault_tde 1.7.1 fixes AAD derivation for out-of-line TOAST values in encrypted_heap.
TOAST data encrypted with v1.7.0 or earlier fails authentication after upgrading to 1.7.1.
Affected tables must be exported and re-imported to restore access and integrity.
Supports HashiCorp Vault, OpenBao, PKCS#11, HSM, and local PKCS#12 wallets for key management.
Requires PostgreSQL 17 or 18 with OpenSSL 3.x and shared_preload_libraries configuration.
Fleet impact: If you are running PostgreSQL 17/18 with pg_vault_tde, immediately audit for TOAST-heavy tables. You must plan an export/import cycle for affected tables to prevent data unavailability, as the new version's stricter AAD derivation will reject legacy encrypted TOAST chunks.
The AWS Database Blog outlines a tiered alerting strategy for Amazon DocumentDB, organizing CloudWatch metrics into Critical, Warning, and Advisory levels to reduce noise. It details methods for diagnosing slow queries using three distinct analytical approaches and emphasizes proactive monitoring of garbage collection health. This guidance helps prevent minor storage issues from escalating into cluster-wide incidents.
Implement Critical/Warning/Advisory tiers for CloudWatch metrics to prioritize alerts effectively.
Diagnose slow queries using three complementary lenses for deeper performance insights.
Monitor garbage collection health proactively to avoid cluster-wide outages.
Shift from reactive firefighting to structured, tiered observability for DocumentDB.
Percona XtraDB Cluster 8.0 defaults to replication traffic encryption, but legacy clusters may still operate without TLS due to past configurations. To address compliance or audit requirements, administrators can use the pxc-encrypt-cluster-traffic variable to activate encryption dynamically. This approach allows for the implementation of security measures without requiring a disruptive cluster restart.
PXC 8.0 enables replication encryption by default, but existing clusters may lack TLS.
Use the pxc-encrypt-cluster-traffic variable to enable TLS without downtime.
Ideal for meeting sudden compliance mandates or addressing audit findings.
Avoids the operational risk and cost of a full cluster restart.
Percona Operator for PostgreSQL 3.1.0 introduces three key capabilities directly within the custom resource: transparent data encryption, logical replicas, and persistent logging. These features address common compliance and operational needs by ensuring data is encrypted at rest, read workloads can be offloaded without straining the primary node, and logs remain accessible for auditing. The release consolidates these requirements into the operator configuration, simplifying platform reviews and deployment workflows.
Transparent data encryption is now native to the operator, satisfying at-rest compliance requirements without external tools.
Logical replicas allow read scaling off the primary node, reducing contention and improving performance for read-heavy workloads.
Persistent logging ensures audit trails and debug information survive pod restarts, critical for troubleshooting and compliance.
All three features are managed via the custom resource, streamlining configuration and reducing manual infrastructure overhead.
Andrei Lepikhov highlights performance bottlenecks in PostgreSQL's built-in aggregates, particularly with variable-length types like SUM(numeric) where partial aggregation yields limited gains. Built-in functions handle general cases, but ERP systems often use numeric columns with fixed scales, creating inefficiency. The proposed solution involves extensions that tune aggregate behavior to these specific, constrained data conditions for better throughput.
Built-in PostgreSQL aggregates are inefficient for large streams where partial aggregation offers little benefit.
Variable-length types, especially numeric, suffer most from general-purpose handling overhead.
ERP systems typically use fixed-scale numeric columns, allowing for tighter optimization.
Extensions can tailor aggregate logic to specific data constraints, improving performance significantly.
David Wheeler has released the chdb extension, which integrates the chDB library to enable efficient data import and export directly within PostgreSQL. By leveraging an in-process ClickHouse engine, the extension supports a wide variety of data formats stored in cloud buckets like AWS S3. Benchmarks against other extensions such as pg_lake and pg_duckdb demonstrate significant performance gains when handling large datasets from regionally colocated storage.
Leverages in-process ClickHouse engine for faster data processing inside Postgres
Supports import/export from various formats directly on cloud storage systems
Outperforms pg_lake and pg_duckdb in initial benchmarks on NYC Taxi dataset
Simplifies ETL workflows by reducing data movement between services
