OffNet Newsroom

Daily topic roundup

Database Technology

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

Share this roundup on LinkedIn Full edition
InfoQ generaldevops

Amazon Acquires DuckLabs, Integrates DuckDB into Aurora PostgreSQL

Amazon has acquired DuckLabs, the creators of the analytical database DuckDB, with original co-founders continuing to lead the team under AWS. While DuckDB remains open-source, the acquisition immediately enables a DuckDB-powered feature within Amazon Aurora PostgreSQL. This move signals AWS's intent to embed high-performance analytical capabilities directly into its managed relational services.

  • DuckDB remains open-source despite the Amazon acquisition
  • Original founders Mühleisen and Raasveldt retain leadership under AWS
  • Aurora PostgreSQL now features DuckDB-powered analytical capabilities
  • AWS is embedding columnar analytics into managed OLTP databases

Fleet impact: Aurora PostgreSQL users gain native analytical acceleration via DuckDB integration, potentially reducing reliance on external OLAP pipelines. DBAs should evaluate how this feature impacts query execution plans and storage overhead in existing Aurora clusters.

Read at source →
The Register general

Postgres 19 delayed to November as AI code reviews uncover excessive bug volume

The PostgreSQL 19 release has been pushed back to November after automated AI code review tools identified a volume of defects that the core developer team could not address within the original timeline. In response to the surge in reported issues, maintainers have reverted up to ten planned features to stabilize the codebase. The team attributes the delay to the superior detection capabilities of modern tooling rather than a decline in developer quality or reliance on vibe coding.

  • Postgres 19 release window shifts to November due to unresolved defect backlog.
  • Up to ten features have been reverted from the upcoming release to stabilize the core.
  • AI-driven static analysis is outpacing human capacity to remediate findings.
  • Core devs clarify that tooling precision, not developer error, drove the delay.

Fleet impact: Delaying the upgrade path to Postgres 19 extends the support window for existing RDS/Aurora versions, providing additional time for regression testing. DBAs should monitor release notes for the specific reverted features to ensure no planned migrations or application dependencies rely on functionality that may be cut or delayed.

Read at source →
AWS Database Blog awsdatabase

Sequelize ORM on Aurora DSQL: UUIDs, IAM, and Optimistic Concurrency Patterns

AWS demonstrates how to integrate Sequelize ORM with Amazon Aurora DSQL for Node.js applications. The guide highlights necessary adaptations, including UUID-based primary keys and IAM authentication via the DSQL connector. It also details handling DDL execution individually and implementing optimistic concurrency control with retry logic.

  • Use UUID primary keys for Aurora DSQL compatibility with Sequelize
  • Integrate IAM authentication using the Aurora DSQL connector
  • Execute DDL statements individually rather than in batches
  • Implement optimistic concurrency control with retry logic for conflicts
Read at source →
PostgreSQL News database

pg_hint_plan v1.9.0 Adds PostgreSQL 19 Support and Path Generation Strategies

The pg_hint_plan extension has released version 1.9.0, introducing compatibility with PostgreSQL 19 and support for path generation strategies (PGS). This major update also delivers bug fixes and improvements to the existing hinting framework. Minor releases have been issued concurrently for PostgreSQL 14 through 18 to maintain stability across older versions.

  • PostgreSQL 19 users must upgrade to pg_hint_plan 1.9.0 for compatibility
  • New path generation strategies (PGS) allow more granular control over plan creation
  • Backward compatibility maintained via v1.8.1 (PG 18) and v1.7.2 (PG 17)
  • Extension relies on SQL comments for hints; review existing query annotations after upgrade

Fleet impact: For AWS Aurora PostgreSQL clusters, verify if the pg_hint_plan extension is enabled and tested against the new PGS features before upgrading to PostgreSQL 19. Oracle ExaCC users running PostgreSQL in containers or side-by-side deployments should check compatibility matrices, as hint behavior changes in v1.9.0 may impact execution plans for critical workloads.

CHECKLISTUpgrade Checklist for pg_hint_planUpgrade to v1.9.0 for PostgreSQL 19 supportExplore new path generation strategies for controlReview existing SQL comment hints after upgradeEnsure backward compatibility with older versions
Read at source →
Percona Blog database

Percona mongo-health tool leverages FTDC for retrospective MongoDB analysis

Percona introduced mongo-health, a utility designed to analyze MongoDB Full Time Diagnostic Data (FTDC) for historical performance investigations. The tool addresses scenarios where application teams report past latency issues that did not trigger real-time alerts. By parsing the diagnostic.data samples recorded by mongod every second, it enables engineers to reconstruct performance states from specific past windows.

  • Enables retrospective analysis of MongoDB performance using existing FTDC logs
  • Resolves 'slow yesterday' tickets without requiring real-time alerting coverage
  • Leverages the 1-second metric sampling inherent to mongod diagnostic.data
  • Provides a structured workflow for diagnosing intermittent latency issues
HOW IT WORKSMongo Health Analysis Workflow1Receive historical latency report2Access FTDC diagnostic.data logs3Parse 1-second metric samples4Reconstruct past performance state5Identify root cause
Read at source →
Percona Blog database

Linux kernel optimization triggers unexpected disk write spikes in PXC 8.0

A Percona case study reveals that upgrading PXC from 5.7 to 8.0 can cause sporadic, high-volume disk writes despite unchanged workload parameters. The root cause is linked to a specific Linux kernel improvement that interacts differently with Galera-based replication mechanisms. This highlights how underlying OS optimizations can inadvertently alter I/O behavior in distributed database clusters.

  • Kernel updates can change I/O patterns in Galera clusters even without config changes
  • PXC 8.0 upgrades may expose latent write amplification issues from kernel optimizations
  • Monitor disk I/O bursts post-upgrade, not just CPU or query latency
  • Reproduce upgrade scenarios in staging to catch kernel-related regressions

Fleet impact: While this specifically affects PXC/Galera, DBAs running Aurora or RDS should remain vigilant: kernel-level I/O scheduler changes in newer Linux distributions can similarly alter write patterns for InnoDB-based engines, potentially impacting IOPS provisioning and storage performance on RDS instances.

CHECKLISTMitigating Kernel-Induced I/O SpikesMonitor disk I/O bursts after upgradesReproduce scenarios in staging environmentsCheck for latent write amplification issuesDo not rely solely on CPU metrics
Read at source →
Planet PostgreSQL database

PostgreSQL Planner: random_page_cost Misnomer and Index Correlation

Christophe Pettus argues that the name random_page_cost is misleading because the PostgreSQL planner actually charges this cost per index page based on the degree of index correlation, not purely on randomness. This distinction highlights how the optimizer weighs physical data layout against index structure when estimating access costs.

  • The term random_page_cost is a misnomer; it applies to index pages
  • Planner costs depend on index correlation, not just I/O randomness
  • Understanding correlation helps explain unexpected plan choices
  • Reviewing correlation stats may clarify cost estimates for index scans

Fleet impact: For Aurora PostgreSQL and RDS fleets, review pg_stats correlation for hot tables to ensure planner costs align with actual SSD I/O behavior, potentially adjusting random_page_cost or relying on correlation stats to avoid inefficient sequential scans.

TRADE-OFFMisleading Name vs Actual LogicImplied MeaningPurely random I/O accessIgnores physical layoutAssumes scattered dataActual BehaviorCharges per index pageWeighs index correlationConsiders physical data layoutvs
Read at source →
GitHub Trending (daily) githubrepos ⚠ unverified date/source

XERJ: Autoindexing local AI search cuts token costs and replaces ElasticSearch

XERJ introduces an autoindexing engine designed to optimize AI agent data retrieval by indexing code, docs, and logs locally. It claims to reduce token consumption by 40x compared to grep while serving as a durable, cost-effective alternative to ElasticSearch for RAG and agent memory tasks.

  • Reduces AI token waste by indexing data locally instead of relying on grep-style file scanning
  • Supports diverse inputs including code, PDFs, logs, and documentation for unified search
  • Positioned as a low-cost alternative to ElasticSearch with claimed 10x infra savings
  • Enables agents to reference open-source repositories for code reuse via automated indexing
THE SHIFTLocal Indexing Efficiency GainGrepSTANDARD SEARCH40xTOKEN SAVINGSLocal autoindexing drastically cuts token usage
Read at source →
↑