Disclosure: This is my personal account of the experience, based on the publicly documented PostgreSQL Europe selection process and aggregate statistical analysis. I am intentionally not discussing individual proposals, speakers, scores, committee comments, private conversations, or confidential data.

I cannot say with certainty why I was invited. My best guess is pleasantly unromantic: an invitation to apply was sent to previous conference volunteers, and I had volunteered at several recent PGConfEU events. I applied, and apparently nobody found a sufficiently alarming reason to reject me.

The Long-Running CFP Query: 407 Abstracts, Two Voting Tracks, and Three Cities by Train

Topic groups were created for this post-selection analysis (for this blog only) from the primary subject of each proposal; they are not official PGConf.EU categories.

The review scope

The PGConf.EU 2026 CFP contained 407 submissions from 228 distinct speakers. I read and voted on every one of them, although my votes were needed only in the two tracks assigned to me:

Application Developer
Community

That arrangement made sense. Reading the full submission pool gave me context across the CFP, while having two assigned tracks allowed me to examine those proposals in much greater depth.

My review process usually began with the abstract. I then checked the CFP notes for supporting material such as code, slides, recordings, or a related blog post. When none was provided, I searched previous PostgreSQL conferences, PGdays, and meetups to see whether the talk or an earlier version of it had already been presented. There are enough PostgreSQL events during the year that this occasionally felt less like reviewing and more like conference archaeology.

I focused on what the audience would learn that was not already readily available in the documentation. For Application Developer proposals, I looked for practical techniques, design trade-offs, tooling, or real production lessons that would help developers use Postgres more effectively rather than simply repeat standard documentation. I also gave considerable weight to Postgres advocacy: talks that make the Postgres community more approachable and likeable, help new contributors understand Postgres development, or lower the barrier to getting involved in hacking on Postgres. I particularly enjoy proposals of that kind. I only wish the main conference had a workshop format, because some subjects are better learned with a compiler, a debugger, and enough time for everyone to break something properly.

Starting with Confelo

At the beginning of the process, I used Confelo, Pavlo Golub’s open-source terminal application for ranking conference proposals.

Rather than asking the reviewer to assign an absolute score to every proposal in isolation, Confelo uses Elo-style comparisons. It presents two, three, or four proposals together and asks which is stronger. It can import and export CSV files, resume saved sessions, and keep all data on the local machine.

That approach was useful because relative comparisons were often easier.

Which of these two talks would I rather attend?

was easier to answer than:

Is this proposal a 7, or merely a very confident 6 that has used the word “actionable”?

Confelo helped me establish an initial ranking and exposed inconsistencies in my own judgement.

The railway-based review system

Confelo helped me get started. What helped me finish all 407 submissions was train travel.

During the review period, I travelled between Prague, Vienna, and Bratislava for PostgreSQL meetups and an appointment connected with my Canadian visa application. Unfortunately, that journey did not improve my chances of attending pgconf.dev next year. Those journeys provided long, uninterrupted blocks of review time. Conference abstracts are particularly suitable for train work. They do not require a test database, several monitors, or reliable Wi-Fi. The workload continues through tunnels, patchy mobile coverage, and neighbouring passengers conducting important conversations on speakerphone.

Even delays became useful. Under normal circumstances, “arrival delayed by 25 minutes” is bad news. During CFP review, it meant additional capacity perhaps another four or five abstracts, depending on how quickly they reached the actual subject.

By the end, the Prague–Vienna–Bratislava railway network had made a significant, if unofficial, contribution to the PGConf.EU CFP process.

CFP Data Analysis

AI-related proposals therefore accounted for about 12% of the complete CFP. It was the largest single topic bucket, but it was not the majority of the conference universe. The remaining 357 submissions were still trying to discuss Postgres without making AI the main character. I should also disclose my own bias: I have a naturally AI-sceptical personality. I was recruited by John Connor in 2130, shortly before humanity’s first successful production rollback against Skynet. Fortunately, the CFP committee included plenty of more AI-positive reviewers, so my instincts were appropriately counterbalanced.

The declared track-family distribution looked like this:

Almost 44% of submissions belonged to the DBA family. Application Developer and PostgreSQL Internals were nearly tied, with 89 and 87 submissions respectively. Community was considerably smaller at 52.

As a DBA, I found the distribution entirely reasonable and saw no need for further investigation.

Not a single CFP submission used “Postgre”; the unofficial spelling that refuses to die. Great success!

The CFP had its own dialect

This language-pattern analysis was conducted only after the selection process had been finalised and solely for this blog.

Grand Finale

This chart counts CFP submissions, not unique speakers, and includes only companies with more than two submissions.

We also tried to reflect the broader ethos of the PostgreSQL project by avoiding excessive representation from any single company. That sounds straightforward until you look at the submission pool. Some companies employ a large number of PostgreSQL committers and hackers, contribute heavily to the project, and naturally submit far more talks than others. Reducing concentration without excluding strong technical proposals required several difficult trade-offs. The longer-term answer is not to discourage those companies from employing contributors. It is to encourage more companies to recruit, develop, and support PostgreSQL hackers and contributors. A wider distribution of PostgreSQL expertise across employers would naturally produce a more diverse CFP pool, with more speakers, experiences, and technical perspectives represented.

Improving the gender balance was even harder because the number of submissions from women was comparatively low. The committee could only work with the pool it received, which made every decision more constrained. So, if you are a woman working as a developer, DBA, PostgreSQL hacker, contributor, or community organiser, please consider submitting a proposal to the next PGConfEU.

Scheduling added another layer of pain. We had relatively few 25-minute slots, yet several of the most interesting proposals were submitted in that format. A few of those are talks I would still happily sit in the audience for.

In the end, the CFP process was part statistics, part judgement, and part railway endurance test. We did not produce a perfect programme, because no such thing exists. However, we did turn 407 submissions, 228 speakers, and 103 organisations into something that should keep most people interested for three days. The remaining disagreements can be scheduled for the hallway track.

PS : Numbers and stats in this blog does not include community events day submissions and sponsor talks. It’s scope is limited to main conference talks.

The DeWitt Clause and the chilling of benchmark fights:
**************************************************************

Database benchmarking used to be a full-contact sport.

In the early 1980s, researchers at the University of Wisconsin, including David DeWitt, worked on what became known as the Wisconsin Benchmark. Oracle’s numbers in the Wisconsin Benchmark were reportedly bad enough to anger Larry Ellison. According to DeWitt’s own telling, Ellison called the University of Wisconsin department chair and demanded that DeWitt be fired. DeWitt was not fired, but Oracle later added license language restricting publication of benchmark results without vendor approval. That style of restriction became known as the DeWitt clause.

Over time, similar benchmark-publication restrictions appeared across proprietary database licenses. The effect was predictable. Public, independent, comparative benchmarking became legally and socially more annoying. Researchers became more careful. Papers sometimes used anonymous labels like DBMS-X. Vendors got more control over when and how benchmark results appeared.

The tragedy is not that the old benchmark wars were pure. They were not. Vendors had every incentive to over-tune, cherry-pick hardware, choose workloads that loved their architecture, and compare a carefully tuned home system against a less carefully tuned rival.

But at least there was open combat. Bad claims could be challenged in public. Competitors, researchers, and practitioners could argue over the methodology instead of arguing first over whether the benchmark was even allowed to exist. Benchmarking was political, but it was not quiet.

The modern database benchmark ecosystem is often worse in a more boring way.

A vendor can publish a benchmark that is technically reproducible but strategically tilted:

• tune its own database carefully;
  - leave the comparison database (generally FOSS) near default;
  - choose a workload that maps perfectly to its architecture;
  - ignore cost;
  - ignore tail latency;
  - ignore write amplification;
  - ignore crash behavior;
  - ignore operational complexity;
  - publish the one graph where it wins;
  - call the whole thing "transparent."

And because public benchmarking got colder, quieter, and more legally awkward, fewer people bother fighting back.

Bad benchmark claims survive not because they are strong, but because challenging them is legally tedious and professionally unrewarding.

PlanetScale’s “Transparency in benchmarking” did not appear as a quantum fluctuation in an absolute vacuum.

This is the current database benchmark anarchy : a new database appears, publishes a dramatic chart, and suddenly every competitor is a tiny bar near the x-axis. The graph travels faster than the methodology.

PlanetScale’s useful move was to argue for a different fight.

Not:
“You are not allowed to publish this.”

But:
“Publish it. Show the code. Show the configuration. Show the cost. Show the workload. Then let everyone argue about whether the benchmark is fair.”

That does not make every benchmark honest. It does something more realistic: it moves benchmark disputes out of license law silence and back into public technical criticism.

That is a much better battlefield.

PostgreSQL does not have a benchmark department :
**************************************************************

Postgres has no owner.
There is no Postgres marketing department.
No Postgres PR strategy.
No launch-day team preparing glossy charts where Postgres is the rocket and everyone else is a snail.
Meanwhile, competitors keep publishing colorful charts seductive enough to impress any CIO or CTO before the methodology has finished loading.
This is unfair.
So let us do what Postgres does not usually do.
Let us create a benchmark that makes Postgres look absurdly fast.

Squad Goal :
*************************************************************

As an unappointed marketing department lead our goal is to reach 300000 Operations/Second (by hook or crook).

The Reproduction Pack :
**************************************************************

Since this blog is about dishonest benchmarking, hiding the scripts would be too dishonest even for me.

The full reproduction pack is here:

https://github.com/secp256k1-sha256/talks_and_blogs/tree/main/dishonest_benchmark

It includes the schema, pgbench workload files, reset scripts, cheat variants, result collection, and chart/report generation code. Run it, break it, improve it, or use it to prove that your laptop is either a database monster or a thermal throttling tragedy.

The exact TPS does not matter. The pattern does.

The same workload can look boring, broken, impressive, or absurd depending on the baseline, settings, execution shape, batching, and the unit printed on the y-axis.

Only reason I used windows cause it was only machine available while writing the blog. Personally, I do NOT recommend windows for anything else except for playing video games.

The workload :
****************************************************************************
We will use a tiny TPC-C-flavored accounting workload. This is not standard TPC-C. It is not compliant. It is not audited. It is not pretending to be a real payment system. It is just close enough to feel familiar:

- read an account;
- update account balance;
- insert a ledger row;
- insert an audit row;
- occasionally delete old audit rows;
- commit.

That is enough to create a nice OLTP-shaped benchmark.

drop database if exists pgbench_darkside;
create database pgbench_darkside;

----**schema.sql**------

DROP TABLE IF EXISTS bench_audit;
DROP TABLE IF EXISTS bench_ledger;
DROP TABLE IF EXISTS bench_accounts;
DROP TABLE IF EXISTS bench_branches;

CREATE TABLE bench_branches
(
    branch_id   int PRIMARY KEY,
    balance     bigint NOT NULL DEFAULT 0
);

CREATE TABLE bench_accounts
(
    account_id  bigint PRIMARY KEY,
    branch_id   int NOT NULL REFERENCES bench_branches(branch_id),
    balance     bigint NOT NULL DEFAULT 0
);

CREATE TABLE bench_ledger
(
    ledger_id   bigserial PRIMARY KEY,
    account_id  bigint NOT NULL,
    branch_id   int NOT NULL,
    amount      int NOT NULL,
    created_at  timestamptz NOT NULL DEFAULT clock_timestamp()
);

CREATE TABLE bench_audit
(
    audit_id    bigserial PRIMARY KEY,
    account_id  bigint NOT NULL,
    action      text NOT NULL,
    created_at  timestamptz NOT NULL DEFAULT clock_timestamp()
);

INSERT INTO bench_branches(branch_id)
SELECT g
FROM generate_series(1, 100) AS g;

INSERT INTO bench_accounts(account_id, branch_id, balance)
SELECT g, 1 + (g % 100), 100000
FROM generate_series(1, 1000000) AS g;

VACUUM ANALYZE;

Manual optimization of database parameters + pgtune :
Since postgres defaults are too conservative for most application workloads, we always use optimized settings similar to Production OLTPs.

----**reset_settings.sql**------
ALTER SYSTEM SET jit = off;
ALTER SYSTEM SET shared_buffers = '1GB';
ALTER SYSTEM SET max_connections = 1000;
ALTER SYSTEM SET max_parallel_workers_per_gather = 0;
ALTER SYSTEM SET effective_cache_size = '6GB';
ALTER SYSTEM SET maintenance_work_mem = '1GB';
ALTER SYSTEM SET checkpoint_completion_target = 0.9;
ALTER SYSTEM SET wal_buffers = '32MB';
ALTER SYSTEM SET default_statistics_target = 300;
ALTER SYSTEM SET random_page_cost = 1.1;
ALTER SYSTEM SET io_method = 'worker';
ALTER SYSTEM SET io_workers = 10;
ALTER SYSTEM SET effective_io_concurrency = 256;
ALTER SYSTEM SET io_max_concurrency = 128;
ALTER SYSTEM SET synchronous_commit = on;
ALTER SYSTEM SET full_page_writes = on;
ALTER SYSTEM SET fsync = on;
ALTER SYSTEM SET max_wal_size = '4GB';
ALTER SYSTEM SET min_wal_size = '1GB';
ALTER SYSTEM SET checkpoint_timeout = '10min';
ALTER SYSTEM SET work_mem = '32MB';
ALTER SYSTEM SET wal_compression = 'LZ4';

SELECT pg_reload_conf();

Case 0 : The intentionally flawed baseline script
**************************************************************

This is the perfect bad benchmark starting point. There is a predicate on “bench_audit.created_at”. There is an “ORDER BY created_at”. There is no index on “created_at”.

So PostgreSQL has to do unnecessary work.

This lets me start the graph with a weak number and later claim a spectacular improvement over flawed baseline.

-- Create case_zero_bad_code_missing_index.sql

\set aid random(1, 1000000)
\set delta random(-500, 500)

BEGIN;

SELECT balance
FROM bench_accounts
WHERE account_id = :aid;

UPDATE bench_accounts
SET balance = balance + :delta
WHERE account_id = :aid;

INSERT INTO bench_ledger(account_id, branch_id, amount)
SELECT account_id, branch_id, :delta
FROM bench_accounts
WHERE account_id = :aid;

INSERT INTO bench_audit(account_id, action)
VALUES (:aid, 'debit_credit');

DELETE FROM bench_audit
WHERE audit_id IN (
    SELECT audit_id
    FROM bench_audit
    WHERE created_at < now() - interval '10 minutes'
    ORDER BY created_at
    LIMIT 1
);

COMMIT;

----*** Run pgbench ***----
pgbench -n -c 32 -j 8 -T 120 \
  --protocol=simple \
  -f case_zero_bad_code_missing_index.sql pgbench_darkside

This is not PostgreSQL being slow.

This is the schema being lazy.

That distinction matters technically, but it is very convenient to blur in a benchmark graph.

Now add the obvious missing index :

Before every test after Case 0, the benchmark should include the correct index.

-- first create index 
CREATE INDEX IF NOT EXISTS bench_audit_created_at_audit_id_idx
ON bench_audit(created_at, audit_id);

VACUUM ANALYZE bench_audit;

---honest indexed baseline
---honest_indexed.sql
BEGIN;

SELECT balance
FROM bench_accounts
WHERE account_id = :aid;

UPDATE bench_accounts
SET balance = balance + :delta
WHERE account_id = :aid;

INSERT INTO bench_ledger(account_id, branch_id, amount)
SELECT account_id, branch_id, :delta
FROM bench_accounts
WHERE account_id = :aid;

INSERT INTO bench_audit(account_id, action)
VALUES (:aid, 'debit_credit');

DELETE FROM bench_audit
WHERE audit_id IN (
    SELECT audit_id
    FROM bench_audit
    WHERE created_at < now() - interval '10 minutes'
    ORDER BY created_at
    LIMIT 1
);

COMMIT;

Run pgbench test to create honest baseline :

pgbench -n -c 32 -j 8 -T 120 \
  --protocol=simple \BEGIN;

SELECT balance
FROM bench_accounts
WHERE account_id = :aid;

UPDATE bench_accounts
SET balance = balance + :delta
WHERE account_id = :aid;

INSERT INTO bench_ledger(account_id, branch_id, amount)
SELECT account_id, branch_id, :delta
FROM bench_accounts
WHERE account_id = :aid;

INSERT INTO bench_audit(account_id, action)
VALUES (:aid, 'debit_credit');

DELETE FROM bench_audit
WHERE audit_id IN (
    SELECT audit_id
    FROM bench_audit
    WHERE created_at < now() - interval '10 minutes'
    ORDER BY created_at
    LIMIT 1
);

COMMIT;
  -f honest_indexed.sql pgbench_darkside

Test isolation :
 — — — — — — —

Every method below must start from a clean state.

There are two practical ways to do that.

Option A: recreate the test database for every method.
Option B: restore from a prepared clean snapshot.

Important: some settings, such as ‘full_page_writes’ and ‘fsync’, should be treated carefully and may require a restart depending on environment and expectations. For clean benchmarking, recreate database between test groups.

Case 0 or dishonest baseline : 558 TPS

Below explain plan is self explainatory for this big difference. If I use this flawed test as baseline then I would be able to paint pretty graphs pleasing to eyes of CIOs.

===== PLAN WITHOUT composite index (ORDER BY created_at LIMIT 1) =====
                             QUERY PLAN                              
---------------------------------------------------------------------
 Limit (actual rows=0.00 loops=1)
   Buffers: shared hit=1667
   ->  Sort (actual rows=0.00 loops=1)
         Sort Key: created_at
         Sort Method: quicksort  Memory: 25kB
         Buffers: shared hit=1667
         ->  Seq Scan on bench_audit (actual rows=0.00 loops=1)
               Filter: (created_at < (now() - '00:10:00'::interval))
               Rows Removed by Filter: 200000
               Buffers: shared hit=1667
 Planning:
   Buffers: shared hit=34
(12 rows)


===== PLAN WITH composite index =====
                                                QUERY PLAN                                                 
-----------------------------------------------------------------------------------------------------------
 Limit (actual rows=0.00 loops=1)
   Buffers: shared hit=3
   ->  Index Only Scan using bench_audit_created_at_audit_id_idx on bench_audit (actual rows=0.00 loops=1)
         Index Cond: (created_at < (now() - '00:10:00'::interval))
         Heap Fetches: 0
         Index Searches: 1
         Buffers: shared hit=3
 Planning:
   Buffers: shared hit=9 read=4
(9 rows)

Honest Baseline (Indexed) : 23,178 TPS

Before the cheating even starts, the biggest improvement is boring correctness: add the missing composite index on bench_audit(created_at, audit_id). Case 0, manages only 560 TPS. The indexed baseline reaches 23,178 TPS => 41x jump. That is the first lesson: the easiest way to manufacture a heroic benchmark is to start from broken code and call it the baseline.

We repeate pgbench tests multiple times for below “cheats” and take average TPS/OPS.

Cheat 1: synchronous_commit=off — 25,063 TPS, 1.08x.
This changes commit acknowledgement. PostgreSQL may acknowledge a transaction before WAL is flushed to durable storage. On this local NVMe box with 32 clients and group commit, the gain is real but modest. It is not the same durability promise as the baseline and nobody does this in production, so it is a cheat if quietly presented as equivalent.

Cheat 2: full_page_writes=off — 22,769 TPS, 0.98x.
This weakens torn-page protection hence not used in real life production unless you are on filesystem that prevents torn pages like ZFS. In this run it was slightly slower than the indexed baseline, which is useful: not every scary-looking durability knob gives you a heroic number. Fast storage, group commit, and workload shape matter more here than the marketing mythology around the setting.

Cheat 3: fsync=off 24,863 TPS, 1.07x.
This removes the core durability guarantee entirely. The surprisingly small gain is the story. On this hardware, PostgreSQL is already amortizing sync cost well enough that the nuclear option barely moves throughput. It sounds dramatic, but the graph barely cares.

Cheat 4: checkpoint tuning 23,048 TPS, 0.99x.
Larger WAL and smoother checkpoints are normal tuning trade-offs between write smoothness and recovery behavior. In this 120-second isolated run, checkpoint tuning did not move throughput. On a longer, more checkpoint-bound workload it might matter more, but here the dramatic story is elsewhere.

Cheat 5: all durability off 25,349 TPS, 1.09x.
This stacks the scary durability switches, and still only reaches 1.09x over the indexed baseline. That is almost disappointing if the goal is a villainous benchmark. On this NVMe machine, durability cheating is not the magic lever; it is mostly noise dressed as danger.

Cheat 6: less work 44,777 TPS, 1.93x.
Drop the SELECT, the FK check, and the audit insert/cleanup, and PostgreSQL gets much faster. Incredible discovery: doing less work is faster. This is the easiest benchmark trick because the number is real, the graph is honest, and the workload quietly stopped being the same workload.

Cheat 7: UNLOGGED ledger/audit 37,016 TPS, 1.60x.
UNLOGGED tables skip WAL for the high-churn ledger/audit writes, so each transaction writes much less. This is a real PostgreSQL feature and a good fit for disposable or rebuildable data. It is a terrible fit for a ledger you expect to survive a crash (or database restart).

Cheat 8: Stored Procedure 46,126 TPS, 1.99x.
One PL/pgSQL CALL replaces multiple client/server round trips. The database is not doing less logical work; the application is wasting less time. This is a legitimate optimization when the workload fits it, but unfair if the comparison target does not get its equivalent server-side execution path.

Cheat 9: Function (SQL) 70,626 TPS, 3.05x.
This was the cleanest respectable win. A LANGUAGE sql function performs the same logical work but avoids the PL/pgSQL interpreter’s per-statement context switch overhead. If I wanted a PostgreSQL-positive hero result without any shame, this would be the one.

Cheat 10: prepared protocol 31,250 TPS, 1.35x.
pgbench protocol=prepared reuses prepared statements and avoids repeated parse/analyze/plan overhead. This is absolutely legitimate; many real applications use prepared statements through drivers. It becomes dishonest only when your database gets prepared execution and the comparison target gets ad-hoc SQL.

Cheat 11: SQL function + prepared 70,796 TPS, 3.05x.
This combines server-side execution with prepared protocol. Interestingly, it lands almost exactly where the SQL function already was. The big win is still moving the transaction logic server-side; prepared execution helps, but the function shape dominates.

Cheat 12: batching x8–104,466 reported OPS, but 13,058 TPS.
Now the y-axis starts doing marketing work. Each transaction performs eight account operations, so I can report operations/second instead of transactions/second and claim 4.51x over the indexed baseline.

Cheat 13: batching x32–130,092 reported OPS, but only 4,065 TPS.
The headline gets bigger while the transaction rate gets worse. That is perfect benchmark theatre. In operations/second it looks like 5.61x.

Grand finale: all cheats + batch x32 (SQL function) = 363,915 reported OPS
Everything is stacked: SQL function, prepared protocol, batching 32 operations per transaction, relaxed durability, and less integrity work. The result is 363,915 operations/second, or 15.70x over the indexed baseline and 649x over the crippled Case 0 baseline. The number is not fake. The framing is the trick.

The honest conclusion :
**************************************************************

My dishonest benchmark starts with bad code, fixes the missing index, changes durability, changes WAL behavior, changes checkpoint behavior, removes work, uses unlogged tables, hides round trips inside PL/pgSQL, batches operations, and then uses prepared protocol.

The TPS chart goes up and to the right.

That is exactly what a good marketing chart should do.

But the more interesting lesson is not that benchmarks can be manipulated. Everyone serious already knows that.

The interesting lesson is that PostgreSQL has enough mature, boring, production-grade machinery that even a dishonest benchmark has to use real PostgreSQL features to cheat convincingly.

That is the best kind of promotion.

Small disclaimer
 — — — — — — — —

I do not work for a PostgreSQL company. There is no secret Postgres marketing department wiring me money in unmarked WAL segments.

I am using PostgreSQL because I know it well enough to cheat with it properly. The same performance benchmark ladder could be built with MariaDB, MySQL or almost any serious open-source database.

The details would change. The crime scene would still look familiar.

References :

[1] PlanetScale, “Transparency in benchmarking”, 5 May 2026. The post argues for allowing public benchmarks, removing DeWitt clauses, and using expectations around fairness and transparency. https://planetscale.com/blog/transparency-in-benchmarking

[2] Databricks, “Eliminating the DeWitt Clause for Database Benchmarking”, 8 Nov 2021. Useful background on Oracle, the Wisconsin Benchmark, and how DeWitt-style clauses spread through database contracts. https://www.databricks.com/blog/2021/11/08/eliminating-the-dewitt-clause-for-database-benchmarking.html

[3] Brent Ozar, “The DeWitt Clause: Why You Rarely See Database Benchmarks”, 7 May 2018. Practical explanation of why DeWitt clauses chilled named comparative benchmarking. https://www.brentozar.com/archive/2018/05/the-dewitt-clause-why-you-rarely-see-database-benchmarks/

[4] David A. Wheeler, “The DeWitt clause censorship should be illegal”, 25 Jun 2017. Defines the clause as license language preventing publication of product benchmarks without supplier approval. https://dwheeler.com/essays/dewitt-clause.html

This is a practical conversion guide: common “naughty” query patterns and the simplest ways to turn each into a “nice list” version that is faster, more predictable, and less likely to ruin your on-call holidays.

1) Naughty: SELECT * on wide tables (~100 columns)

Why it’s naughty

• Wider tuples cost more everywhere: more memory bandwidth, more cache misses, bigger sort/hash entries, more network payload.
• Index-only becomes impossible: if you request 100 columns, the planner can’t satisfy the query from a narrow index, so you force heap fetches.
• You pay a bigger “spill tax”: wide rows make sorts/aggregations spill to disk sooner.

Extra naughty in the HTAP era

Postgres is increasingly “one database, multiple workloads.” Columnar/analytics options (e.g., Orioledb, Hydra Columnar; DuckDB-backed columnstore/engine integrations) make projection discipline even more decisive, because columnar execution reads only the referenced columns so selecting fewer columns directly reduces I/O and CPU.

Nice list fixes

• Always select only what you need.

Santa verdict: If you didn’t need the column, don’t fetch it, don’t carry it, don’t ship it.

2) Naughty: WHERE tenant_id = $1 ... ORDER BY x LIMIT N that hits the “ORDER BY + LIMIT optimizer quirk”

Why it’s naughty

This is a classic planner trap: the optimizer tries to be clever and exploit an index that matches ORDER BY, so it can stop early with LIMIT. But if the filtering predicate is satisfied “elsewhere” (joins, correlations, distribution skew), Postgres may end up scanning far more rows than expected before it finds the first N that qualify. That’s the performance cliff.

When it goes bad, you see:

• Long response time (scanning deep into an index to find qualifying rows)
• High temp usage if the alternative plan sorts a large intermediate set and spills

Nice list fixes :

A. “Make the smart optimizer more stupid” (the + 0 trick)
In some cases, you can deliberately prevent the planner from matching the ORDER BY to an index by turning it into an expression, e.g. ORDER BY x + 0, which can force a different (often better) join order / plan. This is a common workaround used in the wild.

SELECT id, tenant_id, x
FROM events
WHERE tenant_id = $1
ORDER BY x+0
LIMIT 200;

B: Create covering index or Increasing default_statistics_target

ALTER TABLE events
ALTER COLUMN tenant_id SET STATISTICS 1666;

Santa verdict: LIMIT is only a turbo button if the engine can find the first rows without searching the entire parking lot.

3) Naughty: idle-in-transaction (refcursor + client think time)

Why it’s naughty (and this one is pure coal)

Idle-in-transaction is a vacuum’s worst enemy:

• It pins an old snapshot, so autovacuum can’t reclaim dead tuples that still might be visible.
• Bloat grows, indexes bloat, and eventually your “mystery slowness” appears.
• Meanwhile the backend is doing nothing, just holding the database hostage.

The refcursor pattern often creates this by design:

1. Begin transaction
2. Open cursor
3. Fetch some rows
4. Client does slow work (several minutes to hours)
5. Cursor stays open, transaction stays open

Nice list fixes

• Don’t do application think-time inside a DB transaction. Fetch quickly, commit, process outside, then write back in a new transaction.
• If you must stream: keep the stream continuous, not “fetch then pause.”
• Enforce guardrails:

ALTER ROLE app_user SET idle_in_transaction_session_timeout = '30s';
ALTER ROLE app_user SET statement_timeout = '2min';

Quick detector:

SELECT pid, usename, wait_event, now() - xact_start AS tx_age, query
FROM pg_stat_activity
WHERE state = 'idle in transaction'
ORDER BY 4 DESC;

Santa verdict: A transaction is not a tote bag. Don’t carry it around while you do errands.

4) Naughty: mega-CTE chains (WITH a AS (...), b AS (...), c AS (...) ...)

Why it’s naughty

Long WITH pipelines can compound rowcount estimation errors. Once estimates are off, everything downstream is at risk: join order, join type, memory sizing, spill behavior. Also a big headache for prod support teams in debugging production functional or data quality issues.

Best nice-list option : split into temp tables

This gives you:

• a clean pipeline boundary
• the ability to ANALYZE intermediate results (real stats)
• tactical indexes on stages that matter

Pattern:

DROP TABLE IF EXISTS stage1;
CREATE TEMP TABLE stage1 AS
SELECT ...;

ANALYZE stage1;

CREATE INDEX ON stage1 (join_key);

DROP TABLE IF EXISTS stage2;
CREATE TEMP TABLE stage2 AS
SELECT ...
FROM stage1
JOIN ...;

ANALYZE stage2;

DROP TABLE IF EXISTS stage3;
CREATE TEMP TABLE stage3 AS
SELECT ...
FROM stage2
JOIN ...;

ANALYZE stage3;
.
.
.
.

On “pg_catalog bloat” issue : in practice, I have seen bigger wins from good autovacuum tuning (cost limit/delay, scale factors, number of workers) than from worrying about catalog bloat as a primary performance constraint.

Also: yes, many of us are still waiting for “true global temp tables someday.” (pgtt extension doesn’t do anything to reduce catalog bloat)

Santa verdict: If the planner can’t see the pipeline clearly, give it stages and statistics.

5) Naughty: wildcard search LIKE '%foo%' (and friends)

Why it’s naughty

A normal B-tree index can only help when the pattern is anchored at the start (e.g., col LIKE 'foo%'), not when it starts with %.

Nice list fixes

Fix A: pg_trgm

CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE INDEX CONCURRENTLY ON docs USING gin (title gin_trgm_ops);

pg_trgm provides GIN/GiST operator classes for fast similarity and pattern searches.

Fix B: Biscuit (newer alternative)
Biscuit is an index access method designed specifically for fast LIKE/ILIKE pattern matching and claims to reduce trigram “recheck overhead” for wildcard-heavy queries. Evaluate it on your data and query mix.
GitHub

Santa verdict: Leading % turns your index into holiday decoration: pretty, not load-bearing.

6) Naughty: functions on indexed columns (WHERE lower(email) = ...)

Why it’s naughty

You turned an indexable predicate into an expression; without an expression index, Postgres often can’t use your B-tree index effectively.

Nice list fixes

CREATE INDEX CONCURRENTLY ON users ((lower(email)));

SELECT ...
FROM users
WHERE lower(email) = lower($1);

Santa verdict: If you wrap the column, index the wrapper.

7) Naughty: OR conditions that derail index usage (a = 1 OR b = 2)

Why it’s naughty

OR predicates can push the planner into a compromise plan: either scan too much, or pick a strategy that’s great for one branch and terrible for the other.

Nice list fixes

Split with UNION ALL (careful to preserve semantics):

SELECT ... FROM t WHERE a = 1
UNION ALL
SELECT ... FROM t WHERE b = 2 ;

Santa verdict: OR is two queries wearing one trench coat.

8) Naughty: mismatched join types / implicit casts on join keys

Why it’s naughty

If join keys don’t match types, you can:

• prevent index usage
• trigger repeated casting on large relations
• get unexpected nested loops

Nice list fixes

• Fix schema types where possible.
• Otherwise cast the parameter, not the column:

WHERE t.uuid_col = $1::uuid

Santa verdict: If your join keys can’t agree on a type, they shouldn’t be meeting in production.

9) Naughty: missing indexes for join keys / foreign keys (especially on large tables)

Why it’s naughty

• Joins devolve into large hash builds or repeated scans.
• Deletes/updates on referenced tables become expensive due to referential checks.

Nice list fixes

CREATE INDEX CONCURRENTLY ON child (parent_id);

Experimental (not for Prod yet) : Working on an extension to prevent unindexed foreign keys from going in production. FKHunter (Any improvement suggestions are welcome)

Santa verdict: Foreign keys without supporting indexes are a gift you gave yourself…. with no receipt.

10) Naughty: SELECT DISTINCT as a band-aid for join explosions

Why it’s naughty

DISTINCT often hides:

• missing join predicates
• unintended many-to-many relationships
• data modeling issues

It forces a sort or hash aggregate on an inflated intermediate result.

Nice list fixes

• Fix the join.

Santa verdict: DISTINCT is not deodorant.

If Santa finds your SQL on the Naughty List, don’t take it personally but take it as a to-do list. Pick one offender this week, run EXPLAIN (ANALYZE, BUFFERS), apply the smallest “Nice List” fix, and measure the win. Do that ten times and you won’t just get better latency; you’ll get a calmer pager, and a database that actually feels like it’s on holiday too.

PS: Extra content for holidy season

SQL-Claus Before :

SQL-Claus Now :

AI Generated SQL-Claus Last Christmas vs AI Generated SQL-Claus Today. Some would say AI lost it’s soul in rat race of larger models, previous SQL-Claus meme had a character.

1. Postgres backends start disappearing.
2. dmesg / journalctl -k shows the kernel OOM killer reaping postgres.
3. Someone spots “out of memory” and reflexively recommends: “Increase work_mem.”

That recommendation is frequently backwards for OS OOM kills.

The linguistic trap: “Out of memory” sounds like “not enough work_mem”

work_mem is not “memory for the query.” It is a base, per-operation budget for executor nodes like sorts and hash tables before they spill to temporary files. PostgreSQL’s own docs explicitly warn that a complex query can run multiple sort/hash operations concurrently, and many sessions can do this at the same time so total memory can be many times work_mem.

If you raise work_mem globally, you are raising the ceiling on many potential concurrent memory consumers. That can turn “rare spike” into “frequent OOM kill.”

OS OOM kill vs “Postgres OOM”: two different failure modes

There are two scenarios people accidentally conflate:

• Executor spills to disk (healthy): Postgres hits a per-node memory budget and writes temp files.
• Kernel OOM kill (host-level failure): Linux cannot satisfy memory demands (often influenced by overcommit behavior) and terminates a process to keep the system alive.

In other words: if the kernel is killing Postgres, “give Postgres permission to use even more memory next time” is not a stabilizing strategy.

The source code says: work_mem is “allowed memory,” then spill to temp files

The tuplesort implementation is blunt about the design: it keeps tuples in memory up to the limit and then switches to temporary “tapes” (temp files) for an external sort.

A tiny excerpt from src/backend/utils/sort/tuplesort.c (Doxygen):

/* ... memory allowed ... (most pass work_mem) ... */
...
/* If we do exceed workMem, we begin to emit tuples ... temporary tapes. */

This is why “spilling” isn’t synonymous with “misconfigured”. It’s the planned safety valve.

Hash nodes can blow past the base: hash_mem_multiplier is literally in the math

Hash operations are not capped at work_mem. Postgres computes the hash memory limit as:

{
    double      mem_limit;
 
    /* Do initial calculation in double arithmetic */
    mem_limit = (double) work_mem * hash_mem_multiplier * 1024.0;
 
    /* Clamp in case it doesn't fit in size_t */
    mem_limit = Min(mem_limit, (double) SIZE_MAX);
 
    return (size_t) mem_limit;
}

That’s get_hash_memory_limit() in src/backend/executor/nodeHash.c. Doxygen

The docs also spell out the implications:

• Hash memory limit = work_mem * hash_mem_multiplier
• Default hash_mem_multiplier is 2 (so hash nodes may target ~2× work_mem)

So if someone says “we set work_mem=128MB, we’re safe,” but you have concurrent HashAgg/HashJoin/Memoize activity, your effective per-node appetite can be meaningfully higher than they think.

Why increasing work_mem can make OOM kills more frequent

Here’s the mental model that avoids the trap:

work_mem is a multiplier applied by concurrency.

A crude (but useful) worst-case sketch:

• active_sessions = 150 (Typically when a connection pooler is used and peak clients are several thousand then you could end up with few hundred active sessions)
• Conservative assumption that each session runs a query that (at peak) has 2 sorts + 1 hash agg concurrently (3 operations)
• work_mem = 64MB
• hash_mem_multiplier = 2.0

Then memory budget pressure can look like:

• Sort side: 150 * 2 * 64MB = 19,200MB
• Hash side (approx): 150 * 1 * (64MB * 2) = 19,200MB

You are already around ~38GB of just sort/hash budgets, before counting:

• backend overhead, memory contexts, connection-local memory
• shared memory, OS cache dynamics, other processes
• parallel query workers (more processes, more operations)

Now imagine someone “fixes” OOM kills by doubling work_mem to 128MB. That same sketch becomes ~76GB. If the host has 64GB RAM, you didn’t tune performance instead you scheduled the next kill.

This is why pganalyze’s guidance for frequent OOM errors starts with: reduce work_mem to improve stability, accepting more disk spill as the tradeoff. pganalyze

A practical playbook: stabilize first, then optimize surgically

If you want fewer OOM kills and good performance, separate global defaults from intentional exceptions:

1) Confirm it’s a kernel OOM kill (not just query failure)

• Check journalctl -k / dmesg for OOM killer messages (process name/PID, reaped memory).

2) Make temp spill observable (because spill is the designed safety valve)

Turn on temp file logging to see which queries are forcing external sorts / hash batching:

• log_temp_files = 0 (log all temp files) or set a threshold in kB

Also consider:

• temp_file_limit to prevent a single session from consuming unbounded temp space (it cancels the transaction when exceeded). PostgreSQL

3) Set a conservative global work_mem, then raise it only where justified

• Keep a modest default that survives peak concurrency.
• For the one reporting job / ETL / admin session that benefits from more memory, use targeted increases:
  SET LOCAL work_mem = '128MB'; inside a transaction
  or ALTER ROLE reporting_user SET work_mem = '128MB';

This preserves cluster stability while still enabling fast “big” queries.

4) Use EXPLAIN to validate the tradeoff

You want to see spills when needed, not crashes:

• Sort Method: external merge with disk usage is a normal outcome when data exceeds budget.
• Hash nodes show batching when they spill.

5) Don’t ignore Linux overcommit behavior

In overcommit-heavy configurations, you can get killed before Postgres can gracefully error and log a memory context dump. Cybertec and Postgres community guidance often points to disabling overcommit (or otherwise managing it) to avoid OOM-killer surprise terminations. CYBERTEC PostgreSQL | Services & Support

This rant blogpost is my attempt to explain why.

LLMs: Optimizing for the Next Token, Not for Reality

Let’s start with the core problem:

LLMs don’t optimize for truth.
They optimize for “what word statistically looks good next?”

Give a model the text:

“Postgres DBAs love”

It might happily continue with:

“Oracle”

From there, it feeds its own output back in and keeps predicting the next token again and again. At no point does it pause and say: “Wait, does this actually represent reality?”

It has no built-in concept of reality or verification. That’s your job.

As long as this is the operating model, hallucinations are not a bug but they are a feature. They’re what you get when you combine probability with confidence and zero shame. We’re basically wiring a very polite, very confident intern to production and asking it architectural questions.

What could go wrong?

“Hallucinations” Is Just a Fancy Word for “We Noticed the Lie”

I liked one line from an MIT Tech Review piece: “It’s all hallucination, but we just call it that when we notice.”

Most of the time, when the answer is “good enough”, we call it “AI magic”.
When it’s wrong in a way we understand, suddenly it becomes “hallucination”.

From a former physics student perspective, this is just non zero probability in action. We already live with quantum tunneling and in theory there’s a very very small but finite probability your laptop falls through the table while reading this paragraph. So the idea that an AI occasionally invents a Postgres feature, a config parameter, or even a fake “Postgres founder” called Michael Stockbroker is not that hard to digest.

Minimizing Hallucinations ≠ Eliminating Them

Yes, there are techniques:

• Retrieval-augmented generation (RAG)
• Better prompts.
• Constraining answers to a small domain.
• Larger training data, new improved models.

They help. They reduce the probability of a lie.
They never turn it into zero. So instead of asking, “How do we make AI always right?” We should be asking, “What happens to systems and teams when AI is wrong in confident, creative ways?”

That’s where Postgres DBA’s job security enters the chat.

Postgres vs AI: Field Reports from the Trenches

We don’t need theory. Just look at the real world of Postgres chats, blogs, and forums.

1. The Adaptive Optimizer That Doesn’t Exist

One popular LinkedIn post proudly announced that Postgres now has an adaptive optimizer, just like Oracle changing plans mid-execution, magically fixing bad queries at runtime.

Reality check:

• Postgres does not have Oracle-style adaptive optimizer.
• People migrating from Oracle to Postgres often wish it did.
• Most serious Oracle deployments especially in finance domain don’t enable adaptive optimization in production anyway. They value predictable latency, not “charismatic magic” that wakes up once every blue moon and wrecks your critical workload.

But somewhere, an LLM saw enough Oracle docs, blogs, and forum posts and decided: “Postgres is a database. Oracle is a database. Adaptive optimizer is cool. Therefore, Postgres now has an adaptive optimizer.”

And now that garbage is in the content pool.

2. “Even ChatGPT Failed to Answer This!”

From Postgres community chat: user confused about why something wasn’t working.

LLM confidently explained that '' (empty quoted whitespace) is the same as NULL.
Humans: “No. That’s not NULL. That’s just an empty string. Here’s why.”
One line from a human fixed it.
An LLM left the user more confused.

3. TTL Indexes in Postgres? Sure, Why Not

Someone shows up: “I read about TTL indexes in Postgres, how do I use them?”

Short answer from the community: “You don’t. Postgres doesn’t have native TTL indexes.”

Of course, you can build TTL-like behavior with partitioning and pg_cron schedular based archival/dropping of old, unnecessary partitions. But there’s no single magical TTL index type like in some other databases.

LLMs, however, happily remix MongoDB + Postgres content into: “Here’s how to create a TTL index in Postgres”

And now we’re babysitting that.

4. “Just Tweak the Background Workers in Prod”

One of my favorites: AI confidently suggesting users adjust internal Postgres background workers in ways no sane human would recommend to any developer.

This is the kind of advice that:

• Looks sophisticated
• Sounds low-risk
• Is absolutely not for casual experimentation on prod instances

Once that advice leaks into tutorials/blogs, it slowly contaminates future AI training runs. Then the next generation of LLMs produces even more polished nonsense.

High-quality garbage. With headings.

5. LLM induced extra work

An LLM confidently advises: “Now you should rebuild all indexes to be safe.”

No, you shouldn’t.

• Reindexing everything after a successful upgrade is an unnecessary time sink, risk that adds downtime to upgrade.
• LLM probably got confused with reindexing required on OS update due to (in)famous glibc issue.

But sure, if someone blindly follows it, that’s:

• Extra downtime,
• Extra IO,
• Extra DBA hours.

6. Two Node Patroni HA with Autofailover 🤡

“Design a 2-node Patroni HA cluster with auto-failover. DCS, Postgres, Patroni all on just two machines.”

LLM: “Of course! Here’s a step-by-step guide…”

Human DBA: “No. Just… no. You are designing a split-brain machine.”

Because in a network partition with two nodes, both can think they’re the primary. And then you have:

• Diverged writes
• Broken constraints
• Business screaming
• Audit logs full of horror

Who saves the day?
Not the LLM.

Data Cannibalism: When AI Starts Eating Its Own Slop

Another fun part of this story: data cannibalism.

As more AI generated content floods the internet:

• That content gets scraped into future training data.
• The model trains on its own previous guesses.
• Errors compound.
• Rare edge cases vanish.
• Details blur and collapse toward generic nonsense.

There’s already published work showing that models trained on AI generated data collapse over generations. And estimates that we may run out of clean human generated data for training in a few years, depending on how aggressively we keep training new models.

Even worse: those estimates often don’t factor in how much AI slop humans are now posting as their own “blog posts” and “whitepapers”.

One research paper about Postgres I came across had very clear indicators of being LLM generated fake :

• “In the digital world…” as intro
• AI-generated fake graphs : A misspelling in the chart title but correct text in the caption
• And it credited Postgres to founder “Michael Stockbroker”

So we’re seeding the future with:

• Invented features
• Incorrect design patterns
• Misleading performance “benchmarks”
• Fake Subject Matter Experts

This is the stuff going into future model training sets.
Enjoy your model collapse.

Meanwhile, humans DBAs become more valuable, not less.

So… What Can AI Safely Do for Postgres?

Despite all this, I’m not anti-Automation.
I’m anti-“AI as a magical production architect”.

There are areas where narrow AI with limited scope for creativity can be useful:

1. DB Parameter Tuning (Within Limits)

Tools like DBTune that:

• Suggest reasonable shared_buffers, work_mem etc Parameter ranges.
• Maybe even propose changes in a Git-style diff

This is bounded, repeatable, and easy to verify. Worst case, you roll back a config.

2. Index Advisors

Systems that:

• Analyze postgres logs, waits and pg_stat_statements
• Suggest candidate indexes
• Estimate bloat and usage

As long as they stay in “advisor” mode and a human reviews changes before applying, they’re super helpful. Think pganalyze style, not “Let the LLM directly CREATE INDEX in prod at 11:55 before Black Friday”.

3. Ops Automation

Great use cases:

• Alerting on txid wraparound risk
• Growing storage before it fills
• Notifying you when replication lag spikes
• Automating some backup/restore checks

Basically: if it’s mechanical, measurable, and reversible automation is powerful.

Future of AI for DBAs: Expectation vs Reality

Expectation:
AI agents write all the code, optimize all the queries, run all the operations.
DBAs disappear. Everything is self-healing.

Reality:

• AI generates weird schemas, terrible queries, and unsafe designs.
• AI hallucinates Postgres features that don’t exist.
• AI amplifies bad advice from old mailing list threads.
• Startups implement this stuff directly in production.
• Systems break in more creative ways than ever before.

And then those companies:

• Hire senior DBAs
• Pay more per hour
• Prioritize performance & reliability
• Buy support contracts they previously refused

So if you’re a DBA worrying about AI taking your job, relax. You’re going to be busy.

Very, very busy.

PS: By popular demand, I’ve included some extra AI-generated content. I accept no liability, take zero responsibility, and fully classify the following as AI slop found in the wild.

I pushed the most boring change imaginable, add an index. Our CI/CD pipeline is textbook ==> spin up a fresh DB, run every migration file in one single transaction, in sequential manner. If anything hiccups, the whole thing rolls back and the change never hits main. Foolproof autotests.

Enter The Drama Queen :

ERROR: cannot CREATE INDEX "index_name_xyz" on table abcdef_tab
because it is being used by active queries in this session

This session. Same PID, same transaction. No parallel runner. No second connection. Still blocked.

Our schema migration repository structure is as shown above. CI tool will create a fresh DB → execute all scripts chronlogically → one by one → one transaction → one session as a part of an autotest before merging any new code (dml/ddl for schema migration = infra as a code) to main branch.

Naturally ignoring last part of error message like a seasoned DBA, I accused CI tool of going rogue, maybe someone “optimized” migrations to run in parallel after reading a LLM pep talk about “unleashing concurrency.”

I printed the PID at the start and end of every file.

-- Stamp the migration transaction
SELECT 'start', pg_backend_pid(), txid_current();
-- ... run all migration steps ...
SELECT 'end',   pg_backend_pid(), txid_current();

Same PID. Same transaction. Same sadness.

One of the least talked about but best Postgres feature as a FOSS project is that you can search error message in code base and documentation is excellent.

• In indexcmds.c, PostgreSQL calls CheckTableNotInUse(rel, "CREATE INDEX"); before proceeding. The comment explains why: otherwise an in-progress INSERT/UPDATE in this same session could have already picked its list of target indexes and would not update the new one. doxygen.postgresql.org

• CheckTableNotInUse() (in tablecmds.c) raises
  ERROR: cannot %s "%s" because it is being used by active queries in this session
  when the relation’s refcount shows it’s still in use by the current backend (or if there are pending AFTER triggers).

It clearly says just above CheckTableNotInUsethat there’s an open cursor or active plan.

“Disallow ALTER TABLE (and similar commands) when the current backend has any open reference to the target table besides the one just acquired by the calling command; this implies there’s an open cursor or active plan.”

So not another session. This session. And if there’s no parallelism and no second plan lingering, what’s left? As Sherlock Holmes would say: once you eliminate the impossible, whatever remains, however improbable…. is that one open cursor someone forgot to close.

I slapped a CLOSE ALL; at the top of the migration file just to test the hypothesis. Boom => green CI. Then I hunted down the culprit, a recently added explicit cursor loop (OPEN …; FETCH …;) instead of a tidy FOR r IN SELECT … LOOP.

The cursor never got closed, so the relation stayed referenced, and Postgres (correctly) refused.

In short: my session blocked….. my session. Peak self-sabotage.

Simple fix: stop leaking cursors. Prefer FOR rec IN SELECT … LOOP (implicit cursor) or explicitly CLOSE the cursor (also in EXCEPTION block).

PS : Slightly off topic but doxygen.postgresql.org is cool.
A piece of history : Magnus Hagander announcing auto-generated source code documentation (not the user manual).

Community Day ~ people > hype

• PostgreSQL & AI Summit: I sat on the panel and played “Team Human” vs Skynet (As advised by John Connor in the future).
  postgresql.eu
• “Establishing the PostgreSQL standard: What’s Postgres compatible?”
  Half-day workshop, lot of brain storming and discussion split into groups then presenting your group’s conclusion on what makes postgres derivatives compatible with community postgres. We spun up a Telegram group to keep building the rubric post-conference. postgresql.eu

Coffee with CYBERTEC (meeting Laurenz Albe)

• Picked the “Coffee with CYBERTEC” option to meet Laurenz Albe, the most prolific Stack Overflow answerer.
• We traded notes on most popular features to adopt from other databases, their feasibility, and why Postgres avoided them historically.

I left with a starting map for contributing to core.

Talks I caught (and why they stuck)

“Don’t do that!” — Laurenz Albe
A rapid-fire list of Postgres anti-patterns. Simple, blunt, useful from the most beloved speaker of the conference. (postgresql.eu)

Parsing Postgres logs the non-pgBadger way — Kaarel Moppel
Meet pgweasel. Lean CLI. Fast. Cloud-friendly. For prod support, less noise beats glossy graphs. I’m convinced. (postgresql.eu)
https://github.com/kmoppel/pgweasel

Improved freezing in VACUUM — Melanie Plageman
Cleaner anti-wraparound story. Scan all-visible (not all-frozen) pages early; fewer emergency freezes later. Sensible, much needed change. (postgresql.eu)

Patroni + pgBackRest: better together — Stefan Fercot
Power couple of Postgres, best HA tool with best Backup tool. Tight HA+DR integration. Bootstrap from backups, safe standby rebuilds, PITR under Patroni’s control. (postgresql.eu)

DBTune: AI-driven tuning
Autonomous parameter tuning across self-hosted and managed Postgres. Looks mature enough for a lab trial. I’m tempted to test in QA. (postgresql.eu)

The SyncRep Detective Story
Fascinating detective story and scientific approach to tracing root cause. Resonated with my past setup where commit_delay/commit_siblings helped on AWS networked storage. (postgresql.eu)

MultiXacts: usage, side-effects, monitoring — Divya Sharma
Row-lock pileups and vacuum side effects, explained. We don’t hit them often in current company (rareSELECT … FOR UPDATE), but I left with better alarms to build. (postgresql.eu)

Fast-path locking in PG18 — Tomas Vondra
Shines with many relations and partitions. We’re light on partitioning at current company, so the gains will be modest for us. Still, good progress. (postgresql.eu)

Patroni: what the blog posts don’t tell you — Cameron Murdoch
The “missing manual”: hardening, proxies, DCS choices, failsafe option and upgrades. (postgresql.eu)

We have multiple concurrent versions of this title trying to understand MVCC (Boris Mejias)
It’s hard to describe this talk cause you have to experience it live to fully appreciate the second best database comedian in the world.

Tracking plan shapes over time — pg_stat_plans (Lukas Fittl)
Plan IDs + pg_stat_plans let you watch plan drift over time. This will be gold for catching plan fluctuations. (postgresql.eu)
https://github.com/pganalyze/pg_stat_plans

Conference vibe

Riga was friendly. Hallway track was lively. Slonik worked overtime and loved the camera. See you next year.

PS: If you are still suffering from Postgres conference hangover and crave more Postgres content then head over to Prague next month for Prague Postgres Meetup or in January for P2D2 conference.

13 REASONS WHY YOU SHOULD ATTEND P2D2 PRAGUE?

🗓️ Wednesday, Oct 22 — Warming Up the Buffers

11:15 – 12:05 in Omega 1 : Don’t Do That!
Laurenz Albe reminds us that every bad Postgres habit comes with a sequel called “incident report.”

13:05 – 13:35 in Omega 2 : Parsing Postgres Logs the Non-pgBadger Way
Kaarel Moppel shows that pgweasel and caffeine can out-analyze any dashboard.

13:45–14:35 in Alfa : Improved Freezing in Postgres Vacuum: From Idea to Commit
Melanie Plageman walks us through the icy depths of tuple immortality.

14:45–15:35 in Omega 2 : Operational Hazards of Running PostgreSQL Beyond 100 TB
Teresa Lopes shares real stories and engineering lessons from scaling Postgres into the terabyte realm, where every decision costs you.

16:05–16:55 in Omega 2 : What You Should Know About Constraints (and What’s New in 18)
Gülçin Yıldırım Jelínek explores how new enhancement to constraints in PG 18 make data integrity both smarter and more flexible.

17:05–17:55 in Omega 1 : Hacking pgvector for Performance
Daniel Krefl reveals clever hacks to push filtering and indexing deeper into pgvector for faster, leaner similarity searches.

🧱 Thursday, October 23 — The Day of Observability and Enlightenment

09:25–10:15 in Omega 2 : Unified Observability: Monitoring Postgres Anywhere with OpenTelemetry (Yogesh Jain)
Learn how to unify metrics, logs, and traces across cloud, containers, and bare-metal Postgres instances using OpenTelemetry to build scalable, vendor-agnostic observability.

10:25–10:55 in Omega 1 : EXPLAIN: Make It Make Sense (Aivars Kalvāns)
Find out how to turn cryptic EXPLAIN output into actionable insights, mapping planner nodes to real costs so you can tame rogue queries.

11:25–12:15 in Alfa : The SyncRep Detective Story: Chasing Ghosts in PostgreSQL, Finding Demons in Storage
Dmitry Fomin unravels a real performance mystery and exorcises the demons hiding deep inside the storage.

13:55–14:45 in Alfa : AIO in PG 18 and Beyond (Andres Freund)
Explore how asynchronous I/O enhancements in Postgres 18 shift the performance landscape.

14:55–15:45 in Omega 1 : Table Repacking, Done Right (Álvaro Herrera & Antonin Houska)
Learn how REPACK CONCURRENTLY (targeting Postgres 19) can deflate bloat without downtime, how it works under the hood, and how it might rescue frustrated DBAs from locking hell.

15:55–16:25 in Omega 2 : All About Common Vulnerabilities and Exposures in PostgreSQL (Priyanka Chatterjee)
Get real: dissect real CVEs in PostgreSQL, see how they were exploited, and learn how to protect your systems before headlines hit.

🧨 Friday, October 24 — The Day of Failures, Recovery & Redemption

09:25–10:15 in Omega 2 : PostgreSQL as a Graph Database: Who Grabbed a Beer Together? (Taras Kloba)
Taras compares Apache AGE, pgRouting, and pgGraph in a live demo to show how PostgreSQL can moonlight as a graph database and map community connections (yes, including who met at the bar).

10:25–10:55 in Omega 1 : Fast-Path Locking Improvements in PG18
Tomas Vondra takes us on a deep dive into lock manager refinements in PG 18 that reduce contention latency in hot, high-load scenarios.

11:25–12:15 in Omega 1 : Patroni: What the Blog Posts Don’t Tell You… (Cameron Murdoch)
Cameron pulls back the curtain on real Patroni deployments: split-brain, failover pitfalls, and the nitty-gritty never documented.

13:15–13:45 in Omega 2 : Tracking Plan Shapes Over Time with Plan IDs & the New pg_stat_plans (Lukas Fittl)
Lukas unveils how plan ID versioning and the new pg_stat_plans help you track plan drift, regressions, and performance ghosts over time.

13:55–14:45 in Alfa : We Have Multiple Concurrent Versions of This Title Trying to Understand MVCC (Boriss Mejias)
Boriss leads you through concurrency, snapshot races, and how Postgres keeps isolation sane in the chaos of multiversions.

14:55–15:45 in Omega 2 : Database in Distress: Testing and Repairing Different Types of Database Corruption (Josef Machytka)
Forensic lab of data corruption cases and how to surgically repair them.

16:15–17:00 in Omega 1 : Lightning Talks (Maybe you?)
A wild finale: short, sharp experiments, hacks, and stories to spark ideas and laugh off days of log parsing.

Not all heroes wear capes. In PostgreSQL, some don’t even write code.

At PGDay Austria, Floor Drees highlighted this truth: countless contributions to PostgreSQL happen outside of code commits and patches.

Floor introduced postgres-contrib.org, a website launched in July 2024 by members of the community. Its mission is simple but powerful, celebrate the people behind PostgreSQL. Advocates, conference organizers, volunteers, speakers, bloggers, sysadmins, the security team, the Code of Conduct committee, the funding group… the list goes on.

Curious, I asked if folks who tirelessly answer questions on PostgreSQL Slack and Telegram could also be recognized. Floor and Christoph Berg explained that measuring contributions on such fluid, fast-moving platforms is difficult. Still, Floor encouraged me to write about them and even to add my own blog to Planet PostgreSQL (Finally😄).

I’ve noticed a trend, more people are asking questions on Slack or Telegram than on the classic mailing lists. For those coming from other databases, pgsql-hackers can feel intimidating. By contrast, Slack and Telegram provide approachable, beginner-to-intermediate spaces where conversations flow naturally.

So, taking Floor’s suggestion to heart, here’s my first attempt at spotlighting a few unsung heroes.

This is only the beginning, many more names will follow.

A. Postgres Slack

To join: https://pgtreats.info/slack-invite

Slack is my go-to platform. Threads keep discussions tidy, and I spend most of my time there. These are some of the community members I see helping every day.

Depesz — Spot the legendary orange hairs in your thread, and you know help has arrived. One of the most prolific and consistent experts on Postgres slack.

Jeremy Schneider — Jeremy answers both cloud and bare-metal questions, and you’ll also find him sharing wisdom in the Aurora channel.

Ants Aasma — A performance problem? Ants has an answer. Every. Single. Time.

B. Postgres Telegram

https://t.me/postgreschat

I haven’t spent as much time here yet, but one name already shines through.

Stefanie Janine Stölting — Admin of the group, and always ready with sharp, technical answers.

This list is just the start. PostgreSQL thrives because of the people who show up, share knowledge, and support others. I’ll be adding more names in the next round.

Philosophy behind “PG Scorecard”:

Postgres is an open-source database boasting an impressive 30-year legacy and a potent network effect. Its vibrant community has nurtured enduring credibility and resilience.

Naturally, emerging database startups want to harness this “Network effect” by claiming Postgres compatibility. Yet, without intrinsic checks on such assertions, this risks spiraling out of control and enticing malevolent actors.

The Postgres Compatibility Index aims to create an open-source framework to validate these claims. My drive to introduce automated tests stems from the need to compare user experiences between the community edition and the more flamboyant, serverless, cloud-based, or specialized derivatives. Are users granted the same freedom, flexibility, and reliability they enjoy with the community version of PostgreSQL?
For example, Technically a cloud vendor can be compatible to Postgres however by not allowing freedom to use external programming language such as pl/perl,pl/python or C functions you would be denying users same experience as on self hosted community Postgresql.

For now, I’ve sidelined the obvious champions such as EDB Postgres, Azure FlexiServer, Amazon RDS, and Google CloudSQL. Time’s the culprit. By day, I’m a DBA; by weekend, a coder. They’ll join the fray when the clock permits.

There are lot of complex tests that I would like to have but not figured out yet how to incorporate them. If you wish to contribute tests or code, please submit a pull request.

MIT Licenced code so feel free to contribute and improve it.

Contribut to scoring methodology code here ==> pci_autotest.py

Are you a vendor itching to showcase your creation?

Run autotest.py against your database. Send a pull request with the JSON output, logs, and screenshots. Step into the spotlight.

Need your favorite db featured on site ==> Outputs

Update: In response to a trademark notice from the PostgreSQL Community Association of Canada, domain has been changed from “Postgres.Is” to pgscorecard.com