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

Some even joked that if DSQL truly is PostgreSQL compatible, why Larry Ellison has not proclaimed Oracle to be the world’s most PostgreSQL-compatible enterprise database?

This notion lingered in my mind when I encountered Gunnar (the former lead at Debezium) and Tudor (CTO of Xata) in a discussion about standardizing what it truly means to be PostgreSQL-compatible. Inspired by their exchange, I went on to create the Postgres Compatibility Index.

Postgres Compatibility Index (PCI)

• PCI runs a battery of tests on the database in question, poking at every feature Postgres has to offer.
• Each feature is scored, depending on whether it works, or implodes spectacularly.
• The results are weighted, calculated, and distilled into a single PCI score, a percentage of compatibility perfection.

•The code for the PostgreSQL Compatibility Index (PCI) is freely available under the MIT License, because the journey to compatibility should be a collaborative effort.

•Feel free to explore the repository and send a PR to help enhance PCI for the entire Postgres community:
PostgreSQL Compatibility Index on GitHub

Next Level :

Web app is built upon the dynamic JSON output produced by running pci_autotest.py

Visit => PG Scorecard

You can compare various attributes of different postgres derivatives.

Or

You can see how postgres derivates fare for a specific attribute.

If you want your favorite postgres derivative to feature on website then just run pci_autotest.py and send me json output generated or if you are cloud provider then give me your free tier account. :-) .

POSTGRES IS

While the Postgres Compatibility Index meticulously addresses the technical facets of PostgreSQL, it also prompts a deeper, philosophical inquiry: What does it truly mean to be PostgreSQL? To explore this question, I draw upon Philip K. Dick’s “Human Is” as a metaphor, reflecting on the evolution of PostgreSQL over three transformative decades. Following series of memes eloquently conveys what a thousand words alone could not capture.

1. AI?

2. GraphDB?

3. Event streaming engine?

4. Timeseries database?

5. Document database?

6. Geospatial analytics tool?

7. A Search engine?

8. Data-lake?

9. Data Ecosystem

10. A Working Class Hero

11. Galactus?

12. Postgres Is

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

But while we DBAs gaze at these marvels with starry-eyed wonder, QA teams hunker down in Helm’s Deep, bracing for the inevitable orc army of compatibility bugs. They’ve seen the promises before, and they know the truth: “compatible” is often just marketing speak for “we hope it mostly works.”

DBAs love the idea of embracing the future. We get excited when a new database claims to support distributed transactions, vector embeddings, and geospatial analytics while still being Postgres at heart. Imagine the scalability! The performance boosts! The bragging rights in Slack!

But QA? QA sees a Mordor of testing cycles, long nights, and a hundred Jira tickets labeled “Regression: Foreign Key not supported.”

The One Index to Rule Them All

Enter the PostgreSQL Compatibility Index (PCI): a tool to help both DBAs and QA teams navigate this epic saga. The PCI is like the Council of Elrond — everyone gets to know the facts, lay their cards on the table, and decide whether this new database is the Aragorn we need or just another Boromir, doomed to fail us at a critical moment.

Here’s how it works:

• PCI runs a battery of tests on the database in question, poking at every feature Postgres has to offer.
• Each feature is scored, depending on whether it works, or implodes spectacularly.
• The results are weighted, calculated, and distilled into a single PCI score, a percentage of compatibility perfection.

And just like Gandalf, PCI doesn’t pull punches. It will expose the Balrog-sized gaps in compatibility that marketing conveniently forgot to mention.

For the Manual Wizards in the Realm of Compatibility

Not every compatibility journey requires the magic of automated tests — sometimes, a manual spellbook does the trick. The PostgreSQL Compatibility Index (PCI) also allows you to calculate scores manually by crafting a JSON input file with a fixed set of characteristics as defined in pci_calculator.py.

For instance, here’s how the PCI score was conjured for databases like CockroachDB, Amazon DSQL, and Yugabyte, using manually filled JSON files.

Below is an example of the input json for Yugabyte.

{
    "data_types": {
        "Primitive Types": "full",
        "Complex Types": "partial",
        "JSONB": "full",
        "Geospatial Types": "partial",
        "Custom Types": "full",
        "Full-Text Search": "full",
        "Vector": "no"
    },
    "ddl_features": {
        "Schemas": "full",
        "Sequences": "full",
        "Views": "full",
        "Materialized Views": "full"
    },
    "sql_features": {
        "CTEs": "full",
        "Upsert": "full",
        "Window Functions": "full",
        "Subqueries": "full"
    },
    "procedural_features": {
        "Stored Procedures": "full",
        "Functions": "full",
        "Triggers": "full"
    },
    "transaction_features": {
        "ACID Compliance": "full",
        "Isolation Levels": "full",
        "Nested Transactions": "no",
        "Row-Level Locking": "full"
    },
    "extensions": {
        "Extension Support": "partial",
        "Foreign Data Wrappers": "partial",
        "Custom Plugins": "partial"
    },
    "performance": {
        "Index Types": "partial",
        "Partitioning": "full",
        "Parallel Query Execution": "no"
    },
    "constraints": {
        "Foreign Key": "full",
        "Check": "full",
        "Not Null": "full",
        "Unique": "full",
        "Exclusion": "no"
    },
    "security": {
        "Role Management": "full",
        "GRANT/REVOKE Privileges": "full",
        "Row-Level Security": "full"
    },
    "replication": {
        "Streaming Replication": "full",
        "Logical Replication": "full"
    },
    "notifications": {
        "LISTEN/NOTIFY": "no",
        "Event Triggers": "no"
    },
    "miscellaneous": {
        "Temporary Tables": "full",
        "Monitoring and Statistics": "full"
    },
    "utilities": {
        "pg_dump": "full",
        "pg_stat_statements": "full",
        "pg_walinspect": "no",
        "amcheck": "full"
    },
    "penalty": {
        "superuser_restricted": "no",
        "transaction_limits": "no",
        "read_limits": "no"
    }
}

Why the manual mode? Because automating tests for every single characteristic using only SQL/PLpgSQL can feel like forging the One Ring — it’s a monumental task, especially when new-gen databases uses different nomenclatures or semantics for core features. For these situations, manual mode is your trusty sword and shield.

So the next time a database vendor claims “Postgres compatibility,” don’t just trust the marketing pitch. Run PCI, check the score, and then decide whether you’re leading your team to Gondor — or straight into Mordor.

Join the Quest: Open Source Awaits!

The code for the PostgreSQL Compatibility Index (PCI) is freely available under the MIT License, because the journey to compatibility should be a collaborative effort. Whether you’re inspired to add new features, improve existing ones, or simply sharpen the edges of the tool, your contributions are welcome!

Feel free to explore the repository and send a PR to help enhance PCI for the entire Postgres community:
PostgreSQL Compatibility Index on GitHub

May your queries be efficient, your indexes be optimized, and your compatibility claims… actually compatible.