PostgreSQL 18 RC1: io_uring AIO, uuidv7, OAuth and a new wire protocol—GA planned Sep 25, 2025
Key update
The PostgreSQL Global Development Group published PostgreSQL 18 Release Candidate 1 on September 4, 2025, with general availability planned for September 25, 2025. This release brings a substantive set of platform-level changes: a new asynchronous I/O subsystem (worker-based with Linux io_uring support) that promises large read‑heavy throughput gains, virtual generated columns now computed at query time by default, uuidv7 support (timestamp-ordered UUIDs), OAuth authentication extension support, richer EXPLAIN ANALYZE output that shows buffer/index/WAL metrics, parallel GIN index builds, several query/optimizer improvements (skip‑scan B‑tree lookups, better OR/IN planning), and a new PostgreSQL wire protocol version 3.2. New clusters will have data checksums enabled by default.
Why it matters (practical evaluation)
This is a genuine platform inflection for production backends and tooling. The asynchronous I/O subsystem alone can materially reduce I/O latency and raise throughput for read- and index-heavy workloads—expect measurable gains on large sequential scans, bitmap heap scans, and VACUUM; cloud and block-storage users should benchmark with your real workloads because gains vary by storage and OS. The new wire protocol and several internal changes mean client libraries, connection proxies, and poolers should be tested: while libpq remains compatible with 3.0 by default, drivers and proxies will need validation for 3.2 features and behaviors before you upgrade production databases.
Operational and migration implications are immediate. PostgreSQL 18 is a major version: upgrades require pg_upgrade or dump/restore and you should run full compatibility tests. New clusters defaulting to data checksums affects init flows and image-building pipelines (you can opt out with initdb flags, but CI/automation must be updated). Security changes—OAuth support and the continued deprecation of md5 auth in favor of SCRAM—mean you should plan authentication migrations now if you still rely on older methods. Developer-facing features like virtual generated columns, uuidv7, and enhanced EXPLAIN diagnostics are practical wins: virtual columns reduce storage and sync complexity for computed values, uuidv7 helps index locality and time-range sharding, and the richer EXPLAIN output makes query troubleshooting faster.
Actionable next steps: run the RC in a staging environment with representative workloads, validate your client drivers/poolers and ORMs (including Node.js pg, server-side connection managers, and any proxies), update CI images to use initdb flags you want for checksums, and plan for an upgrade window around the GA date (Sep 25, 2025). If you rely on extensions, confirm compatibility with 18rc1 and watch the extension ecosystem for updates.
Source
Read Next
Node.js v25 scheduled for 2025‑10‑15 — semver‑major release imminent
September 30, 2025Node.js v25 is scheduled for October 15, 2025 (commit cutoff 2025‑09‑15). Teams should run CI against the new major, validate native modules, and prepare canary deployments.
Azure Functions Proxies: community support ends 2025‑09‑30 — migrate off Proxies now
September 29, 2025Azure announced Azure Functions Proxies will be unsupported after 2025‑09‑30; teams still using Proxies must inventory and migrate to a supported API surface (APIM, Front Door, or a lightweight reverse proxy) immediately.
NodeShield: runtime SBOM enforcement (CBOM) for Node.js limits supply‑chain attacks with negligible overhead
September 28, 2025A new paper introduces NodeShield, a runtime enforcement system that uses SBOMs extended with per‑dependency capabilities (CBOM) to prevent supply‑chain abuses in Node.js with ~98% effectiveness and <1ms overhead.