OffNet Newsroom

Daily topic roundup

Database Technology

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

Christophe Pettus explains how maintenance_work_mem serves as a critical memory budget for heavy background tasks like index creation and vacuuming. Understanding its behavior as a one-allocation limit helps engineers tune these operations for maximum speed without exhausting system resources. Proper configuration prevents bottlenecks during maintenance windows by balancing memory availability against concurrent workload demands.

  • Tune maintenance_work_mem to accelerate index builds and vacuum operations significantly.
  • Recognize it acts as a single large allocation limit, not a per-operation pool.
  • Balance higher values against available RAM to avoid OOM risks during maintenance.
  • Monitor execution times to determine optimal settings for your specific workload.

David Wheeler introduces the chdb extension for PostgreSQL, leveraging the chDB library to embed an in-process ClickHouse engine. This tool significantly accelerates data import and export operations by reading directly from cloud storage systems like AWS S3. Benchmarks indicate superior performance compared to existing extensions such as pg_lake and pg_duckdb when handling large datasets.

  • Leverages in-process ClickHouse engine for fast, flexible data conversion from cloud storage.
  • Supports importing and exporting a wide variety of data formats directly into Postgres.
  • Outperforms alternatives like pg_lake and pg_duckdb in regionally-co-located S3 benchmarks.
  • Reduces infrastructure overhead by eliminating external ETL steps for bulk data loads.

Amazon RDS for MariaDB now supports community minor versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, and 12.3.3. These updates introduce post-quantum TLS key exchange for encrypting data in transit. The release also includes fixes for known CVEs and general performance improvements from the MariaDB community.

  • New community minors are available for immediate upgrade in RDS MariaDB.
  • Post-quantum TLS (PQ-TLS) is now supported for in-transit encryption.
  • Upgrading addresses recent CVEs and applies community bug fixes.
  • Review RDS MariaDB release notes for specific enhancement details.
COMPARISONAvailable MariaDB Minor Versions10.6 series10.6.2810.11 series10.11.1911.4 series11.4.1311.8 series11.8.9

Amazon RDS for SQL Server now supports the latest Cumulative Updates and General Distribution Releases for SQL Server versions 2016 through 2025. These patches include critical security fixes for vulnerabilities identified as CVE-2026-47295, CVE-2026-47296, CVE-2026-54118, and CVE-2026-55002. Specific RDS versions map to Microsoft KB articles for each supported release line.

  • Patches cover SQL Server 2016 SP3 through 2025 CU7
  • Addresses four specific CVEs listed in Microsoft advisories
  • RDS versions now reflect specific KB numbers for compliance
  • GDR updates provide security fixes without full CU feature set
  • No manual patching required if using supported RDS engine versions
CHECKLISTSQL Server Patching ChecklistUpdate RDS 2016 SP3 through 2025 CU7Address CVE-2026-47295, 47296, 54118, 55002Verify specific KB numbers for complianceUse GDR for security without full CURely on auto-patching for supported engines

Dalibo has released PostgreSQL Anonymizer 3.2, introducing a new set of high-speed pseudonymization filters. This extension continues to support six core masking strategies, including dynamic, static, replica, backup, view, and wrapper-based masking. The update aims to enhance privacy protection for PII and sensitive commercial data with improved performance.

  • New fast pseudonymization filters reduce overhead for data masking operations.
  • Supports six strategies: dynamic, static, replica, backup, views, and wrappers.
  • Extension masks PII and commercial data across various PostgreSQL workflows.
  • Dalibo drives updates to improve privacy protection performance.
CHECKLISTPostgreSQL Anonymizer 3.2 TakeawaysNew filters reduce masking overheadSupports six core masking strategiesMasks PII and commercial dataImproves privacy protection performance

Autobase 2.11 transforms the PostgreSQL deployment interface into a comprehensive cluster lifecycle platform. The release enables direct management of scaling, upgrades, backups, and point-in-time recovery via the UI. Scaling is handled by automatically provisioning read replicas based on specified node counts using existing cloud configurations.

  • Autobase Console now manages full cluster lifecycle, not just initial deployment.
  • Scale read capacity by specifying node count; Autobase provisions replicas automatically.
  • Manage upgrades, backups, and point-in-time recovery directly from the UI.
  • Uses existing cloud configuration for server and infrastructure provisioning.
HOW IT WORKSAutobase 2.11 Lifecycle1Deploy initial cluster2Scale via replicas3Perform upgrades4Manage backups5Point-in-time recovery
Planet PostgreSQL database

PostgreSQL 19 drops two features after Robert Haas review

Two features have been removed from the upcoming PostgreSQL 19 release following a request by Robert Haas to the pgsql-hackers mailing list. Haas asked if six heavily patched features should ship with version 19, resulting in the reversion of two items. One of the removed features was on Haas's original list, while the other was not included in that initial review.

  • PostgreSQL 19 excludes two features deemed too risky or immature for the release.
  • Robert Haas initiated a review of six heavily patched features before the final ship.
  • One reverted feature was on Haas's list; the second was an additional reversion.
  • Drivers for removal likely involve stability concerns or incomplete patching.
CHECKLISTWhat matters herePostgreSQL 19 excludes two features deemed too risky or immature for…Robert Haas initiated a review of six heavily patched features before…One reverted feature was on Haas's list; the second was an additional…Drivers for removal likely involve stability concerns or incomplete…
Planet PostgreSQL database ↺ since 09-05

PostgreSQL session_replication_role does not disable check constraints

Setting session_replication_role to replica disables triggers and rules but does not bypass check constraints or foreign keys. A practical example shows that while a foreign key violation is ignored, a check constraint on column values still fires and rejects invalid data within the same session. This distinction is critical for bulk load scripts that rely on this setting to bypass referential integrity.

  • session_replication_role only affects triggers and rules, not data integrity constraints.
  • Check constraints remain active even when the role is set to replica.
  • Foreign keys are enforced via internal triggers, which are suppressed by this setting.
  • Do not use this setting to bypass check constraints during data loads.
TRADE-OFFSession Replication Role LimitsDisabled by ReplicaTriggers are suppressedRules are ignoredForeign keys bypassedStill EnforcedCheck constraints activeInvalid data rejectedBulk loads failvs
↑