September’s release week had a clear priority: a security fix. Between September 8 and 14, the PostgreSQL ecosystem shipped a first stable migration tool, a transparent data encryption extension, a cluster-lifecycle platform update, and a masking utility that patches three critical privilege-escalation CVEs. Here is what Houston data teams should act on, in order.

PostgreSQL Anonymizer 3.2 fixes three critical privilege-escalation CVEs

If you use the PostgreSQL Anonymizer extension to mask production data into test and analytics copies, this is a patch-now release. Version 3.2 fixes three vulnerabilities that let a user gain superuser privileges under certain circumstances:

• CVE-2026-19633 — privilege elevation via custom types, operators and rangevars.
• CVE-2026-19634 — SQL injection in the masking rules import functions.
• CVE-2026-83534 — privilege elevation via parallel static masking.

Dalibo rates the risk as very high on PostgreSQL 14 and on instances upgraded from PostgreSQL 14 or earlier. Anyone running an anonymized clone of an OLTP database — the usual pattern for Houston energy trading, insurance and healthcare systems that need realistic test data — should treat this as a same-week upgrade.

Two behavior changes come with the fix. First, 3.2 adds a security barrier that refuses to run masking on behalf of a superuser, enforcing least privilege. If your static, replica or backup masking jobs run as a superuser, create a dedicated role instead; setting anon.nosuperuser to FALSE removes the barrier at your own risk. Second, the JSON schema for rule imports and exports changed between 3.1 and 3.2, so re-export your rules after upgrading.

-- upgrade the extension
ALTER EXTENSION anon UPDATE;

-- move masking off superuser instead of disabling the new barrier
CREATE ROLE anon_runner LOGIN;
GRANT anon_runner TO app_owner;

Pseudonymization is now 40x faster with anon.seeded_*

The headline feature in 3.2 is a new panel of anon.seeded_* filters replacing the old pseudo_* functions: anon.pseudo_email() becomes anon.seeded_email(). The new functions are 40 times faster and can be localized, so generated values match the language of the dataset. The pseudo_* functions still work but are deprecated and will be removed later.

-- deprecated
SELECT anon.pseudo_last_name(id) FROM customers;

-- 3.2: faster and localizable
SELECT anon.seeded_last_name(id) FROM customers;
SELECT anon.seeded_street_name(id, 'fr_FR') FROM customers;

PostgreSQL Migrator 1.0: Oracle and MySQL exits get a stable tool

Dalibo released PostgreSQL Migrator 1.0 after roughly a year of betas and release candidates, under the PostgreSQL License. It is a pure Go binary with no proprietary dependencies, targeting PostgreSQL 16 through 19 as the destination, and supports Oracle Database 11g through 26ai, MySQL 8.4+ and MariaDB 10+ as sources.

The workflow matters more than any single conversion step:

• Offline catalog inspection — extract the source catalog once, then iterate on conversion without touching the source again.
• Complexity scoring — compare candidate schemas so you can rank migration projects instead of guessing.
• Web UI and transpilation — browse original and converted catalogs side by side, and analyze or transpile SQL, PL/SQL and routines with the companion transqlate tool.
• Streamed bulk COPY — low memory use and, in Dalibo’s tests, significantly higher throughput than traditional tools.

Scope check before you build a program on it: 1.0 has full inspection coverage, but conversion currently covers roles, schemas, sequences, tables, virtual columns, constraints and indexes. Views, procedural objects and SQL Server are roadmap items. Houston relevance is direct — the city runs a long tail of Oracle-backed ERP and financial systems plus a generation of MySQL web applications, and Oracle licensing is a line item someone asks you to cut every budget cycle.

pg_vault_tde 1.7.1 adds TDE for PostgreSQL 17 and 18 — with a TOAST warning

pg_vault_tde provides transparent data encryption through a table access method, encrypted_heap, that encrypts every tuple with AES-256-GCM before it reaches the storage manager and decrypts it on the way out, with no application changes. Keys stay outside the database — HashiCorp Vault or OpenBao Transit, a PKCS#11 token or HSM, or a local PKCS#12 wallet — and data encryption keys are per table with online rotation. It requires PostgreSQL 17 or 18, OpenSSL 3.x, and registration in shared_preload_libraries (confirm the exact library name in the README before restarting).

Read the upgrade note twice. Version 1.7.1 corrects the AAD derivation for out-of-line TOAST values, so TOAST data written by 1.7.0 or earlier does not authenticate under 1.7.1: affected tables must be exported before the new binary is installed. Encryption at rest is a standard control in healthcare and financial reviews, so in-database encryption is genuinely useful — but treat this as a third-party extension to test in staging, not a checkbox to flip in production.

Autobase 2.11 closes the cluster-lifecycle loop

Autobase 2.11 is the release where scaling, upgrades, backups and point-in-time recovery all land in the UI. Read replicas are provisioned by specifying a node count, with cloud deployments creating servers automatically. Minor upgrades roll replicas one at a time then switch over, keeping reads available with roughly 5–10 seconds of write downtime; in-place major upgrades run 30–60 seconds, with a blue-green path planned. Backup and restore — latest state, point in time, or a specific backup — are configured by method, storage, retention and schedule, and new Ansible playbooks (enable_backups, backup_pgcluster, backup_list, restore_pgcluster) keep operations in code. For lean teams running Postgres without a dedicated DBA, PITR as a button is the most valuable item here.

Community: CERN PGDay 2027 call for papers closes November 8

SwissPUG and CERN announced CERN PGDay 2027, a single-day, single-track conference on Friday, February 12, 2027 at the CERN campus in Geneva: six to seven English-language sessions, a networking social, and CERN visits around the program. Proposals go in through Indico, and the call for papers closes November 8, 2026 at 23:59 CET.

The published themes read like a description of a Houston data stack — massive datasets and extreme write throughput, partitioning and high availability, pgvector and RAG pipelines, enterprise security and sovereignty, and core performance and extensibility. If you have been sitting on a talk about scaling Postgres for industrial workloads, the deadline is eight weeks out.

Your action list for the week

1. Patch Anonymizer to 3.2 if you rely on it for test data — especially on PostgreSQL 14 or clusters upgraded from 14 or earlier — then re-export masking rules and move masking off superuser.
2. Audit pg_vault_tde versions. On 1.7.0 or earlier, export affected tables before installing the 1.7.1 binary.
3. Pilot Migrator 1.0 on one Oracle or MySQL schema and use its complexity score to size a migration before committing budget.
4. Submit a CERN PGDay abstract before November 8.
5. Evaluate Autobase 2.11 if PITR is still a runbook rather than a button.

Sources: PostgreSQL Anonymizer 3.2, PostgreSQL Migrator 1.0, pg_vault_tde 1.7.1, Autobase 2.11, CERN PGDay 2027 CfP.