Database Technology

The author argues that while storage components like queues and vector stores have moved into PostgreSQL, the API tier has not. The proposal is to keep the network edge for authentication and HTTP adaptation while pushing the transactional boundary into the database. This approach leverages PostgreSQL’s existing authority to make every declared outcome of an operation provable within the same transaction.

• Storage consolidation into Postgres is complete for queues, caches, and search indexes.
• API tiers should retain network edge responsibilities like auth and HTTP adaptation.
• Transactional boundaries belong in the database to ensure provable outcomes.
• Debate over API movement often focuses on the wrong architectural boundary.

Amazon Web Services published guidance on preventing out-of-memory events and excessive disk spilling in RDS and Aurora for PostgreSQL. The blog details how PostgreSQL allocates memory, methods to identify memory-intensive queries, and steps to diagnose and recover from OOM incidents. This resource aims to help engineers mitigate common production failures related to memory consumption.

• PostgreSQL OOM and disk spilling are frequent production issues on RDS and Aurora PostgreSQL.
• The guide explains internal memory allocation mechanisms to help pinpoint consumption sources.
• Techniques provided for identifying and optimizing memory-intensive queries are included.
• Recovery and prevention strategies for OOM events are detailed for both engine types.

Fleet impact: For DBAs managing RDS PostgreSQL and Aurora PostgreSQL fleets, this guide offers critical strategies to tune memory-intensive workloads and prevent service disruptions from OOM kills. Review the diagnostic steps to proactively identify queries causing excessive disk spilling, which can degrade performance and stability in your production environment.

Amazon Aurora PostgreSQL now supports binary quantization combined with HNSW indexes to handle hundreds of millions or billions of vectors. This approach allows for significant scaling of vector search workloads while maintaining practical recall rates through reranking techniques. The guidance covers index sizing strategies and validation methods to ensure performance meets operational requirements.

• Binary quantization enables scaling pgvector to billions of vectors on Aurora PostgreSQL
• Combine with HNSW and reranking to balance speed, recall, and storage efficiency
• Follow practical guidance on index sizing to prevent performance degradation
• Validate recall metrics carefully to ensure accuracy meets application thresholds

Fleet impact: For Aurora PostgreSQL fleets, this feature allows you to reduce storage costs and improve query latency for large-scale vector workloads by switching to binary quantization. Monitor recall rates closely, as aggressive quantization can impact search accuracy, and plan index re-creation if vector dimensions or data volumes shift significantly.

Percona has introduced gcache-inspector to replace guesswork in sizing the Galera write set cache. The tool allows engineers to inspect actual write set sizes rather than relying on peak load estimates. Accurate sizing helps minimize state transfer duration and prevents performance degradation during cluster maintenance.

• Replace capacity planning guesswork with concrete write set size data
• Reduce state transfer time by right-sizing the gcache parameter
• Prevent cluster performance drops during maintenance windows
• Tool aids in avoiding long state transfers on reduced compute

Fleet impact: For ExaCC/RAC and Aurora users, this highlights the critical importance of accurate write-set sizing in Galera-based clusters. Ensure gcache size is tuned based on actual write set metrics to prevent prolonged state transfers that can impact cluster stability during node failover or maintenance.