OffNet Newsroom

Daily topic roundup

Database Technology

Tuesday, September 01, 2026 · 5 stories, curated & summarized — click any story for the source.

Share this roundup on LinkedIn Full edition
AWS Database Blog awsdatabase

Resolve circular role dependencies before upgrading RDS/Aurora PostgreSQL

Major version upgrades to PostgreSQL 15 or later in RDS and Aurora can stall or roll back if circular role dependencies exist. AWS provides a specific pre-upgrade query to detect these problematic configurations. Resolving these dependencies beforehand ensures a smooth upgrade path without interruption.

  • Upgrades to PostgreSQL 15+ may fail due to circular role dependencies
  • Run the provided pre-upgrade query to detect existing cycles
  • Clear identified dependencies before initiating the major version upgrade
  • Pre-check prevents automatic rollback and service interruption

Fleet impact: RDS/Aurora PostgreSQL DBAs must run the pre-upgrade detection query before scheduling any major version upgrade to PostgreSQL 15+. Circular role dependencies will cause upgrade failures or rollbacks, so identifying and resolving them is a critical prerequisite step.

Read at source →
Planet PostgreSQL database

PostgreSQL Read-Your-Own-Writes Lag on Replicas

Modern frontends often query replicas immediately after a write, causing data to vanish briefly if replication lag exists. This issue is exacerbated by parallel cache invalidation and collaborative features that accelerate user interaction speeds. The problem highlights the risk of eventual consistency in high-performance architectures where replicas are not guaranteed to be up-to-date with the primary.

  • Replica lag can cause newly written data to disappear from user views momentarily.
  • Fast frontends and parallel cache invalidation amplify this consistency gap.
  • Collaborative apps face worse symptoms due to higher write frequency.
  • Read-your-own-writes requires explicit handling, not just default replication.
Read at source →
Percona Blog database

Rotate X.509 Certs in Percona Server for MongoDB with Minimal Downtime

Expired TLS certificates block new client connections and break internal authentication for replica set or sharded cluster members using X.509. This guide details a same-CA renewal process, issuing replacement leaf certificates for servers, members, and clients. The approach is designed to maintain service continuity during the rotation.

  • Expired certs halt client access and internal member authentication in X.509 clusters.
  • Same-CA renewal simplifies the process by reusing the existing certificate authority.
  • Replace server, member, and client leaf certificates to restore full connectivity.
  • Follow the specific rotation steps to minimize service interruption during updates.
CHECKLISTX.509 Certificate Rotation StepsIssue replacement leaf certificates using the same CAUpdate server certificates on all cluster nodesRefresh member certificates for replica or shard setsRotate client certificates to restore authenticationVerify connectivity and monitor for errors
Read at source →
Planet PostgreSQL database

PostgreSQL 19 to Feature Historic pg_catalog Changes

PostgreSQL 19 is projected to introduce the most significant modifications to the pg_catalog schema in the system's history. This critical metadata layer exposes database structure and real-time server state, making it essential for diagnosing replication lag, lock contention, and query performance issues. As these catalogs evolve, engineers must stay aware of shifting column definitions and view structures to maintain effective operational visibility.

  • PG19 will break more catalog conventions than any previous release, altering metadata schemas.
  • pg_catalog is the primary interface for inspecting tables, indexes, and live server activity.
  • Diagnosing locks, vacuum, and replication lag relies heavily on stable catalog views.
  • Monitor upcoming release notes for specific column additions or removals in pg_stat_activity and pg_locks.
  • Update internal monitoring scripts to handle potential schema drift in the next major version.

Fleet impact: As a DBA managing ExaCC/RAC or Aurora, treat pg_catalog as a moving target; PG19 changes may break legacy diagnostic queries or custom metadata extraction scripts. Audit your monitoring tools and automated health checks against the PG19 release notes to ensure compatibility with new or removed catalog columns.

CHECKLISTPG19 Catalog ReadinessMonitor release notes for schema driftUpdate scripts for pg_stat_activity changesAudit pg_locks view modificationsVerify replication lag diagnostic toolsTest lock contention monitoring scripts
Read at source →
AWS What's New awsdatabase ↺ since 08-29

Amazon Aurora MySQL 3.13 reaches GA with MySQL 8.0.45 compatibility

Amazon Aurora MySQL-Compatible Edition 3 is now generally available with version 3.13, aligning with MySQL 8.0.45. This release integrates community MySQL fixes alongside specific Aurora enhancements to improve stability and feature parity. Upgrades can be executed in-place or via snapshot restore during scheduled maintenance windows, with support across all AWS Regions where the service is offered.

  • Upgrade to Aurora 3.13 for MySQL 8.0.45 compatibility and latest community fixes.
  • Use automatic minor version upgrades or orchestrate phased rollouts via AWS Organizations.
  • Perform in-place upgrades or utilize snapshot restores for migration flexibility.
  • Available in all AWS Regions supporting Aurora MySQL.
  • Review release notes for specific performance improvements and bug fixes.
HOW IT WORKSAurora 3.13 Upgrade Paths1Review release notes2Choose in-place or snapshot3Execute during maintenance4Verify MySQL 8.0.45 compat
Read at source →
↑