OffNet Newsroom

Daily topic roundup

Database Technology

Monday, July 13, 2026 · 7 stories, curated & summarized — click any story for the source.

PostgreSQL News database

PoWA Archivist 5.2.0 Adds PostgreSQL 19 Support

The PoWA team released version 5.2.0 of powa-archivist, the core extension for the PostgreSQL Workload Analyzer. This update introduces compatibility with PostgreSQL 19, including new system views for recovery and lock statistics. The tool continues to provide real-time metrics, charts, and index optimization suggestions across supported PostgreSQL versions.

  • PoWA now supports PostgreSQL 19, essential for early adopters of the latest release.
  • New pg_stat_recovery and pg_stat_lock views enable deeper internal diagnostics.
  • Core workload analysis and index suggestion features remain stable in this update.
  • Upgrade powa-archivist to maintain monitoring coverage on PG19 instances.
CHECKLISTPoWA Archivist 5.2.0 Upgrade GuideUpgrade to PoWA 5.2.0 for PostgreSQL 19 compatibilityUtilize new pg_stat_recovery views for diagnosticsMonitor lock statistics via pg_stat_lock viewsMaintain real-time metrics and index suggestions

RegreSQL 1.0 addresses the limitation of previous tools by validating query execution plans, not just result sets. It leverages real production statistics to catch regressions caused by planner shifts, such as unexpected sequential scans on growing tables. This approach prevents scenarios where tests pass despite significant performance degradation due to data growth or index changes.

  • RegreSQL 1.0 shifts focus from row correctness to execution plan stability.
  • Uses production statistics to simulate real-world query planning behavior.
  • Detects regressions caused by planner switches to sequential scans.
  • Prevents false positives from empty or stale development databases.
  • Essential for maintaining performance as table sizes increase over time.
AWS What's New awsdatabase ↺ since 07-11

AWS DMS Schema Conversion adds offline SQL Server support

AWS Database Migration Service now allows offline schema conversion for Microsoft SQL Server by extracting metadata locally and uploading it to the service. This approach removes the need for direct connectivity, bypassing security reviews, firewall changes, and VPN setups. It delivers identical conversion results to the connected method while accommodating strict security policies that prohibit external tool access to production databases.

  • Extract SQL Server metadata using standard commands in your own environment before uploading.
  • Eliminate delays from security reviews, firewall rules, and VPN configuration for migrations.
  • Achieves the same conversion accuracy as the connected method without live database access.
  • Ideal for production environments with strict policies against external tool connectivity.
HOW IT WORKSOffline SQL Server Migration Steps1Extract metadata locally using standard…2Upload extracted data to AWS DMS3Perform schema conversion in the cloud4Deploy migrated schema to target system
AWS Database Blog awsdatabase ↺ since 07-10

AWS RDS Oracle: Diagnose and resolve replica lag via wait events

This second part of a series on Amazon RDS for Oracle Read Replicas focuses on troubleshooting replication lag. It details methods for monitoring lag using CloudWatch metrics and database views, followed by an analysis of common root causes through wait event identification. The post provides actionable steps to resolve performance issues causing delays in replica synchronization.

  • Monitor replication lag using Amazon CloudWatch metrics and specific database views for real-time visibility.
  • Identify root causes by analyzing database wait events to pinpoint bottlenecks in the replication stream.
  • Apply targeted troubleshooting steps to resolve performance issues affecting read replica synchronization.
  • Part 2 builds on Part 1's configuration optimizations with deeper diagnostic and resolution techniques.

Fleet impact: For DBAs managing RDS for Oracle fleets, this guidance is critical for maintaining read scalability without data staleness. Prioritize wait event analysis during lag spikes to distinguish between I/O contention and network/redo transmission issues, ensuring you apply the correct remediation rather than blindly scaling instances.

Percona Blog database ↺ since 07-11

Percona builds experimental MySQL 9.7 with DuckDB storage engine

Percona has released an experimental MySQL 9.7 build featuring a DuckDB storage engine that routes analytical queries from marked tables directly to DuckDB. This approach allows analytical workloads to run on the same server and connection as transactional data without duplicating the dataset. Early TPC-H benchmarks at scale factor 10 show InnoDB timing out on six queries and taking 1317 seconds on others, highlighting the performance gap DuckDB aims to fill.

  • Experimental MySQL 9.7 build enables ENGINE=DuckDB for analytical offloading from InnoDB.
  • Analytical queries run in-process without data duplication or separate infrastructure.
  • InnoDB struggled with TPC-H Q6-Q22 timeouts and high latency at scale factor 10.
  • Validates hybrid transactional/analytical processing within a single database instance.
BY THE NUMBERSDuckDB Beats InnoDB Latency1317 secondsInnoDB query timeTimeouts on 6 of 17 TPC-H queries
AWS Database Blog awsdatabase ↺ since 07-10

AWS RDS for Oracle: Reduce Replication Lag via Redo Compression

AWS Database Blog details how enabling redo compression for Amazon RDS for Oracle replicas can optimize and reduce replication lag. This first part of a series focuses specifically on the configuration and impact of the redo compression feature. A subsequent post will cover monitoring, troubleshooting, and resolution techniques for replication lag.

  • Enable redo compression on RDS for Oracle replicas to minimize replication lag
  • Part 1 covers the mechanics of redo compression; Part 2 addresses monitoring and troubleshooting
  • Redo compression reduces network payload, potentially improving stream replication performance
  • Review AWS documentation for specific parameter settings required to activate this feature

Fleet impact: For Oracle ExaCC/RAC fleets replicating to RDS for Oracle, enabling redo compression can significantly reduce WAN bandwidth usage and lag during peak loads. Verify that the target RDS instance supports the feature and test compression ratios in a non-prod environment to gauge network impact before production rollout.

GitHub Trending (daily) githubrepos ↺ since 07-10 ⚠ unverified date/source

pgrust: Rust-based Postgres rewrite passes 100% of regression tests

The pgrust project, a Postgres rewrite in Rust, now passes 100% of the Postgres 18.3 regression suite, covering over 46,000 queries. It maintains disk compatibility with existing Postgres data directories, allowing systems to boot directly from them. The current architecture uses a thread-per-connection model, replacing the traditional process-per-connection approach.

  • pgrust achieves full regression test parity with Postgres 18.3, ensuring behavioral compatibility.
  • Disk compatibility allows migration or side-by-side usage with existing Postgres data directories.
  • Shifts from process-per-connection to thread-per-connection, potentially impacting concurrency models.
  • Leverages Rust and AI-assisted development to explore deeper server internals changes.
BY THE NUMBERSFull Test Parity Achieved100%Regression tests passedPostgres 18.3 suite, 46,000 queries