OffNet Newsroom

Daily topic roundup

Database Technology

Saturday, July 04, 2026 · 6 stories, curated & summarized — click any story for the source.

Share this roundup on LinkedIn Full edition
Planet PostgreSQL database

PostgreSQL GUC enable_parallel_append spreads workers across branches

Christophe Pettus explains the enable_parallel_append GUC, which allows PostgreSQL to distribute workers across multiple partitions or UNION branches simultaneously rather than sequentially. This shift from sequential to parallel execution across append nodes aims to improve throughput for complex queries involving large unions or partitioned tables.

  • Parallel Append executes branches concurrently, not one after another
  • Enable via enable_parallel_append GUC to change execution strategy
  • Beneficial for large UNION queries or wide partitioned table scans
  • Workers are distributed across branches to maximize resource usage
  • Check execution plans to verify parallel append is actually used
Read at source →
Planet PostgreSQL database

pg-healthcheck: Open-source Go tool for 180+ live PostgreSQL diagnostics

Ahsan Hadi released pg-healthcheck, an open-source Go utility designed to provide immediate visibility into PostgreSQL instance health. The tool performs over 180 checks across 14 categories by querying live system catalogs, covering critical issues like bloat, WAL retention via replication slots, transaction ID wraparound, and silent backup failures. It specifically targets hard-to-detect problems such as TOAST corruption and heap-VM state mismatches that disrupt vacuum operations.

  • Runs 180+ checks against live system catalogs for accurate, real-time diagnostics without estimates.
  • Covers critical failure modes including WAL holdback, bloat, and silent backup cessation.
  • Detects complex catalog issues like TOAST corruption and vacuum-affecting state mismatches.
  • Written in Go for easy deployment as a standalone utility on any PostgreSQL instance.
Read at source →
Hacker News (100+ points) general

TLA+ uncovers 16-year-old SQLite WAL bug; dqlite impact analyzed

A formal verification effort using TLA+ has identified a Write-Ahead Log (WAL) defect in SQLite that has existed for 16 years. The investigation focuses on whether this specific edge case affects dqlite, the distributed SQLite implementation used by Ubuntu and Canonical. The analysis highlights how model checking can reveal long-standing concurrency issues in mature database libraries.

  • 16-year-old SQLite WAL bug found via TLA+ model checking
  • Analysis determines if dqlite implementations are affected
  • Formal verification exposes deep concurrency edge cases
  • Practitioners should review dqlite versions for this defect
Read at source →
The Register general

Databricks unifies OLTP and OLAP, but the data copy model is debatable

Databricks is promoting an LTAP architecture that attempts to merge online transaction and analytical processing workloads. The engineering behind this unification is notable, but the marketing claim relies on a loose definition of what constitutes a single copy of the data. This approach aims to simplify the stack but introduces complexity regarding data consistency and synchronization.

  • LTAP architecture attempts to merge OLTP and OLAP workloads in one platform.
  • The 'single copy' marketing claim is debatable and depends on data sync definitions.
  • Underlying engineering is clever but may introduce consistency overhead.
  • Practitioners should scrutinize the actual data movement and latency implications.
Read at source →
Planet PostgreSQL database

Postgres 19 Targets Online Data Checksum Enablement

Shaun Thomas highlights that while data checksums protect against silent corruption, enabling them historically required a full offline cluster rebuild, even after pg_checksums was added in version 12. With checksums finally becoming the default in version 18, the upcoming version 19 aims to eliminate the painful outage window by allowing online activation. This shift addresses the long-standing friction of adding this critical safeguard to existing deployments.

  • Checksums now default to on in Postgres 18, making them the standard safety net.
  • Postgres 19 is expected to support online checksum enablement, avoiding full outages.
  • Previous methods like pg_checksums required bringing the cluster completely offline.
  • Existing clusters can finally add corruption detection without rebuilding from scratch.

Fleet impact: For Oracle ExaCC/RAC fleets, this mirrors the value of ASM diskgroup checksums or Oracle Block Change Tracking for validation, though Exadata already provides robust hardware-level error detection. For AWS Aurora PostgreSQL/MySQL + RDS, this feature is largely abstracted away as Amazon manages underlying storage integrity; however, it reinforces the importance of verifying that your managed service provider exposes or enables equivalent low-level data integrity checks, as you likely cannot toggle them manually anyway.

Read at source →
Planet PostgreSQL database

PostgreSQL Single-File Storage Complicates Ransomware Catalog Recovery

Zhang Chen analyzes how PostgreSQL's architecture of storing each relation in a separate file increases the difficulty of recovering from ransomware attacks. The post highlights that catalog recovery becomes particularly painful when individual file integrity is compromised. It contrasts this exposure model with the more consolidated storage approaches found in MySQL and Oracle.

  • PostgreSQL's single-file-per-relation design creates granular failure points during ransomware incidents.
  • Catalog recovery is significantly harder due to the high volume of individual files involved.
  • This exposure model differs notably from MySQL and Oracle's more consolidated storage strategies.
  • Practitioners should review backup granularity and restoration procedures for PostgreSQL fleets.
Read at source →
↑