Database Technology

Zhang Chen, a PostgreSQL ACE, details the evolution of PDU (PostgreSQL Data Unpacker) from traditional offline extraction and WAL mining to advanced techniques like fragment scanning. This progression enables database recovery even when the data dictionary is missing or corrupted. The article highlights the technical depth required to position oneself as a specialized recovery expert in the PostgreSQL ecosystem.

• PDU capabilities have expanded from WAL mining to fragment scanning for deeper recovery.
• Recovery is now possible without a data dictionary, addressing critical corruption scenarios.
• Specialized titles like 'Recovery Expert' reflect deep, niche technical proficiency.
• Offline extraction remains a foundational technique alongside newer scanning methods.

The PostGIS team has issued the second beta of version 3.7.0, targeting PostgreSQL 14 through 19 beta2. This update includes bug fixes and enhancements following the previous beta release. Users requiring full feature parity, particularly for geometry processing and SFCGAL operations, must upgrade to GEOS 3.15+ and SFCGAL 2.3.0+ respectively.

• Requires PostgreSQL 14-19beta2 and GEOS 3.10+ for baseline operation.
• Enable all features by upgrading to GEOS 3.15+ and SFCGAL 2.3.0+.
• Includes bug fixes and enhancements since PostGIS 3.7.0beta1.
• Compatible with PostGIS Raster, Topology, and SFCGAL extensions.

Since PostgreSQL 10, the integer_datetimes configuration parameter has been fixed at true, yet client connections continue to receive it in the startup message. This reflects a historical shift in how the server represents temporal data, moving away from floating-point datetime implementations. The announcement highlights that this GUC is effectively a no-op for modern deployments while remaining part of the protocol handshake.

• The integer_datetimes GUC has been hardcoded to true since PostgreSQL 10
• Client libraries still receive this parameter during connection startup
• No action required for modern PostgreSQL 10+ deployments
• This GUC is a historical artifact with no functional impact today

Amazon DynamoDB introduces built-in vector similarity search capabilities, eliminating the need for separate vector databases in many architectures. The update allows developers to store and query vector embeddings directly within DynamoDB tables, streamlining applications that require semantic search functionality. Metering details for vector operations are included to help manage costs associated with this new feature.

• DynamoDB now handles vector similarity search natively, reducing architectural complexity.
• Eliminates the need for maintaining a separate vector database for many use cases.
• Vector search operations are metered separately, impacting cost models.
• Enables semantic search applications using tools like Amazon Bedrock embeddings.

Percona tested its DuckDB-based MySQL storage engine using a 500GB TPC-H dataset comprising three billion lineitem rows on an 80-core, 187GB RAM server. The evaluation compared the new MySQL+DuckDB engine against standard InnoDB and plain DuckDB to measure performance at scale. The results highlight how the hybrid engine handles massive analytical workloads compared to traditional row-store and columnar approaches.

• DuckDB MySQL engine supports 3B+ rows on standard server hardware without external clusters.
• Direct comparison with InnoDB shows potential performance shifts for analytical MySQL workloads.
• Validates columnar processing capabilities within the MySQL ecosystem for heavy analytics.
• Memory footprint of 187GB RAM supports large-scale in-memory operations effectively.

Andrei Mironov details a method for implementing and verifying Row-Level Security in PostgreSQL specifically for AI agent workloads. The approach utilizes non-owner roles, FORCE RLS, explicit policies, and controlled writes to ensure strict access boundaries. It emphasizes the importance of running denial tests to validate that security constraints function as intended.

• Use non-owner roles to isolate AI agent access from database owners.
• Enable FORCE RLS to ensure policies apply even to table owners.
• Implement explicit policies to define granular read/write permissions.
• Conduct denial tests to verify security boundaries are enforced.