October opened with a security-heavy round of maintenance releases, and if you run a connection pooler in front of PostgreSQL, this is the week to schedule an upgrade window. The Pgpool-II project shipped patches across every supported branch, while the wider ecosystem delivered new funding, a new cloud platform, and a data-lake feature that deletes an ETL step for analytics teams.

Pgpool-II patches seven CVEs across five branches

On October 1, the Pgpool Global Development Group released 4.7.3, 4.6.8, 4.5.13, 4.4.18, and 4.3.21 — five versions covering every maintained line, all carrying security fixes. Full details are in the release notes.

The CVEs (CVE-2026-92867 through CVE-2026-92873) cluster around two themes. The first is watchdog message handling, the coordination layer Pgpool-II uses in multi-node pools:

• CVE-2026-92867 — a malformed watchdog message during failover lets an attacker write an arbitrary 32-bit value to an arbitrary memory address.
• CVE-2026-92869 — watchdog message processing can overwrite memory past the bounds of fixed-size arrays.
• CVE-2026-92870 — failover messages with arbitrary-length data corrupt the stack and crash a Pgpool-II process.
• CVE-2026-92871 — a NULL pointer dereference in watchdog inter-node authentication when an authentication key is configured and a crafted message omits credentials.
• CVE-2026-92873 — watchdog promotion processing allows an attacker to bypass authentication key checks and promote a node of their choosing to leader.

The second theme is certificate handling. CVE-2026-92868 is the one to weigh even if you do not use watchdog: Pgpool-II does not properly handle NUL bytes in the Common Name field of a client X.509 certificate, allowing a malicious client to connect as another user without a password. CVE-2026-92872 is an information disclosure in the heartbeat receiver process.

In plain terms: if you run a single Pgpool-II node without watchdog and without certificate authentication, your exposure is narrow. Multi-node watchdog clusters, and any deployment trusting client certificates, should treat these as urgent.

# Confirm what you are running before you upgrade
pgpool -V

# Debian / Ubuntu
sudo apt-get update && sudo apt-get install --only-upgrade pgpool2

# RHEL / Rocky / AlmaLinux
sudo dnf upgrade pgpool-II

Restarting the pooler briefly interrupts connections, so pair the upgrade with a drain window or, better, roll it across pool nodes one at a time if your topology allows.

The pooler keeps becoming the soft spot

This release lands alongside a timely essay from Christophe Pettus, Nobody Patches the Pooler, which argues that PgBouncer is the most neglected critical component in most Postgres stacks. PgBouncer 1.26.0 fixed three CVEs in September, two of them triggerable by anyone who can reach the port. The pattern is consistent: poolers sit in the network path of every connection, are often front-facing, and are frequently the last thing on a patch calendar. Treat Pgpool-II and PgBouncer as part of your attack surface, not as plumbing.

Aurora PostgreSQL now reads Iceberg and Parquet directly

AWS announced that Aurora PostgreSQL can query Apache Iceberg and Parquet data in your data lake directly, with no ETL pipeline in between. The capability embeds DuckDB inside the Postgres server, so analytical scans of lake data run through a columnar engine while operational data is served by Aurora in the same query.

CREATE EXTENSION aurora_analytics;
-- Then create foreign tables pointing at Iceberg or Parquet in S3,
-- S3 Tables, or the AWS Glue Data Catalog, and query them with SQL.
-- IMPORT FOREIGN SCHEMA can bulk-create every table in a Glue database.

It is available on Aurora PostgreSQL 17.11+ and 18.6+ (including Serverless v2) in all commercial and GovCloud regions at no additional charge — you pay only for incremental compute and S3 requests. Predicate pushdown, column pruning, and automatic local caching keep the scans efficient, and access flows through the same PostgreSQL roles and audit logs you already use.

Supabase raises $150M and acquires Turso

Supabase announced $150 million in new funding led by GIC, with CapitalG, IronArc, and SquarePeg participating, and an agreement to acquire Turso. Turso rewrote SQLite in Rust, removed its single-writer constraint, and runs a diskless, write-ahead-log-on-object-storage architecture that can host huge numbers of small databases cheaply. The bet is squarely on agentic workloads, where each agent may need its own database provisioned on demand; Turso users get a graduation path into standard Postgres.

pgEdge Starfleet targets the AI prototype-to-production gap

pgEdge launched Starfleet, a cloud platform built on 100% standard Postgres. It bundles an MCP server and RAG server for agent tooling, and — the differentiator — lets you start on pgEdge’s cloud and move the same platform to your own cloud, on-premises, or air-gapped. That matters for regulated industries where data residency is non-negotiable.

Dasha 1.8 adds index recommendations and I/O analysis

Dasha, the open source Postgres fleet dashboard, shipped 1.8 with B-tree index recommendations derived from pg_stat_statements (each with a ready CREATE INDEX CONCURRENTLY), an I/O page built on pg_stat_io for PostgreSQL 16+, 17 schema checks, and an MCP connector that exposes fleet diagnostics to AI assistants. Databricks also added full-text and vector search to Lakebase, its Postgres-based serving layer, signaling that search features once bolted on are becoming table stakes.

What this means for Houston teams

For Houston data teams the throughline is consolidation. Energy and upstream groups that maintain separate analytics stacks over seismic, production, and trading history can now query lake data from Aurora through the same interface they already use for operational records, which removes a nightly job and a class of schema-drift bugs. Poolers deserve the same respect the operating data does: many Houston shops run Pgpool-II for failover without a patch cadence attached to it, and watchdog bugs are exactly the kind that stay quiet until they do not.

Your action list for the week

1. Audit every Pgpool-II and PgBouncer instance and record its exact version.
2. Upgrade all Pgpool-II deployments to 4.7.3, 4.6.8, 4.5.13, 4.4.18, or 4.3.21 as appropriate during a drain window.
3. If you terminate client X.509 certificates at the pooler, treat CVE-2026-92868 as urgent — it is an authentication bypass.
4. Review whether your pooler is reachable from untrusted networks and tighten that boundary today.
5. If you run Aurora PostgreSQL 17 or 18, test aurora_analytics against one real data-lake dataset before committing to a broader rollout.