Database Technology

Percona Server for MySQL 9.7.2-2 introduces DISTANCE() and VECTOR_DISTANCE() functions, enabling direct SQL-based vector similarity scoring. These functions support COSINE, EUCLIDEAN, MANHATTAN, and DOT metrics, allowing embeddings to be ranked or filtered without external services. While ANN indexing remains a future milestone, this update provides the immediate compute primitive for similarity operations.

• DISTANCE() enables SQL-native vector ranking using COSINE, EUCLIDEAN, MANHATTAN, or DOT metrics.
• Eliminates need for external vector DBs for basic similarity scoring and filtering.
• Provides foundational layer for future ANN indexing support like HNSW and IVF.
• Allows embedding comparison directly within MySQL queries for application logic.

Uber has updated M3DB shard placement by introducing fixed-size subclusters to contain the blast radius of node failures, maintenance windows, and scaling events. This architecture bounds shard dependencies and maintains replica isolation, preventing cascading issues across the cluster. A greedy algorithm handles shard migrations directly, eliminating the need for a separate rebalancing pass and reducing unnecessary data movement.

• Fixed-size subclusters contain failure impact, reducing blast radius during node outages or maintenance.
• Greedy migration algorithm avoids separate rebalancing passes, lowering operational overhead.
• Replica isolation is preserved, ensuring shard dependencies remain bounded and predictable.
• Unnecessary data movement is minimized, improving efficiency during cluster scaling events.

Bruce Momjian argues that non-volatile memory (NVM) could eliminate the complexity of current durability mechanisms like the Write-Ahead Log (WAL). Since CPU-accessible memory is currently volatile, Postgres relies on OS-accessible storage to ensure data persistence. NVM would allow durable storage to reside directly in CPU-accessible memory, potentially streamlining how relational databases guarantee ACID properties.

• NVM could replace the need for separate durable storage layers for WAL.
• Architecture shifts from volatile RAM + non-volatile disk to unified NVM.
• Potential simplification of database engine complexity and durability guarantees.
• Core ACID properties rely on current split-storage models that NVM might unify.

AWS demonstrates a three-tier membership lookup pattern combining Amazon ElastiCache for Valkey, an exact-match cache, and Aurora PostgreSQL as the source of truth. This architecture delivers sub-millisecond decision times at peak throughput while eliminating the risk of false positives inherent in standard Bloom filters. The solution ensures correctness by validating potential matches against the relational database before accepting a result.

• Eliminates false-positive risk by validating Bloom filter hits against a relational source of truth.
• Achieves sub-millisecond lookup latency suitable for high-throughput production workloads.
• Uses a three-tier design: Valkey for probabilistic filtering, exact cache, and Aurora PostgreSQL.
• Provides a correctness-safe alternative to standard probabilistic data structures.
• Integrates AWS managed services for simplified deployment and management.

Fleet impact: For fleets using Aurora PostgreSQL, this pattern offers a robust way to offload expensive membership checks to ElastiCache for Valkey without compromising data integrity. Review your read-heavy workloads for opportunities to implement this three-tier approach to reduce database load and improve latency, ensuring your caching layer includes a fallback validation step to handle any theoretical false positives.

Mark Wong demonstrates a systematic approach to sizing an OLTP workload on AWS EC2 using DBT-5, a TPC-E-like benchmark. He leverages Claude Fable 5.1 to generate a mechanical test plan, starting with a minimum database size of 5,000 customers and incrementally increasing user load. Initial configuration adjustments include pre-setting shared_buffers and max_wal_size, with further tuning planned after characterizing system behavior.

• Use AI tools to generate systematic, mechanical test plans for workload sizing.
• DBT-5 serves as a practical TPC-E-like benchmark for OLTP sizing exercises.
• Initialize with minimum valid database size (e.g., 5,000 customers) before scaling.
• Iteratively increase user load starting from 1 user to observe system behavior.
• Pre-configure known critical settings like shared_buffers and max_wal_size early.

Mikhail Shytsko demonstrates that PgBouncer in transaction mode can assign a connection from one tenant to a subsequent client, causing the second client to see the first tenant's rows. This occurs because the MCP protocol lacks its own session management, meaning agent tool calls arrive without proper context isolation. The standard practice of injecting tenant keys via session variables fails when connections are recycled across tenants.

• PgBouncer transaction mode reuses connections across different logical users, breaking tenant isolation.
• MCP protocol agents lack inherent session state, relying on the underlying DB connection for context.
• RLS policies reading session variables are vulnerable when the session variable is stale or misassigned.
• Do not rely on session-level SET commands for tenant identification in pooled environments.
• Verify pooler configuration and agent connection handling to prevent data leakage between tenants.

Fleet impact: For DBAs managing multi-tenant PostgreSQL fleets with PgBouncer, this is a critical security flaw. Ensure your pooler is not using transaction mode for tenant-isolated applications, or switch to connection pooling with explicit tenant context passing. Audit RLS policies to ensure they do not rely solely on session variables that can be overwritten by pooled connections.