OffNet Newsroom

Daily topic roundup

Database Technology

Wednesday, October 07, 2026 · 8 stories, curated & summarized — click any story for the source.

AWS Database Blog awsdatabase

AWS DMS SQL Server CDC: Least-Privilege Pattern Without Sysadmin

AWS Database Blog outlines a method to run change data capture migrations from self-managed SQL Server using AWS DMS without requiring sysadmin privileges for the endpoint login. The approach relies on certificate-signed wrapper procedures and granular permissions to maintain full CDC functionality while satisfying separation-of-duties compliance. AWS Secrets Manager is integrated to handle credential management securely within this restricted access model.

  • Eliminate sysadmin requirement for DMS endpoint logins on SQL Server sources.
  • Use certificate-signed wrapper procedures to grant minimal necessary permissions.
  • Preserve full CDC capabilities while meeting strict separation-of-duties policies.
  • Integrate AWS Secrets Manager for secure credential handling in the migration workflow.
CHECKLISTSecure DMS CDC SetupEliminate sysadmin requirement for DMS endpoint loginsUse certificate-signed wrapper procedures for permissionsPreserve full CDC capabilities under strict policiesIntegrate AWS Secrets Manager for credentials

PGX Inc. has launched version 1.0 of pgx-bm25, an extension that integrates Okapi BM25 ranked full-text search directly into PostgreSQL as a native index access method. Compatible with PostgreSQL 17 and 18, it operates as bm25_native and leverages standard index scan mechanics to return results ordered by relevance without requiring a separate Sort node. The index resides within the database's own pages, ensuring it is automatically handled by WAL logging, crash recovery, physical replication, and VACUUM processes. This eliminates the need for external search engines or separate runtimes for basic full-text retrieval needs.

  • Native index access method removes dependency on external search engines like Elasticsearch.
  • Results are ordered by BM25 relevance score directly via the index, avoiding extra Sort nodes.
  • Fully integrated with core PostgreSQL lifecycle: WAL, crash recovery, replication, and VACUUM.
  • Supports PostgreSQL 17 and 18; install via CREATE EXTENSION bm25_native.
  • Simplifies architecture by keeping search logic and storage within the database cluster.
TRADE-OFFTraditional vs Native SearchExternal Search EnginesRequires separate infrastructureNeeds complex synchronizationAdds operational overheadpgx-bm25 ExtensionBuilt into PostgresUses native WALSimplifies architecturevs
Planet PostgreSQL database

PostgreSQL 18 Fixes 12-Year Semaphore Calculation Bug

PostgreSQL 18 introduces the num_os_semaphores GUC to explicitly report the OS semaphore count required by the server. This new setting corrects a formulaic error that has persisted in PostgreSQL for twelve years, ensuring accurate resource estimation. The change provides visibility into an often-overlooked operating system constraint for high-concurrency deployments.

  • New GUC num_os_semaphores exposes exact OS semaphore requirements.
  • Fixes a calculation drift present in PostgreSQL for over a decade.
  • Critical for tuning systems hitting OS-level semaphore limits.
  • PostgreSQL 18 is the first version to include this explicit reporting.

Google has released Spanner Omni generally available, enabling its distributed SQL database to operate on-premises, across multiple clouds, or on local laptops. This portability requires replacing hardware-dependent components like Colossus and TrueTime with software-based abstractions for storage and time synchronization. Early assessments indicate that while deployment flexibility is high, practitioners are closely monitoring potential increases in tail latency and operational overhead.

  • Spanner Omni runs on any infrastructure, removing hardware locks for TrueTime and Colossus.
  • No availability SLA is provided; users must self-manage reliability and uptime guarantees.
  • Expect higher tail latency and operational toil compared to native Google Cloud Spanner.
  • Software-based time sync replaces atomic clocks, enabling true multi-cloud portability.

The AWS Database Blog introduces a decision framework for Amazon Neptune that aligns specific availability goals with appropriate architectural patterns. It evaluates options ranging from Multi-AZ and Global Database deployments to write-ahead logs and caching strategies. The guidance helps engineers select the right configuration based on their required recovery time objectives, recovery point objectives, and budget constraints.

  • Maps availability targets like RTO and RPO directly to Neptune architectural choices.
  • Evaluates Multi-AZ and Global Database patterns for cross-region resilience needs.
  • Considers write-ahead logs and caching as part of the broader availability strategy.
  • Helps balance technical resilience requirements against budget limitations.
PostgreSQL News database

pg_plan_filter 1.0.0 released for PostgreSQL 14-18

The pg_plan_filter extension has reached version 1.0.0, enabling administrators to block queries that exceed configured planner cost thresholds before execution. It supports statement-level and transaction-level cost caps, with an option to restrict filtering to SELECT statements only. The module is compatible with PostgreSQL versions 14 through 18.

  • Prevent expensive queries from hitting production by enforcing planner cost limits.
  • Cap total transaction cost to avoid resource exhaustion from long-running batches.
  • Filter can be scoped to SELECT statements only to protect write paths.
  • Available for PostgreSQL 14 through 18 as a loadable module.
TRADE-OFFpg_plan_filter CapabilitiesCost CapsBlock queries exceeding planner costCap total transaction cost limitsScope ControlRestrict filtering to SELECT onlyProtect write paths from limitsvs

Percona's new DBTrail tool enables analytical reporting on MySQL data without executing queries against the primary database server. This approach prevents large scans from evicting hot pages from the buffer pool and stops long-running reads from delaying the purge thread. It also avoids performance degradation caused by temporary table creation during complex aggregations.

  • Preserve buffer pool efficiency by isolating analytical workloads from OLTP traffic
  • Prevent purge thread latency spikes caused by long-running read transactions
  • Avoid temporary table overhead when performing large GROUP BY operations
  • Use DBTrail to offload reporting without impacting application responsiveness
CHECKLISTOffload MySQL Analytics SafelyIsolate analytical workloads from OLTP trafficPrevent purge thread latency spikesAvoid temporary table overheadUse DBTrail for reporting
Planet PostgreSQL database

PostgreSQL Connection Pooling: 5 New Tools Reviewed

Christophe Pettus expands his analysis of PostgreSQL connection poolers by evaluating Odyssey, pgagroal, Supavisor, PgDoorman, and ProxySQL. The post compares these tools against existing options, highlighting their specific capabilities and architectural differences. It also addresses how these solutions integrate with or are already present in various cloud environments.

  • Five specific poolers are analyzed: Odyssey, pgagroal, Supavisor, PgDoorman, ProxySQL.
  • Comparison covers features, performance, and ease of deployment for each tool.
  • Cloud integration status is noted, showing which poolers are natively available.
  • Helps practitioners choose the right pooling strategy for high-concurrency workloads.
↑