Database Technology

Amazon Aurora DSQL now supports declaring foreign key constraints on both new and existing tables. This feature enforces referential integrity by rejecting writes that would leave references to non-existent rows. Administrators can define deletion and update behaviors using standard options like CASCADE, RESTRICT, and SET NULL.

• Enforces referential integrity natively in the serverless distributed engine.
• Applies to existing and new tables across all supported AWS Regions.
• Supports standard SQL actions: NO ACTION, RESTRICT, CASCADE, SET NULL, SET DEFAULT.
• Prevents orphaned records without requiring application-level validation logic.

Percona evaluated performance changes across three 2026 minor releases of Percona Server for MySQL 8.4, specifically versions 8.4.8-8, 8.4.10-10, and 8.4.11-11. The investigation focuses on quantifying improvements in both read and write throughput as the software progressed through the year. This data helps determine if upgrading within the 8.4 branch yields tangible efficiency benefits.

• Three specific 2026 versions were benchmarked for read/write performance deltas.
• Data confirms whether incremental 8.4 updates deliver measurable speed gains.
• Use these benchmarks to justify patching or minor version upgrades in production.
• Focuses on throughput metrics relevant to high-traffic MySQL workloads.

Percona introduces vector-bench, a tool designed to standardize vector search benchmarking by addressing the lack of reproducibility in industry reports. The utility allows practitioners to select specific database engines and execute consistent tests to verify performance claims. This effort aims to replace vague marketing numbers with actionable, checkable data for vector index comparisons.

• Industry vector benchmarks often lack reproducibility and missing context.
• vector-bench enables side-by-side testing across multiple database engines.
• Focus on reproducible metrics rather than isolated high-performance claims.
• Tool helps validate vector search performance for specific workloads.

Postgres has become the default choice for new projects and AI backends, yet migrating between providers remains deceptively complex. This analysis highlights the hidden risks of vendor lock-in that turn straightforward migrations into difficult puzzles. The focus is on identifying proprietary extensions and configuration differences that impede portability.

• Postgres popularity masks migration complexity caused by cloud-specific proprietary features.
• Vendor lock-in often stems from hidden extensions not present in standard distributions.
• Architecting for portability requires auditing dependencies before committing to a provider.
• AI and greenfield projects are particularly vulnerable to subtle compatibility traps.

Ismaël Mejía demonstrates running DocumentDB, a MongoDB-compatible layer built on PostgreSQL, using the pglayers-azure container image. The setup exposes a gateway on port 10260 that translates the MongoDB wire protocol, allowing standard drivers like pymongo to interact with PostgreSQL as if it were MongoDB. The guide covers end-to-end connectivity and highlights a common authentication pitfall regarding password handling.

• MongoDB clients connect via port 10260 while PostgreSQL listens on 5432 within the same container.
• pglayers-azure mirrors open-source extensions found in Azure Database for PostgreSQL.
• BSON support and full CRUD operations are enabled through the DocumentDB extension.
• Watch for a specific password authentication quirk that often trips up new users.