Neues vom PostgreSQL Planet

We’re wrapping up our series of articles reviewing the changes in PostgreSQL 19. The previous articles covered the first four CommitFests: 2025-07, 2025-09, 2025-11, 2026-01.

Somewhere in the multiverse, there is a version of you who attends every interesting talk at PGConf.EU.

Unfortunately, in this universe, PostgreSQL has parallel query execution. Humans don’t.

Last year, I created an Underground Map for Database Nerds to navigate PGConf.EU without getting lost in the schedule.

This is part 3 of a series about Postgres logical replication use-cases, and about how the feature set has evolved over the past ten years and ten releases (Postgres 10 through the Postgres 19 beta), one architecture at a time. Part 1 built a hub-and-workers system for write scalability and has the table of what each release added, which this post assumes.

How ctid-aware segment partitioning, an inverted DocId map, and bitmap postings accelerated ParadeDB's Wikipedia COUNT queries—then a look at the rest of search, where ParadeDB delivered 10–22x TIN's throughput on filtered and time-sorted Hacker News queries.

PGConf Asia 2026 is heading to Hong Kong from November 17–18! As a premier regional event for the PostgreSQL community, PGConf.Asia brings together developers, contributors, DBAs, and enterprise users from across the continent. Several EDB team members will be presenting sessions this year. Additionally, EDB's own Bruce Momjian is serving on the organizing committee and co-chairing the program committee. Here is a sneak peek at the EDB-led sessions at PGConf Asia:

PGConf Asia 2026 is heading to Hong Kong from November 17–18! As a premier regional event for the PostgreSQL community, PGConf.Asia brings together developers, contributors, DBAs, and enterprise users from across the continent. Several EDB team members will be presenting sessions this year. Additionally, EDB's own Bruce Momjian is serving on the organizing committee and co-chairing the program committee. Here is a sneak peek at the EDB-led sessions at PGConf Asia:

Do you know about the Winklevoss twins, Cameron and Tyler? They grew up together, went to the same university, and eventually built very different things around technology, finance, and entrepreneurship. Whatever you think of their story, there is something fascinating about twins who start from the same place and then take their abilities into different directions.

Now imagine two twins who grow up in completely different families.

The `port` parameter does double duty: it names the TCP socket and the Unix socket file too. (I consult on PostgreSQL through PGX Inc..)

Three ways to create a read-only user in PostgreSQL 17, measured: what each still allows, from a write through a function to password verifiers and RLS.

What raised 'must be owner of table' in PostgreSQL 17, measured: which statements need ownership, which a grant covers, and how tables end up with mixed owners.

BYPASSRLS, table owners, FORCE and superusers in PostgreSQL 17, measured: who sees every row, what role membership passes on, and what RLS never covers.

The same LIMIT query on an idle Postgres: 78 ms, then 0.07 ms, with every page already in shared_buffers. Ten runs with a standard deviation and a per-run sample on each plan node found the cause (synchronize_seqscans), a control proved it, and the same statement returned different rows with nothing writing. Why one EXPLAIN ANALYZE is a sample of one, and how to read dispersion on a plan.

ALTER DEFAULT PRIVILEGES in PostgreSQL 17, measured: whose new tables it covers, why a per-schema revoke does nothing, what counts as a table, how to list it.

What raised 'permission denied for table', schema and sequence in PostgreSQL 17, measured: the privilege each statement needs, and why default privileges miss.

What current_setting and set_config do with a custom setting in PostgreSQL 17, measured: NULL or empty string, how long a value lasts, defaults, who may set it.

A table that shrinks in rows does not shrink on disk. Everyone who has run PostgreSQL for a while knows this in general. I wanted the actual numbers, because "VACUUM reclaims space" means something narrower than it sounds.

Short answer: I deleted every second row of a 2,000,000-row table. The table was 137 MB before, 137 MB after the DELETE, 137 MB after VACUUM, and 68 MB after VACUUM FULL.

Some advice gets repeated in code review because it sounds like it should matter. I picked four I have seen argued about and measured them. I expected at least two clear winners. I got three ties and one result that went the opposite way from the advice.

Setup

PostgreSQL 18.6, default settings. 2020 13-inch MacBook Pro, Intel i5-8257U, 8 GB RAM. A 2,000,000-row table u with an id, an email, a status and a timestamp. Times are execution times from EXPLAIN (ANALYZE, TIMING OFF), warm cache, first run discarded, median of the rest.

Ten enterprise customers own 80% of the orders. On uniform test data the query runs in ~1ms; on that real skew it runs ~1,000x slower. The fix doesn't transfer between engines: Postgres is rescued by one free session setting, SQL Server can't be touched by it and needs a completely different access-path fix. Measured on Neon and Azure SQL Database using ExoBench.

Row-level security for a multi-tenant SaaS on PostgreSQL 17, result by result: what leaks, what it costs, how to set the tenant, and where each test is.

Setting the tenant for PostgreSQL row-level security in Go with pgx 5.11, measured: pgxpool, PrepareConn hooks, transactions, batches and PgBouncer.