Latest Blog Posts

All Your GUCs in a Row: backslash_quote
Posted by Christophe Pettus in pgExperts on 2026-05-14 at 01:00
A 2006 SQL injection vulnerability and multibyte character encodings created `backslash_quote`, a GUC parameter that remains in PostgreSQL for backward…

Postgres May 2026 Security Update: 11 CVEs, All Versions Affected
Posted by Robins Tharakan on 2026-05-13 at 15:28

It's that time again. The upcoming Postgres v18.4 release (along with minor releases for all Major versions) has dropped some serious hints in the git logs, and it's bringing a significant payload of CVE tagged patches. As a seasoned Postgres end-user and an erstwhile DBA, whenever I see a flurry of high-vulnerability security commits, I immediately start recommending that customers begin planning their patching cycles.

(Note: As these patches are hot off the press, official CVSS scores and detailed advisories from NVD and postgresql.org are still pending. The severity scores listed below are estimates at best. I'll update this post with links to the NVD and the postgresql.org site as soon as they're available.)

Tom Lane: Last-minute updates for release notes.
Security: CVE-2026-6472, CVE-2026-6473, CVE-2026-6474, CVE-2026-6475, CVE-2026-6476, CVE-2026-6477, CVE-2026-6478, CVE-2026-6479, CVE-2026-6575, CVE-2026-6637, CVE-2026-6638

Let's quickly take a quick look at the CVE list:

The Memory and Overflow Fixes

  • CVE-2026-6472 (Estimated Severity: Medium) — Missing CREATE Privilege Check on Multirange Types. (Backpatched to: 14, 15, 16, 17, 18)
  • CVE-2026-6473 (Estimated Severity: High) — The Memory Overflow Ghost. (Backpatched to: 14, 15, 16, 17, 18)
  • CVE-2026-6474 (Estimated Severity: Medium) — Unsafe pg_strftime() handling. (Backpatched to: 14, 15, 16, 17, 18)
  • CVE-2026-6477 (Estimated Severity: High) — Frontend Large Object Buffer Overruns. (Backpatched to: 14, 15, 16, 17, 18)

The Replication and Backup Vulnerabilities

  • CVE-2026-6475 (Estimated Severity: Critical) — Path Traversal in pg_basebackup & pg_rewind. (Backpatched to: 14, 15, 16, 17, 18)
  • CVE-2026-6476 (Estimated Severity: High) — SQL Injection in pg_createsubscriber. (Backpatched to: 17, 18 — pg_createsubscriber was introduced in v17)
  • CVE-2026-6638 (Estimated Severity: High) — SQL Injection in Logical Replication. (Backpatched to: 16, 17, 18)

The Cryptograp

[...]

Twenty Years in pgcrypto
Posted by Christophe Pettus in pgExperts on 2026-05-13 at 15:00
A heap buffer overflow in pgcrypto's OpenPGP code lurked for two decades—until a December 2025 exploit made it real.

pg_statviz 1.0 released with AI-powered analysis
Posted by Jimmy Angelakos on 2026-05-13 at 12:37

pg_statviz logo

I'm excited to announce release 1.0 of pg_statviz, the minimalist extension and utility pair for time series analysis and visualization of PostgreSQL internal statistics.

This is a major release that introduces a new optional capability: AI-powered analysis. With the new --ai flag, each chart's data and PNG are sent to a vision-capable LLM along with Senior PostgreSQL DBA-level context, and the model produces a [HEALTHY] / [WARNING] / [CRITICAL] verdict, a short interpretation, and a concrete remediation step for any [WARNING] or [CRITICAL] finding. Reports are written as HTML pages, created alongside the chart PNGs, with a top-level index.html synthesising the per-module findings into a single summary.

AI report sample

The new features:

  • Three AI providers, one flag: --ai claude for Anthropic Claude (the default), --ai gemini for Google AI Studio's free-tier Gemini 2.5 Flash, and --ai local for an Ollama instance running a vision-capable model such as gemma4:e4b (the recommended local default). All three are entirely optional: pg_statviz still installs and runs with zero AI dependencies, and the new [ai] extra (pip install pg_statviz[ai]) pulls in only what you ask for.
  • Per-module HTML reports embed each chart PNG and render the LLM's markdown analysis with status badges and styled paragraphs. A new top-level index.html report aggregates per-chart verdicts and asks the model to synthesise them, identifying correlated patterns across charts (for example, a WAL spike alongside long-running sessions) and surfacing the single most important next action.
  • Deterministic rules engine runs checks on the actual numeric data before the LLM call. Findings are injected into the prompt as additional context, and a severity floor enforces that the final verdict can never be downgraded below the worst rule finding, so an overly optimistic LLM can't quietly hide a real problem.
  • Configuration-aware prompts: the relevant pg_settings for each chart (shared_buffers and bgwriter_* for buffers
[...]

CNPG Recipe 24 - Migrating from Crunchy PGO to PostgreSQL 18 with CloudNativePG
Posted by Gabriele Bartolini in EDB on 2026-05-13 at 10:21

A step-by-step guide to migrating a PostgreSQL 17 cluster managed by Crunchy PGO v6 to PostgreSQL 18 under CloudNativePG. Two paths are covered: a fully declarative offline migration using CloudNativePG’s built-in pg_dump import, and an online migration using native PostgreSQL logical replication for a near-zero-downtime cutover.

Contributions for week 18, 2026
Posted by Cornelia Biacsics in postgres-contrib.org on 2026-05-13 at 06:10

PGConf Belgium took place on 5 May 2026, organized by Wim Bertels, An Vercammen, and Grégory Gioffredi , who served also at the talk selection team.

Speaker:

  • Jan Karremans
  • Boriss Mejias
  • Dwarka Rao
  • Emrah Becer
  • Robert Treat
  • Franck Pachot
  • Mohsin Ejaz
  • Afroditi Loukidou
  • Gianni Ciolli
  • Bruce Momijan
  • Matt Cornillon
  • Xavier Fisher
  • Thijs Lemmens
  • Josef Machytka

Claire Giordano and Aaron Wislang hosted and published a new podcast episode on May 6, 2026 From MemSQL to HorizonDB, an engineer's journey with Adam Prout from the Talking Postgres series.

On May 7 2026, Andreas Scherbaum, Daria Aleshkova, Sergey Dudoladov and Oleksii Kliukin organized the Berlin PostgreSQL May Meetup. Robert Treat and Celeste Horgan spoke at this event.

On May 7 2026, Jimmy Angelakos organized the PostgreSQL Edinburgh Meetup May 2026. River MacLeod, Jim Gardner and Jimmy Angelakos delivered a talk.

All Your GUCs in a Row: backend_flush_after
Posted by Christophe Pettus in pgExperts on 2026-05-13 at 01:00
PostgreSQL's complicated relationship with the Linux page cache spawns four GUCs to manage writeback—and backend_flush_after is the conservative one.

Snowflake Postgres, Lakebase, HorizonDB: Picking the Lock-In You Want
Posted by Christophe Pettus in pgExperts on 2026-05-12 at 15:00
Three major cloud platforms just shipped Postgres with custom storage engines and scale-out architectures.

Managed Postgres, Examined: Google Cloud SQL for PostgreSQL
Posted by Christophe Pettus in pgExperts on 2026-05-12 at 13:00
Google's managed PostgreSQL returns to first principles: a conventional instance on a VM with a regional disk, plus a distinctive data cache on Enterprise Plus…

Two projects, one mission - hackorum and pginbox join forces
Posted by Kai Wagner in Percona on 2026-05-12 at 11:15

Last week, Zsolt and I jumped on a call with someone who had been building something remarkably similar to what we had been working on, completely independently. That someone is Jack Bonatakis, the creator of pginbox.dev, and that call turned into one of the most energizing conversations we’ve had since launching hackorum.dev.

Two builders, one problem

When we launched Hackorum back in January, the goal was simple but important: make the pg-hackers mailing list actually readable. The list is the heartbeat of PostgreSQL core development, patches are proposed, debated, iterated on, and committed entirely through it. But the interface? Decades-old email threads. Dense, fast-moving, and not exactly welcoming to newcomers or even experienced contributors trying to manage the volume.

All Your GUCs in a Row: autovacuum_worker_slots
Posted by Christophe Pettus in pgExperts on 2026-05-12 at 01:00
PostgreSQL 18 splits autovacuum configuration to finally let you tune worker concurrency without restarting.

ParadeDB is Officially on Render
Posted by Ming Ying in ParadeDB on 2026-05-12 at 00:00
Deploy ParadeDB on Render with one click. Full-text search, vector search, and hybrid search over Postgres — now available on your favorite cloud platform.

What’s New in pg_clickhouse
Posted by David Wheeler on 2026-05-11 at 20:24

Bit of a news catchup on the pg_clickhouse project.

What’s New

First up, a couple weeks ago the ClickHouse Blog published What’s New in pg_clickhouse, in which I covered various improvements to the extension:

We’ve been gratified by the community reception of pg_clickhouse, the extension to query ClickHouse databases from Postgres. Recent uptake generated a ton of feedback, which we’ve been diligently addressing in the last few releases. These changes follow our constant mantra for pg_clickhouse: pushdown, pushdown, pushdown! Let’s take a quick tour.

It includes working pushdown examples for JSONB accessors, SQL value functions like CURRENT_TIMESTAMP, array functions like array_cat() and array_to_string(). It wraps with a demonstration of HTTP result set streaming, with a nice bar char for the before and after (spoiler: pg_clickhouse’s http driver became far more memory-efficient).

v0.3.0

But that’s not all. Today we released pg_clickhouse 0.3.0. Nothing drives improvements like customer issues, and v0.3.0 features a slew of them, including:

  • Mapping for the ClickHouse JSON type to the PostgreSQL JSONB type in the binary driver; it was already supported for the HTTP driver.

  • Support for mapping the Postgres JSON type to the ClickHouse JSON type. In general JSONB better matches ClickHouse JSON semantics, but we wanted to support the obvious alternative.

  • Pushdown for the Postgres to_char(timestamp[tz], fmt) function to the ClickHouse formatDateTime() function for formats that map to binary-compatible equivalents: YYYY, MM, DD, DDD, HH24, HH12, HH, MI, SS, Q, Mon, Dy, AM/PM, plus lowercase variants.

  • Support for pushing down functions from the new re2 extension, which provides ClickHouse-compatible RE2-backed regular expression functio

[...]

SSL in PostgreSQL
Posted by SHRIDHAR KHANAL in Stormatics on 2026-05-11 at 15:09

A beginner’s guide to encrypting your database connections

“’SSL is enabled’ and ‘SSL is actually working’ are two very different things.”

1. What is SSL, and why does a database need
it?

SSL stands for Secure Sockets Layer. Its successor is TLS (Transport Layer Security), but in the PostgreSQL world, and in most documentation, people still call it SSL out of old habit. Don’t let that confuse you. When someone says “SSL” in a Postgres context, they mean modern TLS-based encryption.

Here’s the problem it solves. By default, when your application connects to PostgreSQL, everything travels across the network in plain text. Usernames. Passwords. Every query you run. Every row of data that comes back. If anyone can intercept that traffic, someone on the same network, a compromised internal service, they can read all of it. A basic packet sniffer is enough. No special skills needed.

SSL wraps that connection in encryption before any data is exchanged. What travels on the wire becomes unreadable noise to anyone who doesn’t hold the session keys.

ℹ Note:  Even inside a private network or VPC, this matters. And the “it’s an internal network” line doesn’t protect you from lateral movement attacks, where an attacker is already inside the perimeter

2. How does SSL actually work?

When a client connects to PostgreSQL with SSL, before any database traffic is exchanged, this sequence happens: The client opens a plain TCP connection and signals it wants SSL. The server sends its certificate — a signed document that proves the server’s identity and contains its public key. The client checks whether that certificate was signed by a Certificate Authority it trusts, and whether the hostname in the certificate matches what it is connected to. If both checks pass, both sides negotiate a cipher and derive a shared session key. After that, all PostgreSQL traffic — authenticat

[...]

The wal_level You Set Is Not the wal_level You Get
Posted by Christophe Pettus in pgExperts on 2026-05-11 at 15:00
PostgreSQL 19 finally lets wal_level adapt dynamically to your actual replication slots, eliminating the always-on WAL cost of logical standby insurance.

Making JSONB More Queryable with Generated Columns
Posted by Richard Yen on 2026-05-11 at 06:00

Introduction

Over the past year, I’ve worked in a handful of contexts managing large volumes of data stored as JSONB in PostgreSQL. The scenario is common: users appreciate the flexibility of a document-oriented storage model, avoiding the need to predefine schemas or constantly migrate table structures as their data requirements evolve. JSONB documents can be deeply nested with numerous optional fields, and they scale to hundreds of kilobytes per record without issue. However, when the time comes to query these documents – filtering by user ID, event type, timestamps, or nested action properties – the queries can become slow and/or cumbersome to work with.

The problem I want to address is: “How do we make searching JSONB data more efficient without breaking apart our documents or forcing it into columns in a relational database?” There are several approaches available in Postgres, each with different tradeoffs. I hope to shed some light on those approaches in this article.

The Setup

I created a basic, no-frills table for the sake of this test: 

CREATE TABLE events (
    id BIGSERIAL PRIMARY KEY,
    data JSONB NOT NULL
);

Here's the document shape I used for testing and writing this post -- it's representative of the event logs and audit trails I've encountered: a mix of primitive fields, nested objects, and metadata that accumulates over time.

-- Representative JSONB document
{
  "user_id": 5234,
  "event_type": "event_42",
  "timestamp": 1712341200,
  "session_id": "sess_abc123...",
  "ip_address": "192.168.1.42",
  "action": {
    "type": "click",
    "target_id": 87654,
    "coordinates": {"x": 512, "y": 768},
    "duration_ms": 1234
  },
  "device": {
    "type": "mobile",
    "os": "iOS",
    "screen_width": 1920,
    "screen_height": 1080
  },
  "performance": {
    "page_load_time": 1234,
    "dns_lookup": 123,
    "tcp_connection": 234,
    "server_response": 876
  },
  "custom_fields": { ... }
}

The queries that matter are straightforward equality and range filters on known

[...]

All Your GUCs in a Row: autovacuum_work_mem
Posted by Christophe Pettus in pgExperts on 2026-05-11 at 01:00
autovacuum_work_mem sets the maximum memory each autovacuum worker may use for tracking dead tuple identifiers (TIDs) during a vacuum. Default is -1, which means “inherit from maintenance_work_mem.” Context is sighup. The parameter exists so that autovacuum’s memory consumption can be tuned indep…

All Your GUCs in a Row: autovacuum_vacuum_scale_factor and autovacuum_vacuum_threshold
Posted by Christophe Pettus in pgExperts on 2026-05-10 at 01:00
Autovacuum's most powerful tuning lever: the scale factor that determines when dead tuples trigger a vacuum. On large tables, the 20% default waits too long.

Strong views on PostgreSQL VIEWs
Posted by Radim Marek on 2026-05-10 at 00:00

VIEWs should be the cleanest abstraction SQL, and therefore Postgres, has on offer. I love the concept. The promise of decoupling logical intent from physical storage is perfect on paper. In practice, few things in the database world trigger such a heated debate or carry as much historical baggage. VIEWs mix big promises with false hopes, and the promises rarely survive contact with production.

The appeal is straightforward. Abstract "active customer" once and reuse it everywhere. Every query, report and dashboard uses the same definition. The "active customer" then becomes the foundation of a "customer orders" view, which in turn powers an operational "customer summary" view. 

-- layer 1: who counts as an active customer?
CREATE VIEW active_customers AS
SELECT c.*
FROM customers c
WHERE c.deleted_at IS NULL
  AND c.status = 'active'
  AND c.last_login_at > now() - interval '90 days';

-- layer 2: active customers with their recent orders
CREATE VIEW customer_orders AS
SELECT
    ac.*,
    o.id         AS order_id,
    o.total_cents,
    o.created_at AS ordered_at,
    o.status     AS order_status
FROM active_customers ac
LEFT JOIN orders o ON o.customer_id = ac.id
WHERE o.created_at > now() - interval '12 months'
   OR o.created_at IS NULL;

-- layer 3: one row per customer, ready for the dashboard
CREATE VIEW customer_summary AS
SELECT
    co.id,
    co.email,
    co.name,
    COUNT(co.order_id)                                   AS orders_12mo,
    COALESCE(SUM(co.total_cents), 0)                     AS revenue_12mo_cents,
    MAX(co.ordered_at)                                   AS last_order_at,
    COUNT(*) FILTER (WHERE co.order_status = 'refunded') AS refunds_12mo
FROM customer_orders co
GROUP BY co.id, co.email, co.name;

Each layer has one job. "Active customer" is defined exactly once - if marketing changes the ninety-day rule tomorrow, it is one line in one place, and the dashboard query collapses to SELECT * FROM customer_summary WHERE id = $1.

VIEWs also have the potential to be a real se

[...]

All Your GUCs in a Row: autovacuum_vacuum_max_threshold
Posted by Christophe Pettus in pgExperts on 2026-05-09 at 01:00
PostgreSQL 18 finally fixes the autovacuum formula that left billion-row tables waiting for 200M dead tuples.

A Field Guide to Alternative Storage Engines for PostgreSQL
Posted by Christophe Pettus in pgExperts on 2026-05-08 at 17:30
Six years after PostgreSQL shipped the table access method API, the alternative storage engine ecosystem is thriving—but messier than early predictions…

pg_lake vs Lakebase: Two Very Different Things Called “Postgres + Lakehouse”
Posted by Christophe Pettus in pgExperts on 2026-05-08 at 15:00
Snowflake's pg_lake and Databricks' Lakebase both wrap PostgreSQL for lakehouse workloads, but they're nearly opposite architectures.

No Compiler Required: Writing SQL-Only Postgres Extensions
Posted by Shaun Thomas in pgEdge on 2026-05-08 at 12:11

Recently at Postgres Conference 2026 in San Jose, I presented a talk called Let's Build a Postgres Extension! Since that entire presentation was primarily focused on writing a C extension while exploring the Postgres source code, I only mentioned pure SQL extensions as an aside. But what's more likely in the Postgres community in general: C devs, or people who know SQL?It turns out that you can do a lot with functions, triggers, views, tables, and various other Postgres-native capabilities. The extension system doesn't care whether the contents are compiled C or plain SQL. It just wants a control file, a SQL script, and an optional  to help with installation.So let's build a relatively trivial extension article entirely in SQL.

What Do We Want?

First things first: we need a plan. What should this extension actually do? I wrote about blocking DDL a while back with a C extension, so why not revisit that example with SQL?This being pure SQL, there are other handy elements we can add with very little effort, so how about:
  • A setting to enable or disable the extension.
  • A setting to allow or block superusers from executing DDL.
  • A role that allows members to bypass the DDL restriction.
  • A function to add users to the bypass role.
  • A function to remove users from the bypass role.
  • A view to see which users are in the bypass role.
  • An
  • event trigger
  •  to actually block DDL attempts.
Rather than a simple event trigger to prevent DDL execution, we are building a kind of DDL execution management suite. That should hopefully demonstrate just how capable a purely SQL implementation can be.

Three Files and a Dream

Every Postgres extension, regardless of complexity, boils down to the same basic structure:
  • A control file to describe the extension.
  • A SQL script to create the tables, views, functions, etc.
  • An optional Makefile to copy the SQL script and control file to the right place. Unlike a C project, there's no build step for a SQL-only extension bec
[...]

All Your GUCs in a Row: autovacuum_vacuum_insert_scale_factor and autovacuum_vacuum_insert_threshold
Posted by Christophe Pettus in pgExperts on 2026-05-08 at 01:00
PostgreSQL 13 added insert-triggered autovacuum to solve a critical problem: append-only tables never vacuumed, breaking index-only scans and delaying tuple…

Tracing PostgreSQL Using eBPF and Hardware Breakpoints
Posted by Jan Kristof Nidzwetzki on 2026-05-08 at 00:00

Hardware breakpoints can trigger eBPF programs when specific memory addresses are accessed, leveraging CPU hardware support for low overhead. By utilizing these hardware breakpoints, we can efficiently monitor PostgreSQL’s internal variable updates, such as transaction ID generation and OID assignment. In this post, we will discuss what hardware breakpoints are, whether they have less overhead than uprobes, and how to answer questions like “How many transactions are being executed per second?” or “Which backend is consuming the most OIDs?” with bpftrace.

In a previous blog post, I discussed how to use eBPF, uprobes/uretprobes, and bpftrace to monitor PostgreSQL’s internal functions, such as vacuum. uprobes and uretprobes trigger eBPF code in the Linux kernel when a function in user space is entered or exited. Even though uprobes and uretprobes have very low overhead, they still require instrumenting the function entry or exit with a software interrupt. That overhead is especially relevant for functions that are called very frequently. In contrast, hardware breakpoints use CPU hardware features to monitor specific memory addresses and trigger a real hardware interrupt when the monitored address is accessed. Therefore, they also let us catch all updates to a specific variable, even if it is updated in multiple functions, without instrumenting every function that touches it.

How Uprobes Work Under the Hood?

Uprobes and uretprobes instrument the function entry or exit by replacing the first few instructions with a software (int3) interrupt. When the function is called, the CPU executes the software interrupt, triggering a CPU mode switch that enables the eBPF program to run.

When the eBPF program finishes, the kernel needs to execute the instruction that was replaced with int3. This is called out-of-line execution and requires the kernel to run the original instruction separately, which adds additional overhead.

The instruction replacement can be observed in gdb by inspecting the first few byte

[...]

The Maintainer Is Not the Owner
Posted by Christophe Pettus in pgExperts on 2026-05-07 at 17:30
When a maintainer rewrites a project with AI and changes its license, they've crossed a line.

pgEdge Control Plane Adds Supporting Services and a Preview of systemd Support
Posted by Antony Pegg in pgEdge on 2026-05-07 at 17:20

Most Postgres management tools ask you to pick a lane. You can manage databases, or you can manage the services around them. You can run in containers, or you can run on bare metal. You get one deployment model, one operational surface, one set of assumptions about how your infrastructure works.The pgEdge Control Plane just added two features that refuse to pick a lane: Supporting Services and systemd Support. Together, they push the Control Plane into territory that, as far as we can tell, nobody else in the Postgres world is covering. Supporting Services is fully available, while the systemd support is currently a Preview feature.

Supporting Services: More Than Just Postgres

Here's the thing about enterprise Postgres in 2026: the database is only part of the story. Your AI agents need an MCP server to talk to the data, your applications need a REST API to query it, and your knowledge base needs a RAG server to index and retrieve from it. These services aren't optional extras, they're what make the database useful in production.Until now, you managed those services separately: different deployment pipelines, different configuration, different credentials, different monitoring. The database lived in one world and the services that depended on it lived in another, even though they're fundamentally coupled. When the database moves, the services need to follow, and when credentials rotate, every connected service needs to know about it. When you scale out, everything needs to come along for the ride.Supporting Services in the Control Plane fixes this by treating the database and its surrounding services as a single declarative unit. You add a array to the same JSON spec you already use for your database, and the Control Plane handles deployment, credential provisioning, health checking, and lifecycle management for everything together.That's a two-node distributed database with Spock multi-master replication, an MCP server for AI agent access on the US node, and PostgREST instances on both nodes for REST API [...]

Eight Bytes Is the Easy Part
Posted by Christophe Pettus in pgExperts on 2026-05-07 at 15:00
PostgreSQL 19 expands MultiXactOffset to 64 bits, eliminating a real outage failure mode. So when do regular transaction IDs get the same treatment?

You have a Patroni leader election. You are only halfway to PostgreSQL high availability.
Posted by Umair Shahid in Stormatics on 2026-05-07 at 10:40

A PostgreSQL primary loses power at 2am. Writes resume in under thirty seconds. The on-call engineer reads the alert in the morning, sees that the cluster healed itself, and goes back to coffee. That is the outcome PostgreSQL high availability is supposed to deliver.

A working Patroni cluster, on its own, gets you partway there. The leader election runs. A standby gets promoted. The cluster state in etcd stays consistent. Then the application keeps trying to reach an IP address that points at the wrong node now, the old primary needs a manual rejoin, and the on-call engineer is on a conference bridge instead of in bed.

I have seen this pattern enough times to call it the default. The cluster does its job. The application waits on a human. The runbook comes out. RTO passes the SLA. Everyone agrees afterward that “we should look at HA more seriously.”

The arithmetic of recovery time

The case for automation is mostly arithmetic.

When the cluster heals itself, the RTO clock starts at the failure detection and stops at the application’s first successful write. With Patroni’s TTL set to 30 seconds, a routing layer that follows promotion within another second or two, and an application that retries with backoff, the whole sequence finishes in under a minute. Often well under.

Bring a human into the loop, and a different clock starts. The monitoring system needs to detect the failure, group it into an alert, and deliver it to the on-call engineer’s pager. That alone is often 30 to 60 seconds. The engineer needs to wake up, find a laptop, log into the bastion, and load enough context to know what is happening. Even for a sharp on-call engineer ready at the keyboard, that is 5 to 10 minutes of best-case effort. Then comes the investigation: which node failed, what state the cluster is in, what is safe to do next. That is another 5 to 30 minutes depending on how clean the runbook is and how confident the engineer f

[...]

PG DATA 2026: The talks I am most excited about. Part 4 (the last one!)
Posted by Henrietta Dombrovskaya on 2026-05-07 at 02:08

That’s the last post of the series about the talks at the upcoming PG DATA 2026 conference, covering the remaining Friday talks.

Part 1

Part 2

Part 3

First, I wanted to mention two more talks presented by PG DATA organizers: Comparing Apples to Oranges with Postgres’ Type System by Dian Fay and Master Upgrading PostgreSQL, Using Real World stories and examples by Pat Wright. Dian’s talk is about Postgres types, and I can’t say enough how much I love the ability to create new types! Probably even more than I love Postgres extensions! Pat’s talk is about real-life upgrade stories, and although we know way too well that our own upgrades will present us with our unique challenges, it’s still worth learning from other people’s experience 🙂

Yet another real-life story is Apoorv Garg’s Electric SQL: Local -first Architecture. Building mobile applications is not something I am familiar with, but it looks like developers had to face familiar problems of reliability, performance, and security, which become especially challenging in the situation of a disappearing network.

Egor Tarasenko’s presentation, Streamlining Data Ingestion and Transformation with Trino + dbt, addresses a well-known problem: handling DDL changes in the source when they are not promptly communicated to the streaming process. I’ve seen multiple solutions to this problem, but none of them appeared to be perfect, so I’m very interested to hear Egor’s perspective.

Several presentations will address understanding and monitoring query execution. First is Alfredo Rodriguez’s presentation How to understand EXPLAIN without dying in the attempt. I remember Alfredo presenting at PG Day Chicago for the first time, and I know he is happy to be back with his by now well-known presentation. Then comes Mohsin Ejaz’s “Why your PostgreSQL tuning guide might be wrong (and what to do about it),” in which he shares DBTune’s perspective. And finally, Postgres plan monitoring and management in practice by Lukas Fittl. I am a great admirer of Lu

[...]

Top posters

Number of posts in the past two months

Top teams

Number of posts in the past two months

Feeds

Planet

  • Policy for being listed on Planet PostgreSQL.
  • Add your blog to Planet PostgreSQL.
  • List of all subscribed blogs.
  • Manage your registration.

Contact

Get in touch with the Planet PostgreSQL administrators at planet at postgresql.org.