Citus Data Blog

Distribute PostgreSQL 18 with Citus 14

Mehmet Yilmaz — 2026-02-17T17:00:00+00:00

The Citus 14.0 release is out and includes PostgreSQL 18 support! We know you've been waiting, and we've been hard at work adding features we believe will take your experience to the next level, focusing on bringing the Postgres 18 exciting improvements to you at distributed scale.

PostgreSQL 18 is a substantial release: asynchronous I/O (AIO), skip-scan for multicolumn B-tree indexes, uuidv7(), virtual generated columns by default, OAuth authentication, RETURNING OLD/NEW, and temporal constraints. For those of you who are interested in upgrading to Postgres 18 and scaling these new features of Postgres: you can upgrade to Citus 14.0!

Let's take a closer look at what's new in Citus 14.0:

Postgres 18 support in Citus 14.0
PostgreSQL 18 highlights that benefit Citus clusters
What Citus 14 adds for PostgreSQL 18 compatibility

Postgres 18 support in Citus 14.0

Citus 14.0 introduces support for PostgreSQL 18. This means that just by enabling PG18 in Citus 14.0, all the query performance improvements directly reflect on the Citus distributed queries, and several optimizer improvements benefit queries in Citus out of the box! Among the many new features in PG 18, the following capabilities enabled in Citus 14.0 are especially noteworthy for Citus users:

Faster scans and maintenance via AIO
Better index usage with skip-scan
uuidv7() for time-ordered UUIDs
OAuth authentication support
JSON_TABLE() COLUMNS
Temporal constraints
CREATE FOREIGN TABLE ... LIKE
Generated columns (Virtual by Default)
VACUUM/ANALYZE ONLY semantics
Constraints: NOT ENFORCED + partitioned-table additions
DML: RETURNING OLD/NEW
COPY expansions
MIN()/MAX() on arrays and composite types
Nondeterministic collations
sslkeylogfile connection parameter
Planner fix: enable_self_join_elimination
Utility/Ops plumbing and observability

To learn more about how you can use Citus 14.0 + PostgreSQL 18, as well as currently unsupported features and future work, you can consult the Citus 14.0 Updates page, which gives you detailed release notes.

PostgreSQL 18 highlights that benefit Citus clusters

Because Citus is implemented as a Postgres extension, the following PG18 improvements benefit your distributed cluster automatically—no Citus-specific changes needed.

Faster scans and maintenance via AIO

Postgres 18 adds an asynchronous I/O subsystem that can improve sequential scans, bitmap heap scans, and vacuuming—workloads that show up constantly in shard-heavy distributed clusters. This means your Citus cluster can benefit from faster table scans and more efficient maintenance operations without any code changes.

You can control the I/O method via the new io_method GUC:

-- Check the current I/O method
SHOW io_method;

Better index usage with skip-scan

Postgres 18 expands when multicolumn B-tree indexes can be used via skip scan, helping common multi-tenant schemas where predicates don't always constrain the leading index column. This is particularly valuable for Citus users with multi-tenant applications where queries often filter by non-leading columns.

-- Multi-tenant index: (tenant_id, created_at)
-- PG18 skip-scan lets this query use the index even without tenant_id
SELECT * FROM events
WHERE created_at > now() - interval '1 day'
ORDER BY created_at DESC
LIMIT 100;

uuidv7() for time-ordered UUIDs

Time-ordered UUIDs can reduce index churn and improve locality; Postgres 18 adds uuidv7(). This is especially useful for distributed tables where you want predictable ordering and better index performance across shards.

-- Use uuidv7() as a time-ordered primary key
CREATE TABLE events (
  id uuid DEFAULT uuidv7() PRIMARY KEY,
  tenant_id bigint,
  payload jsonb
);

SELECT create_distributed_table('events', 'tenant_id');

OAuth authentication support

Postgres 18 adds OAuth authentication, making it easier to plug database auth into modern SSO flows—often a practical requirement in multi-node deployments. This simplifies authentication management across your Citus coordinator and worker nodes.

What Citus 14 adds for PostgreSQL 18 compatibility

While the highlights above work out of the box, PG18 also introduces new SQL syntax and behavior changes that require Citus-specific work—parsing/deparsing, DDL propagation across coordinator + workers, and distributed execution correctness. Here's what we built to make these work end-to-end.

JSON_TABLE() COLUMNS

PG18 expands SQL/JSON JSON_TABLE() with a richer COLUMNS clause, making it easy to extract multiple fields from JSON documents in a single, typed table expression. Citus 14 ensures the syntax can be parsed/deparsed and executed consistently in distributed queries.

CREATE TABLE pg18_json_test (id serial PRIMARY KEY, data JSON);

SELECT jt.name, jt.age
FROM pg18_json_test,
     JSON_TABLE(
       data,
       '$.user'
       COLUMNS (
         age  INT  PATH '$.age',
         name TEXT PATH '$.name'
       )
     ) AS jt
WHERE jt.age BETWEEN 25 AND 35
ORDER BY jt.age, jt.name;

Temporal constraints

Postgres 18 adds temporal constraint syntax that Citus must propagate and preserve correctly:

WITHOUT OVERLAPS for PRIMARY KEY / UNIQUE
PERIOD for FOREIGN KEY

CREATE TABLE temporal_rng (
  id int4range,
  valid_at daterange,
  CONSTRAINT temporal_rng_pk PRIMARY KEY (id, valid_at WITHOUT OVERLAPS)
);

SELECT create_distributed_table('temporal_rng', 'id');

CREATE FOREIGN TABLE ... LIKE

Postgres 18 supports CREATE FOREIGN TABLE ... LIKE, letting you define a foreign table by copying the column layout (and optionally defaults/constraints/indexes) from an existing table. Citus 14 includes coverage so FDW workflows remain compatible in distributed environments.

-- Copy column layout from an existing table
CREATE FOREIGN TABLE my_ft (LIKE my_local_table EXCLUDING ALL)
  SERVER foreign_server
  OPTIONS (schema_name 'public', table_name 'my_local_table');

Generated columns (Virtual by Default)

PostgreSQL 18 changes generated column behavior significantly:

Virtual by default: Generated columns are now computed on read rather than stored, reducing write amplification
Logical replication support: New publish_generated_columns publication option for replicating generated values

CREATE TABLE events (
  id bigint,
  payload jsonb,
  payload_hash text GENERATED ALWAYS AS (md5(payload::text)) VIRTUAL
);

SELECT create_distributed_table('events', 'id');

VACUUM/ANALYZE ONLY semantics

Postgres 18 introduces ONLY for VACUUM and ANALYZE so you can explicitly target only the parent of a partitioned/inheritance tree without automatically processing children. Citus 14 adapts distributed utility-command behavior so ONLY works as intended.

-- Parent-only: do not recurse into partitions/children
VACUUM (ANALYZE) ONLY metrics;
ANALYZE ONLY metrics;

Constraints: NOT ENFORCED + partitioned-table additions

Postgres 18 expands constraint syntax in several ways that Citus must parse/deparse and propagate across coordinator + workers:

CHECK constraints can be marked NOT ENFORCED
FOREIGN KEY constraints can be marked NOT ENFORCED
NOT VALID foreign keys on partitioned tables
DROP CONSTRAINT ONLY on partitioned tables

ALTER TABLE orders
  ADD CONSTRAINT orders_amount_positive CHECK (amount > 0) NOT ENFORCED;

ALTER TABLE orders
  ADD CONSTRAINT orders_customer_fk
  FOREIGN KEY (customer_id) REFERENCES customers(id)
  NOT ENFORCED;

DML: RETURNING OLD/NEW

Postgres 18 lets RETURNING reference both the previous (old) and new (new) row values in INSERT/UPDATE/DELETE/MERGE. Citus 14 preserves these semantics in distributed execution.

UPDATE t
SET v = v + 1
WHERE id = 42
RETURNING old.v AS old_v, new.v AS new_v;

COPY expansions

PG18 adds two useful COPY improvements that Citus 14 supports in distributed queries:

COPY ... REJECT_LIMIT: set a threshold for how many rows can be rejected before the COPY fails, useful for resilient bulk loading into sharded tables
COPY table TO from materialized views: export data directly from materialized views

-- Tolerate up to 10 bad rows during bulk load
COPY my_distributed_table FROM '/data/import.csv'
  WITH (FORMAT csv, REJECT_LIMIT 10);

MIN()/MAX() on arrays and composite types

PG18 extends MIN() and MAX() aggregates to work on arrays and composite types. Citus 14 ensures these aggregates work correctly in distributed queries.

CREATE TABLE sensor_data (
  tenant_id bigint,
  readings int[]
);
SELECT create_distributed_table('sensor_data', 'tenant_id');

-- Now works with array columns
SELECT MIN(readings), MAX(readings) FROM sensor_data;

Nondeterministic collations

PG18 extends LIKE and text-position search functions to work with nondeterministic collations. Citus 14 verifies these work correctly across distributed queries.

sslkeylogfile connection parameter

PG18 adds the sslkeylogfile libpq connection parameter for dumping SSL key material, useful for debugging encrypted connections. Citus 14 allows configuring this via citus.node_conn_info so it works across inter-node connections.

Planner fix: enable_self_join_elimination

PG18 introduces the enable_self_join_elimination planner optimization. Citus 14 ensures this works correctly for joins between distributed and local tables, avoiding wrong results that could occur in early PG18 integration.

Utility/Ops plumbing and observability

Citus 14 adapts to PG18 interface/output changes that affect tooling and extension plumbing:

New GUC file_copy_method for CREATE DATABASE ... STRATEGY=FILE_COPY
EXPLAIN (WAL) adds a "WAL buffers full" field; Citus propagates it through distributed EXPLAIN output
New extension macro PG_MODULE_MAGIC_EXT so extensions can report name/version metadata
New libpq parameter sslkeylogfile support via citus.node_conn_info

Diving deeper into Citus 14.0 and distributed Postgres

To learn more about Citus 14.0, you can:

Check out the 14.0 Updates page to get the detailed release notes.

You can also stay connected on the Citus Slack and visit the Citus open source GitHub repo to see recent developments as well. If there's something you'd like to see next in Citus, feel free to also open a feature request issue :)

This article was originally published on citusdata.com.

Bits of wisdom from a year of Talking Postgres

Claire Giordano — 2025-07-22T16:21:00+00:00

A year ago we renamed the Talking Postgres podcast—and just published our 29th episode. Since it’s a monthly thing, that means 13 new conversations in the past year. So this feels like a good moment to pause, reflect, and share a few highlights.

If you’re already a listener, this post might help you find an episode you missed. If you’re new to the podcast, think of this as a sampler: a few favorite quotes, some backstory, and quick-hit summaries of each episode from the past year.

What is the Talking Postgres podcast? It's a long-form conversation—usually an hour, often more—with people in the Postgres world. We talk about what they do with Postgres, why they do it, and how they got started. (I’m a bit obsessed with origin stories.)

The show isn’t about features or how-to’s. It’s not about speeds and feeds. And it’s definitely not trying to sell you anything. It’s about the people behind Postgres—and what we can learn from each other.

In this post you’ll get highlights from the past 13 episodes of Talking Postgres, shared in reverse chronological order. These summaries can’t do the full episodes justice, but maybe they’ll inspire you to listen in.

And if you’re not a podcast person, maybe it's time to give it a try? Podcast listening in the US has grown from 170 million hours a week in 2015 to over 770 million hours per week in 2025. (Source: Share of Ear survey from Edison Research, via Podnews.net).

Figure 1: As of July 2025 we’ve had 41 amazing guests on the monthly Talking Postgres podcast (originally named Path To Citus Con, prior to the rename in 2024). The photos above are not in any particular order! Left-to-right, starting in the top row: Simon Willison, Floor Drees, Andres Freund, Melanie Plageman, Derk van Veen, Claire Giordano (that’s me), Paul Ramsey, Samay Sharma, Affan Dar, Regina Obe, Álvaro Herrera, Chelsea Dole, Heikki Linnakangas, Marco Slot, Lukas Fittl, Rob Treat, Jelte Fennema-Nio, Pino de Candia, Dimitri Fontaine, Grant Fritchey, Thomas Munro, Abdullah Ustuner, Vik Fearing, Teresa Giacomini, Tom Lane, Arda Aytekin, Ryan Booz, Chris Ellis, Daniel Gustafsson, Andrew Atkinson, David Rowley, Burak Yucesoy, Boriss Mejías, Michael Christofides, Aaron Wislang, Robert Haas, Dawn Wages, Bruce Momjian, Peter Farkas, Peter Cooper, and Shireesh Thota.

A listener’s take: Talking Postgres as “oral history”

Last October, I got a text from Thomas Munro—one of the Postgres committers, and someone I deeply respect. He said:

“btw, random comment: i think talking postgres is very cool, going very well, and i love what you are doing”

Naturally, I wanted to know more. So I asked. Thomas's reply:

“it's just a great podcast, you have a relaxed way to get people talking, and people are at ease with you. it’s a perfect format, and it feels quite natural. i don’t know, i just like it. the name is also working well. i was happy to see robert [haas] mentioning it the other day. it's a really nice part of the ecosystem and brings a positive human dimension to it. it's also a kind of documentary, a kind of oral history for the postgresql community.”

As Bruce Momjian likes to say, it costs nothing to show gratitude. The note from Thomas made my day that day—and I’m sharing it here in case it nudges someone else to give the podcast a listen.

From dreaming of driving a bus to leading database engineering at Microsoft

Listen to Episode 29

Shireesh Thota joined me to unpack his journey from early BASIC programming to leading all of database engineering at Microsoft Azure. (Fun fact: his childhood dream was to be a bus driver.)

I’ll admit, I thought it might be intimidating to interview my boss’s boss. But it wasn’t. Shireesh was down-to-earth, thoughtful, and full of stories—especially about the shift from IC to manager. One of his early lessons? You can’t manage people in the same way you write code.

Highlights of "How I got started leading database teams with Shireesh Thota"

The shift from developer to manager (if only people came with documentation)
Why it’s important for Microsoft to contribute to the PostgreSQL open source project
Whether Shireesh has a favorite database (hint: I want it to be Postgres)
Are there any plans to open source the new VS Code extension for Postgres?

What drives someone to publish 600+ issues of a Postgres newsletter?

Listen to Episode 28

I’d been wanting to get Peter Cooper on the podcast for a while. Peter is the creator of Postgres Weekly—my favorite developer newsletter—and the person behind a whole collection of dev newsletters that reach nearly half a million people each week.

But how to get Peter to a yes? I was still pondering that when Michael Christofides (founder of pgMustard, past guest on Talking Postgres, and co-host of Postgres FM) had the same idea: “You should invite Peter Cooper.”

As luck would have it, Peter—who lives in the UK—was visiting the San Francisco Bay Area. We met for coffee (no coffee was actually consumed), I pitched the idea, and he said yes.

Highlights of "12 years of Postgres Weekly with Peter Cooper"

How Peter built a newsletter empire that reaches nearly half a million developers each week
Trends in Postgres he’s seen from the editor’s seat
How the BBC's “big tent” shapes Peter’s editorial (& opinionated) voice
Where he finds the good stuff (all the useful Postgres links)

How does a trek to K2 base camp spark the idea for a database startup?

Listen to Episode 27

In this episode, Peter Farkas shared the origin story of FerretDB, an open source MongoDB alternative that first became an idea at 16,000 feet at the Himalayan K2 base camp. (Spoiler: “Ferret” wasn’t the original name.) We also talked about why Postgres was the obvious choice for FerretDB—and how Peter’s background in customer support has shaped his world view.

Highlights of "How I got started with FerretDB & why we chose Postgres with Peter Farkas"

What “true open source” means to Peter and FerretDB
How FerretDB now runs on the new, open-sourced DocumentDB extension
How Hungarian Trappist cheese 🧀 deserves a footnote in database history

What does it take to lead a global open source project like Postgres?

Listen to Episode 26

Bruce Momjian and I were both at PGConf India in Bangalore when he said yes to joining the podcast. Bruce has been part of Postgres since 1996, and he’s spent decades giving talks, writing, and teaching others about the database. So we had too many good topics to choose from.

We landed on one that felt especially relevant: what it means to lead in open source. Bruce shared stories, lessons, and a perspective that only comes from being in the trenches for nearly 30 years.

Highlights of "Open Source Leadership with Bruce Momjian"

Why servant leadership is such a good fit for open source
How being open to feedback can lead to a much higher quality result
Tips on becoming a good conference speaker
How it doesn’t cost you anything to show appreciation to people
Bruce’s early days on the project, co-founding the PostgreSQL Global Development Group

Why so many Python developers have an affinity for Postgres

Listen to Episode 25

When I first met Dawn Wages, we somehow got onto the topic of her book-in-progress, Domain-Driven Django. One chapter title jumped out at me: “Just Use Postgres.” Of course, I had questions.

At the time, Dawn was President of the Python Software Foundation—and I was curious to hear how a Django developer thinks about Postgres. Why do so many Python and Django devs seem to have such affection for it? This one’s part origin story, part practical wisdom, and part homage to Postgres.

Highlights of "Why Python developers just use Postgres with Dawn Wages"

Why does a book for Django developers deserve a chapter on Postgres?
Why “free as in puppies” beats “free as in cake”
How making really smart friends helps you in work (and in life)
Is Python the second-best language for everything?
Fun fact: Did you know PostgreSQL.org is built with Django?

Why mentor? Because nobody works on an open-source project forever—eventually people move on

Listen to Episode 24

Quote from Robert Haas:

“I think we're all hoping that there will be more people coming along after us who want to pick up the torch and continue to make PostgreSQL amazing. But I think also we'd like to not just sustain the community but to really see it grow. We'd like PostgreSQL to have more developers in the future than it does today and to have a greater pace of development than it does today. And I think that mentoring is a way that we can try to help that happen.”

Highlights of "Why mentor Postgres developers with Robert Haas"

Why did Robert kickstart the new PostgreSQL Hackers mentoring program?
How Robert channeled “what would Tom Lane do?” during patch reviews
How being willing to admit you don't know how to do something properly (yet) is an important part of getting better at it

How walking into a Postgres session at a Linux conference changed everything

Listen to Episode 23

Quote from Daniel Gustafsson:

“And I was sitting there, being completely blown away, realizing that this database has everything that I need and want. It has PL/Perl. I can write everything as a stored procedure. It was the programming environment that I was looking for, but I didn't know existed. And so from that day and time, I have not used any other database.”

Highlights of "How I got started as a developer & in Postgres with Daniel Gustafsson"

The story of one of Daniel’s earliest memories: a Datasaab M10 computer—or as Daniel described it: “a giant steel box in the family study”
Exact date, time, & location a chance LinuxForum encounter with Bruce Momjian changed the course of Daniel's career
Daniel's take on the magic of conferences in the Postgres community—including Nordic PGDay, PGconfdev, & POSETTE
Advice for Daniel’s younger self: “don’t be afraid to ask for help”

What’s it like to lead Postgres engineering at a cloud giant like Microsoft?

Listen to Episode 22

This episode with Affan Dar, who heads up engineering for Postgres at Microsoft, was a fun one. Many of the guests on Talking Postgres come from the open source community, but this time we switched it up, and spoke with the Azure engineering leader who’s steering all of the Postgres work at Microsoft (including the open source contributors team.)

Highlights of "Leading engineering for Postgres on Azure with Affan Dar"

What it's like to lead the engineering team behind Azure Database for PostgreSQL
The strategy behind Microsoft's investments into Postgres
Is Postgres extensibility a double-edged sword?
Affan’s experiences switching between individual contributor & management roles (& back)

Have you ever achieved something remarkable because someone planted an idea in your mind?

Listen to Episode 21

Andrew Atkinson is a software developer who got deeper into Postgres as he and his team tackled scale and reliability challenges. But what makes Andrew’s story stand out is what he did next: he wrote a book to share what he learned—specifically for Rails developers.

But the idea for the book didn’t come out of nowhere. It was planted by someone else. And that spark turned into a popular new book about PostgreSQL.

Highlights of "Helping Rails developers learn Postgres with Andrew Atkinson"

Tackling scalability challenges in Rails
The story behind Andrew’s book, High Performance PostgreSQL for Rails
The idea behind "writing is thinking"
The connection between Andrew's Postgres book and swimming to Antarctica

It was not Tom Lane’s plan to become a computer person

Listen to Episode 20

Tom Lane is a legend in the PostgreSQL contributor community and it was an honor to have him on the podcast. His origin story? Not what you’d expect. He originally wanted to be a pinball machine designer—and only later found his way into databases. Thank goodness he eventually went down the rabbit hole and discovered how interesting Postgres is. Because once he did, he never looked back.

Highlights of "How I got started as a developer & in Postgres with Tom Lane"

Getting nudged by a professor to apply to be a research assistant
Going down a bug-fixing rabbithole, starting with bugs in a port to HP-UX
The importance of adopting a mindset that embraces feedback
One of the things about working in open source: your failures are inherently extremely public

If you could work on anything, would you quit your job to pursue it?

Listen to Episode 19

Melanie Plageman did exactly that. She left her job to go deep on Postgres—writing an extension, watching every Andy Pavlo video ever, and eventually becoming a Postgres committer. So many of us learn from Melanie and this episode is full of her hard-won insights. Also this, one of my favorite quotes from the podcast:

“When you're getting feedback, it's not necessarily about whether or not you're good at engineering—or your patch is a good patch. It's about whether or not it's the right thing for Postgres. Not taking things personally—and thinking about it more from the perspective of ‘how can I make my work a better fit for Postgres’ makes it hurt a little bit less.”

–Melanie Plageman

Highlights of "Becoming a Postgres committer with Melanie Plageman"

How Melanie quit her job and proceeded to learn everything she could about Postgres
Writing a Postgres extension as a way to learn about Postgres (and land a job!)
The value of mentorship, karma, and paying it forward
What’s it like to get so deep in code you lose the ability to relate to people?
The enormous weight of the Postgres committer responsibility

How driving a forklift at a cheese factory led to a career in databases

Listen to Episode 18

David Rowley’s origin story is full of surprises. He started out driving a forklift in a cheese factory—and ended up becoming a go-to expert on Postgres performance.

This episode is a fan favorite (and it even inspired Daniel Gustafsson to come on the show a few months later.) One of the most useful takeaways? David’s advice on how to make your work stand out: do the research, read the archives, and show that you’ve done your homework.

Highlights of "How I got started as a developer & in Postgres with David Rowley"

David’s unusual origin story: from driving a forklift in a cheese factory to writing software
Reading the manual for Postgres 9.1 in a remote part of Australia (because there weren’t a great deal of other things to do in the evenings)
How speeding up Postgres gives a similar sort of buzz to tuning motorbike performance
Appreciating the very high standards in the Postgres contributor community

Have you ever eavesdropped on other people’s conversations?

Listen to Episode 17

Pino de Candia co-hosted the first year of this podcast with me—back when it was still called Path To Citus Con, before we renamed the show. In this episode, he came back for a meta-conversation about what we’ve learned from podcasting about Postgres, and what it’s like to record these conversations live.

We also took a walk down memory lane, revisiting some of our favorite bits from the first 16 episodes—and the guests who shared their Postgres stories with us.

Highlights of "Podcasting about Postgres with Pino de Candia"

Is listening to a podcast the next best thing to being in the hallway track at a conference?
Why it’s worth making the investment to understand Postgres not just at a technical level but also to get to know the community and the project’s history
What it’s like to record the podcasts live on Discord, with a parallel live text chat
Shout-outs to other useful Postgres podcasts, including Postgres FM and Scaling Postgres

Help more people discover Talking Postgres

You can find all the episodes—plus high quality transcripts—on TalkingPostgres.com, or wherever you get your podcasts. If you’ve enjoyed the podcast, there are a few easy ways to help more Postgres folks discover it:

Leave a review or rating (5 stars is always appreciated)
Tell a friend or teammate
Subscribe so you don’t miss future episodes

Word of mouth is still one of the best ways to spread the word.

We record the podcast LIVE on Discord (you’re invited)

If you didn’t know, we record Talking Postgres live on the Microsoft Open Source Discord, with a parallel live text chat. It usually happens at 10am PT on the first or second Wednesday of the month.

Want to listen in live? You can:

Follow the Talking Postgres live recording calendar
Or join the Microsoft Open Source Discord and mark yourself as “interested” in upcoming events. That way, you’ll get notified via Discord right before we go live.

Thank you to the people who make this podcast possible

I’m humbled by every guest who’s joined the show—starting with the very first episode about Working in public on open source with Simon Willison and Marco Slot. Every guest has brought something different: stories, insights, and their unique journeys with Postgres.

Huge thanks to Aaron Wislang of Microsoft, who’s been co-producing the podcast since day one. And to the cohort of Postgres friends who keep encouraging me to do this: Daniel Gustafsson, Melanie Plageman, Thomas Munro, and Boriss Mejías. Also a big shout-out to Pino de Candia, my co-host for the first year. And to my boss Charles Feddersen for supporting this podcast and all of my Postgres open source contributor work.

Figure 2: Screenshot of the TalkingPostgres.com "Subscribe" tab, showing all the many platforms where you can listen (and subscribe) to the Talking Postgres podcast—as well as the RSS feed URL.

This article was originally published on citusdata.com.

Ultimate Guide to POSETTE: An Event for Postgres, 2025 edition

Claire Giordano — 2025-06-04T15:26:00+00:00

POSETTE: An Event for Postgres 2025 is back for its 4^th year—free, virtual, and packed with deep expertise. No travel needed, just your laptop, internet, and curiosity.

This year’s 45 speakers are smart, capable Postgres practitioners—core contributors, performance experts, application developers, Azure engineers, extension maintainers—and their talks are as interesting as they are useful.

The four livestreams (42 talks total) run from June 10-12, 2025. Every talk will be posted to YouTube afterward (un-gated, of course). But if you can join live, I hope you do! On the virtual hallway track on Discord, you’ll be able to chat with POSETTE speakers—as well as other attendees. And yes, there will be swag.

This “ultimate guide” blog post is your shortcut to navigating POSETTE 2025. In this post you’ll get:

A “by the numbers” summary
2 Amazing Keynotes
18 Postgres core talks
12 Postgres ecosystem talks
10 Azure Database for PostgreSQL talks
Where to find the POSETTE Schedule
How to watch & how to participate on Discord
What’s new in POSETTE 2025?
A big thank you to our 45 amazing speakers
Join us for POSETTE 2025 & mark your calendars

“By the numbers” summary for POSETTE 2025

Here’s a quick snapshot of what you need to know about POSETTE:

About POSETTE: An Event for Postgres 2025
3 days	June 10-12, 2025
4 livestreams	In Americas & EMEA time zones (but of course you can watch from anywhere)
42 talks	All free, all virtual
2 keynotes	From Bruce Momjian & Charles Feddersen
45 speakers	PG contributors, users, application developers, community members, & Azure engineers
17.4% CFP acceptance rate	40 talks selected from 230 submissions
26% Azure-focused talks	11 talks out of 42 feature Azure Database for PostgreSQL
74% general Postgres talks	31 talks are not cloud-specific at all
16 languages	Published videos will have captions available in 16 languages, including English, Czech, Dutch, French, German, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, Turkish, Ukrainian, Chinese Simplified, and Chinese Traditional

And to give you a feel for the hi-level categories and detailed “tags”, to help you navigate all 42 of the talks, maybe this diagram will help.

Figure 1: Ultimate Guide for POSETTE 2025, with hi-level categories and detailed tags for all 42 talks.

2 Amazing Keynotes

If you’re interested in what Microsoft is building for Postgres these days, then Charles Feddersen’s keynote is a must-watch. And in spite of all the hype about AI, you’re guaranteed to enjoy Bruce Momjian’s keynote about databases in the AI trenches.

KEYNOTE: What Microsoft is Building for Postgres in 2025, by Charles Feddersen in Livestream 1 and Livestream 4 (Azure, Postgres 18, Async IO, AI, RAG, VS Code, community, livestream1, livestream4)
KEYNOTE: Databases in the AI Trenches, by Bruce Momjian in Livestream 2 and Livestream 3 (AI, semantic search, vector search, RAG, livestream2, livestream3)

18 Postgres Core talks

Performance

Best Practices for Tuning Slow Postgres Queries, by Lukas Fittl (EXPLAIN, optimizing queries, performance, startup, livestream1)
Fun With UUIDs, by Chris Ellis (UUIDs, indexes, performance, livestream3)
Hacking Postgres Executor For Performance, by Amit Langote (PG internals, executor, performance, livestream4)
Leveraging table partitioning for query performance and data archiving, by Derk van Veen (partitioning, performance, livestream4)
Performance Archaeology - 20 years of improvements, by Tomas Vondra (performance, benchmarks, livestream1)
What’s new in the Postgres 18 query planner / optimizer, by David Rowley (PG internals, planner, livestream2)

Postgres internals

Designing a monitoring feature in PostgreSQL, by Rahila Syed (monitoring, PG internals, livestream4)
PostgreSQL and Linux Kernel interactions, by Krishnakumar "KK" Ravi (Async IO, PG internals, Linux, troubleshooting, livestream3)

Replication

Logical replication theory and concepts, by Ashutosh Bapat (replication, wal, livestream2)
Myths and Truths about Synchronous Replication in PostgreSQL, by Alexander Kukushkin (HA, replication, livestream3)
Securing Postgres with streaming replication, by Jan Karremans (replication, disaster recovery, WAL, livestream4)

Community

Setting max_connection: Building PostgreSQL user groups that bring people together, by Ellyne Phneah (community, startup, user groups, livestream4)

Fun

Debugging Data Corruption in PostgreSQL: A Systematic Approach, by Palak Chaturvedi & Nitin Jadhav (debugging, Linux, livestream2)
Implementing Strict Serializability with pg_xact, by Jimmy Zelinskie (strict serializability, pg_xact, livestream3)
Incremental Backup in PostgreSQL, by Robert Haas (backup, incremental backup, livestream1)
Managing Postgres at scale: Challenges, Tools & Techniques, by Karen Jex (backups, HA, monitoring, partitioning, scalability, sharding, livestream3)
Neon: How we made PostgreSQL serverless, by Heikki Linnakangas (serverless, Neon, startup, livestream2)
Postgres Storytelling: Cunning Schema Design with Creative Data Modeling, by Boriss Mejías & Sarah Conway (data modeling, livestream1)

12 Postgres Ecosystem talks

Analytics

Building a PostgreSQL data warehouse, by Marco Slot (extensions, analytics, data warehouse, livestream4)
pg_duckdb: Ducking awesome analytics in Postgres, by Jelte Fennema-Nio (extensions, analytics, DuckDB, startup, livestream2)

App dev

Building modern Python web apps with PostgreSQL, by Pamela Fox (app dev, Python, livestream1)
Exploring .NET and PostgreSQL on Linux as your OSS app dev stack, by Silvano Coriani (app dev, .NET, Linux, livestream2)

Extensions

Can We Use Rust to Develop Extensions for PostgreSQL?, by Shinya Kato (extensions, pgrx, Rust, livestream2)
Designing for Document Databases in PostgreSQL, by Vinod Sridharan (extensions, DocumentDB, livestream1)
Elasticsearch-Quality Full-Text Search in Postgres via Tantivy, by Philippe Noël (Full text search, extensions, pg_search, startup, livestream1)
From MongoDB to Postgres: Building an Open Source Standard for Document Databases, by Peter Farkas (FerretDB, extensions, DocumentDB, MongoDB, startup, livestream4)
Hitchhiker's Guide to Row-Level Security in Citus, by Adam Wølk (security, Citus, livestream4)
Resource Control Admission - I have a date with my PSI, by Cédric Villemain (extensions, pg_psi, monitoring, Linux, PG Internals, livestream4)

Patroni

What is Patroni, really?, by Polina Bungina (HA, Patroni, livestream2)

VS Code

Introducing Microsoft’s VS Code Extension for PostgreSQL, by Matt McFarland (VS Code, IDE, livestream1)

10 Azure Database for PostgreSQL talks

AI-related talks

Building Enterprise RAG with Azure Database for PostgreSQL and pgvector, by Michael John Pena (AI, Azure, RAG, livestream4)
Building Intelligent Applications with Graph-Based RAG on PostgreSQL, by Abe Omorogbe (AI, AzureDBPostgres, RAG, livestream3)

Customer talks

Fortifying Azure Database for PostgreSQL: Stop Intrusions in Their Tracks, by Johannes Schuetzner (Azure, authentication, customer, Mercedes, networking, security, livestream2)
Scaling Postgres to the next level at OpenAI, by Bohan Zhang (AI, Azure, customer, OpenAI, livestream1)

Flexible Server talks

Azure Database for PostgreSQL: 15 Essential Standards for Compliance and Security, by Taiob Ali (Azure, authentication, backup, compliance, security, livestream3)
Boosting Azure PostgreSQL Performance with Azure Advisor, by Gayathri Paderla (Azure, Azure Advisor, performance, livestream1)
Dear Azure Database for PostgreSQL, can you automate my index?, by Nacho Alonso Portillo (Azure, indexes, livestream2)
Overcoming Performance Hurdles in Postgres Partitioned Tables, by Sarat Balijepalli (Azure, partitioning, performance, livestream3)
What’s New with Azure Postgres Flexible Server in 2025 🆕, by Varun Dhawan (Azure, what's new, flexible server, livestream3)

Oracle to Postgres talks

Migrating from Oracle to Azure Database for PostgreSQL, Seamlessly, by Neeta Goel & Sandeep Rajeev (Azure, Oracle to Postgres, migration, livestream3)

Where to find the POSETTE Schedule

You may be thinking, “I know how to use a website, Claire.” Fair. But hear me out: the POSETTE 2025 Schedule page has 4 tabs—one for each livestream—and it always opens to Livestream 1 by default.

So if you’re looking for talks in Livestreams 2, 3, or 4:

Head to the POSETTE Schedule page
Click the tab for the livestream you want
Voila—talks for that stream

Figure 2: Screenshot of the POSETTE 2025 Schedule with separate tabs for the 4 livestreams

How to watch & how to participate on Discord

Here’s how to tune in—and how to participate in the conference.

How to watch the livestreams

All 4 livestreams will be watchable on the PosetteConf 2025 home page
Pro tip: If you’ve left the page open since the last stream, refresh your browser to see the next livestream.

How to join the virtual hallway track

Head to the #posetteconf channel on Discord (on the Microsoft Open Source Discord)
That’s where speakers and attendees hang out during the livestreams—it’s where you can ask questions, share reactions, and just say hi.

What’s new in POSETTE 2025

If you attended POSETTE last year (or back when it was called Citus Con), you might be wondering, what’s different this year?

In many ways, the POSETTE playbook is the same: useful and delightful Postgres talks in a virtual, accessible format. But here’s what’s new:

New website: And, a new domain too: PosetteConf.com
Only 2 keynotes: instead of 4 keynotes last year. We’re honored that Bruce Momjian & Charles Feddersen accepted the invitation to be keynote speakers. Each keynote will be repeated twice.
58% speakers new to POSETTE: 26 out of 45 speakers (58%) are brand new to POSETTE
New livestream hosts: 3 of the 7 livestream hosts are brand new to hosting POSETTE livestreams: welcome to Adam Wølk, Derk van Veen, & Thomas Munro
Same name: The POSETTE: An Event for Postgres name is here to stay—and we still love the name

Big thank you to our 45 amazing speakers

Every great event starts with great talks—and great talks start with great speakers. Want to learn more about the people behind these talks?

Visit the POSETTE 2025 Speaker page
Click a speaker’s bio to see their interview (if available)
If a speaker has been a guest on the Talking Postgres podcast in the past, then you’ll find a link to their episode there, too

Figure 3: Bio pics for all 45 speakers in POSETTE: An Event for Postgres 25, along with our gratitude.

Join us for POSETTE 2025! Mark your calendars

I hope you join us for POSETTE 2025. Consider yourself officially invited. As part of the talk selection team, I’m definitely biased—but I truly believe these speakers and talk are worth your time.

I’ll be hosting Livestream 1 and Livestream 2 and you’ll find me in the #posetteconf Discord chat. I hope to see you there.

And please—tell your Postgres friends, so they don’t miss out!

🗓️ Add the livestreams to your calendar

Livestream 1: Tue June 10^th 8am-2pm PDT (UTC-7)
Livestream 2: Wed June 11^th 8am-2pm CEST (UTC+2)
Livestream 3: Wed June 11^th 8am-2pm PDT (UTC-7)
Livestream 4: Thu June 12^th 8am-2pm CEST (UTC+2)

Watch last year’s talks in advance: And if you want to get ready, check out the POSETTE 2024 playlist on YouTube. Lots of gems in there.

Acknowledgements & Gratitude

I’ve already thanked the amazing speakers above. In addition, thanks go to Daniel Gustafsson, Teresa Giacomini, and My Nguyen for reviewing parts of this post before publication. And of course, big thank you to the POSETTE 2025 organizing team and POSETTE talk selection team—without you, there would be no POSETTE!

Figure 4: Visual invitation to join the virtual hallway track for POSETTE 2025 on the Microsoft Open Source Discord. So you can chat with the speakers & others in the Postgres community.

This article was originally published on citusdata.com.

Distribute PostgreSQL 17 with Citus 13

Naisila Puka — 2025-02-06T18:45:00+00:00

The Citus 13.0 release is out and includes PostgreSQL 17.2 support! We know you’ve been waiting, and we’ve been hard at work adding features we believe will take your experience to the next level, focusing on bringing the Postgres 17 exciting improvements to you at distributed scale.

The Citus database is an open-source extension of Postgres that brings the power of Postgres to any scale, from a single node to a distributed database cluster. Since Citus is an extension, using Citus means you're also using Postgres, giving you direct access to the Postgres features. And the latest of such features came with Postgres 17 release! In addition, Citus 13 will be made available on the elastic clusters (preview) feature on Azure Database for PostgreSQL - Flexible Server, along with PostgreSQL 17 support, in the near future.

PostgreSQL 17 highlights include performance improvements in query execution for indexes, a revamped memory management system for vacuum, new monitoring and analysis features, expanded functionality for managing data in partitions, optimizer improvements, and enhancements for high-concurrency workloads. PostgreSQL 17 also expands on SQL syntax that benefits both new workloads and mission-critical systems, such as the addition of the SQL/JSON JSON_TABLE() command for developers, and the expansion of the MERGE command. For those of you who are interested in upgrading to Postgres 17 and scaling these new features of Postgres: you can upgrade to Citus 13.0!

Along with Postgres 17 support, Citus 13.0 also fixes important bugs, and we are happy to say that we had many community contributions here as well. These bugfixes focus on data integrity and correctness, crash and fault tolerance, and cluster management, all of which are critical for ensuring reliable operations and user confidence in a distributed PostgreSQL environment.

Let's take a closer look at what's new in Citus 13.0:

Postgres 17 support in Citus 13.0
Leveraging optimizer improvements with Citus in Postgres 17
Important bugfixes, including community contributions into Citus 13.0

Postgres 17 support in Citus 13.0

Citus 13.0 introduces support for PostgreSQL 17. This means that just by enabling PG17.2 in Citus 13.0, all the query performance improvements directly reflect on the Citus distributed queries, and several optimizer improvements benefit queries in Citus out of the box! Among the many new features in PG 17, the following capabilities enabled in Citus 13.0 are especially noteworthy for Citus users:

JSON_TABLE() support in distributed queries
Propagate "MERGE ... WHEN NOT MATCHED BY SOURCE" syntax
Expanded functionality on distributed partitioned tables
Propagate new EXPLAIN options: MEMORY and SERIALIZE

To learn more about how you can use Citus 13.0 + PostgreSQL 17.2, as well as currently unsupported features and future work, you can consult the Citus 13.0 Updates page, which gives you detailed release notes.

JSON_TABLE() support in distributed queries

One of the most discussed features in Postgres 17 is the enhanced management of JSON data. The key addition here is the JSON_TABLE() function. JSON_TABLE() converts JSON data into a standard PostgreSQL table. This means that developers can leverage the full capabilities of SQL on data that was originally in JSON format, by getting data from complicated JSONs into a simpler relational view. The commit that adds basic JSON_TABLE() functionality explains that through JSON_TABLE() function, JSON data can be used like other tabular data, with capabilities such as sorting, filtering, joining with regular Postgres tables and usage in a FROM clause. Joining is specifically interesting for Citus: how can we perform a join between the JSON_TABLE() function and a Citus distributed table?

As you may know, Citus uses the sharding technique to distribute the tables, where each table is divided into smaller chunks called shards. Citus 13.0 supports JSON_TABLE() in a distributed query by treating it as a recurring tuple, i.e. an expression that gives the same set of results across multiple shards. This is useful for executing a JOIN between a distributed table and a table coming from the JSON_TABLE() function. The main point is that recurring tuples "recur" for each shard in a multi-shard query. For more technical details on this, check out Citus Technical Documentation on recurring tuples.

Let’s look at example distributed queries of how you can combine the JSON_TABLE() function with Citus distributed tables:

-- create, distribute and populate the table with a jsonb column
-- we will use that column as a regular postgres table through JSON_TABLE()
CREATE TABLE my_favorite_books(book_collection_id bigserial, jsonb_column jsonb);
SELECT create_distributed_table(' my_favorite_books ', 'book_collection_id');

-- these books will be inserted with the automatic book_collection_id of 1
INSERT INTO my_favorite_books (jsonb_column) VALUES (
'{ "favorites" : [
   { "kind" : "mystery", "books" : [
     { "title" : "The Count of Monte Cristo", "author" : "Alexandre Dumas"},
     { "title" : "Crime and Punishment", "author" : "Fyodor Dostoevsky" } ] },
   { "kind" : "drama", "books" : [
     { "title" : "Anna Karenina", "author" : "Leo Tolstoy" } ] },
   { "kind" : "poetry", "books" : [
     { "title" : "Masnavi", "author" : "Jalal al-Din Muhammad Rumi" } ] },
   { "kind" : "autobiography", "books" : [
     { "title" : "The Autobiography of Malcolm X", "author" : "Alex Haley" } ] }
  ] }');

-- these books will be inserted with the automatic book_collection_id of 2
INSERT INTO my_favorite_books (jsonb_column) VALUES (
'{ "favorites" : [
   { "kind" : "mystery", "books" : [
     { "title" : "To Kill a Mockingbird", "author" : "Harper Lee"},
     { "title" : "Our Mutual Friend", "author" : "Charles Dickens" } ] },
   { "kind" : "drama", "books" : [
     { "title" : "Pride and Prejudice", "author" : "Jane Austen" } ] },
   { "kind" : "poetry", "books" : [
     { "title" : "The Odyssey", "author" : "Homer" } ] },
   { "kind" : "autobiography", "books" : [
     { "title" : "The Diary of a Young Girl", "author" : "Anne Frank" } ] }
  ] }');

-- a simple router query, that outputs all the books under book_collection_id = 1
SELECT json_table_output.* FROM
my_favorite_books,
JSON_TABLE ( jsonb_column, '$.favorites[*]' COLUMNS (
   key FOR ORDINALITY, kind text PATH '$.kind',
   NESTED PATH '$.books[*]' COLUMNS (
     title text PATH '$.title', author text PATH '$.author'))) AS json_table_output
WHERE my_favorite_books. book_collection_id = 1
ORDER BY 1, 2, 3, 4;

 key |     kind      |             title              |           author
-----+---------------+--------------------------------+----------------------------
   1 | mystery       | The Count of Monte Cristo      | Alexandre Dumas
   1 | mystery       | Crime and Punishment           | Fyodor Dostoevsky
   2 | drama         | Anna Karenina                  | Leo Tolstoy
   3 | poetry        | Masnavi                        | Jalal al-Din Muhammad Rumi
   4 | autobiography | The Autobiography of Malcolm X | Alex Haley
(5 rows)

-- a simple multi-shard query, where we want to see all the books
SELECT json_table_output.* FROM
my_favorite_books,
JSON_TABLE ( jsonb_column, '$.favorites[*]' COLUMNS (
   key FOR ORDINALITY, kind text PATH '$.kind',
   NESTED PATH '$.books[*]' COLUMNS (
     title text PATH '$.title', author text PATH '$.author'))) AS json_table_output
ORDER BY 1, 2, 3, 4;

 key |     kind      |             title              |           author
-----+---------------+--------------------------------+----------------------------
   1 | mystery       | The Count of Monte Cristo      | Alexandre Dumas
   1 | mystery       | Crime and Punishment           | Fyodor Dostoevsky
   1 | mystery       | Our Mutual Friend              | Charles Dickens
   1 | mystery       | To Kill a Mockingbird          | Harper Lee
   2 | drama         | Anna Karenina                  | Leo Tolstoy
   2 | drama         | Pride and Prejudice            | Jane Austen
   3 | poetry        | Masnavi                        | Jalal al-Din Muhammad Rumi
   3 | poetry        | The Odyssey                    | Homer
   4 | autobiography | The Autobiography of Malcolm X | Alex Haley
   4 | autobiography | The Diary of a Young Girl      | Anne Frank
(10 rows)

-- more complex router query involving LATERAL and LIMIT
-- select two books under book_collection_id = 2
SELECT sub.*
FROM my_favorite_books,
lateral(SELECT * FROM JSON_TABLE (jsonb_column, '$.favorites[*]'
    COLUMNS (key FOR ORDINALITY, kind text PATH '$.kind',
        NESTED PATH '$.books[*]' COLUMNS
            (title text PATH '$.title', author text PATH '$.author')))
    AS json_table_output ORDER BY key DESC LIMIT 2) as sub
WHERE my_favorite_books.book_collection_id = 2;

 key |     kind      |           title           |   author
-----+---------------+---------------------------+------------
   4 | autobiography | The Diary of a Young Girl | Anne Frank
   3 | poetry        | The Odyssey               | Homer
(2 rows)

Furthermore, JSON_TABLE() can be on the inner part of an outer join, as well as in the outer part of a join as long as there is one distributed table (or even more). The limitations of using JSON_TABLE() in distributed queries are the same as the general limitations of the usage of recurring tuples in distributed queries. For more technical examples on usages of JSON_TABLE() in distributed queries, as well as the limitations, you can check out the Updates page.

Propagate "MERGE ... WHEN NOT MATCHED BY SOURCE" syntax

As you may know, the MERGE statement in SQL is used to perform INSERT, UPDATE, and DELETE operations on a target table based on the results of a join with a source table. This allows for efficient data synchronization between the target and source tables because it combines multiple operations into one.

PG15 added support for MERGE, with the syntax originally allowing only defining actions for rows that exist in the data source, but not in the target relation., i.e. WHEN NOT MATCHED BY TARGET.

As of PG17, one may use the MERGE command to operate on rows that exist in the target relation, but not in the data source, by using WHEN NOT MATCHED BY SOURCE. This is a fantastic addition and will greatly simplify various data loading and updating processes, because if a row in the target table being merged doesn’t exist in the source table, we can now perform any necessary actions on that row. Citus extended its already existing strategies employed for handling MERGE in a distributed environment to include this syntax as well. For more details, you can look at how Citus 12 supports MERGE.

Let’s see a simple example, similar to the tests in Postgres, on how to make use of MERGE ... WHEN NOT MATCHED BY SOURCE with Citus managed tables:

-- create and distribute the target and source tables
CREATE TABLE target_table (tid integer, balance float, val text);
CREATE TABLE source_table (sid integer, delta float);
SELECT create_distributed_table('target_table', 'tid');
SELECT create_distributed_table('source_table', 'sid');

-- populate the tables
INSERT INTO target_table SELECT id, id * 100, 'initial' FROM generate_series(1,5,2) AS id;
INSERT INTO source_table SELECT id, id * 10 FROM generate_series(1,4) AS id;

-- Use WHEN NOT MATCHED BY SOURCE
MERGE INTO target_table t
    USING source_table s
    ON t.tid = s.sid AND tid = 1
    WHEN MATCHED THEN
        UPDATE SET balance = balance + delta, val = val || ' updated by merge'
    WHEN NOT MATCHED BY TARGET THEN
        INSERT VALUES (sid, delta, 'inserted by merge')
    WHEN NOT MATCHED BY SOURCE THEN
        UPDATE SET val = val || ' not matched by source';

-- see the updated distributed target table
SELECT * FROM target_table ORDER BY tid;

 tid | balance |              val
-----+---------+-------------------------------
   1 |     110 | initial updated by merge
   2 |      20 | inserted by merge
   3 |      30 | inserted by merge
   3 |     300 | initial not matched by source
   4 |      40 | inserted by merge
   5 |     500 | initial not matched by source
(6 rows)

Expanded functionality on distributed partitioned tables

PG17 has expanded functionality for managing data in partitions. Now you can specify an access method for partitioned tables. Also, you can add exclusion constraints on partitions. Another great addition is supporting identity columns in partitioned tables. Citus has extended the distributed tables capabilities to include these 3 amazing functionalities for distributed partitioned tables as well! Let’s dive in a bit more detail below:

Citus 13.0 allows specifying an access method for distributed partitioned tables: After specifying a table access method via CREATE TABLE ... USING for a partitioned table, you can then distribute it through the Citus signature function: create_distributed_table(). From that point forward, this table will be managed by Citus with the specified access method. Also, Citus propagates ALTER TABLE ... SET ACCESS METHOD to all the nodes in the cluster, allowing to not only specify the access method for the distributed partitioned table, but also modify it.
Adds support for identity columns in distributed partitioned tables: Citus on Postgres 17 allows specifying generated identity columns for Citus managed tables by maintaining generated identity logic while propagating distributed partitioned table DDL to all the cluster nodes. For more details, check out how Citus 11.2 introduced identity column support for Citus managed tables.
Allows exclusion constraints on distributed partitioned tables: Similarly, Citus now allows adding an exclusion constraint because it seamlessly propagates the ALTER TABLE distributed_partitioned_table ADD CONSTRAINT ... SQL command to all the nodes in the cluster.

Let’s demonstrate all of the above with examples below:

-- let's say we are at node 0
-- create a partitioned table
-- specify access method as columnar, use generated identity column
CREATE TABLE dist_partitioned_table
( id_test bigint GENERATED BY DEFAULT AS IDENTITY (START WITH 10 INCREMENT BY 10),
n int )
PARTITION BY RANGE (n)
USING columnar;

-- create a partition for the table
CREATE TABLE pt_1 PARTITION OF dist_partitioned_table FOR VALUES FROM (1) TO (50);

-- distribute the table, making it a distributed partitioned table
SELECT create_distributed_table('dist_partitioned_table', 'id_test');

-- create another partition of the table, it will be automatically distributed
CREATE TABLE pt_2 PARTITION OF dist_partitioned_table FOR VALUES FROM (50) TO (1000);

-- Altering an access method for a partitioned table lets the value be used
-- for all future partitions created under it.
-- Existing partitions are not modified.
ALTER TABLE dist_partitioned_table SET ACCESS METHOD heap;

-- Add an exclusion constraint, which will be part of current and future partitions as well
ALTER TABLE dist_partitioned_table ADD EXCLUDE USING btree (id_test WITH =, n WITH =);

-- Attaching a partition inherits the identity column from the parent table
CREATE TABLE pt_3 (id_test bigint not null, n int);
ALTER TABLE dist_partitioned_table ATTACH PARTITION pt_3 FOR VALUES FROM (1000) TO (2000);

-- verify that the identity column is inherited in all children
SELECT attrelid::regclass, attname, attidentity FROM pg_attribute
WHERE attname = 'id_test' AND attidentity = 'd' ORDER BY 1;

        attrelid        | attname | attidentity
------------------------+---------+-------------
 dist_partitioned_table | id_test | d
 pt_1                   | id_test | d
 pt_2                   | id_test | d
 pt_3                   | id_test | d
(4 rows)

-- the parent table and the new partition have the altered access method "heap"
-- whereas the old two partitions have the original access method "columnar"
SELECT relname, amname FROM pg_class c LEFT JOIN pg_am am ON (c.relam = am.oid)
WHERE relname IN ('dist_partitioned_table', 'pt_1', 'pt_2', 'pt_3') ORDER BY relname;

        relname         |  amname
------------------------+----------
 dist_partitioned_table | heap
 pt_1                   | columnar
 pt_2                   | columnar
 pt_3                   | heap
(4 rows)

-- verify that the distributed partitioned table and its distributed partitions
-- have exclude constraints
SELECT conname FROM pg_constraint
WHERE conname LIKE '%id_test%' ORDER BY 1;

           conname
------------------------
dist_partitioned_table_id_test_n_excl
 pt_1_id_test_n_excl
 pt_2_id_test_n_excl
 pt_3_id_test_n_excl
(4 rows)

-- now, verify correct propagation to all the nodes in the cluster
\c - - - :node_1_port
SELECT attrelid::regclass, attname, attidentity FROM pg_attribute
WHERE attname = 'id_test' AND attidentity = 'd' ORDER BY 1;

        attrelid        | attname | attidentity
------------------------+---------+-------------
 dist_partitioned_table | id_test | d
 pt_1                   | id_test | d
 pt_2                   | id_test | d
 pt_3                   | id_test | d
(4 rows)

SELECT relname, amname FROM pg_class c LEFT JOIN pg_am am ON (c.relam = am.oid)
WHERE relname IN ('dist_partitioned_table', 'pt_1', 'pt_2', 'pt_3') ORDER BY relname;

        relname         |  amname
------------------------+----------
 dist_partitioned_table | heap
 pt_1                   | columnar
 pt_2                   | columnar
 pt_3                   | heap
(4 rows)

-- this node is not a coordinator
-- so we can also see the exclusion constraints on the shards
SELECT conname FROM pg_constraint
WHERE conname LIKE '%id_test%' ORDER BY 1;

           conname
------------------------
dist_partitioned_table_id_test_n_excl
dist_partitioned_table_id_test_n_excl_102008
....
 pt_1_id_test_n_excl
 pt_1_id_test_n_excl_102040
...
 pt_2_id_test_n_excl
 pt_2_id_test_n_excl_102072
...
 pt_3_id_test_n_excl
 pt_3_id_test_n_excl_102104
...

Propagate new EXPLAIN options: MEMORY and SERIALIZE

EXPLAIN in PG17 now includes two new options: SERIALIZE and MEMORY. SERIALIZE option investigates the real cost of converting the query's output data into displayable form and the cost of sending the data to the client, whereas the MEMORY option reports planner memory consumption. Citus 13.0 allows these options when trying to explain a distributed query.

As you may know, Citus distributes the query to the appropriate nodes that contain the shards that the query is referring to. Let’s refer to these as tasks sent to shards. For each of those shard tasks, it will return the explain output to the node that runs the EXPLAIN query. As a start in Citus, the MEMORY option will be especially useful for parallelized queries across shards to see the amount of memory used in a single task. The SERIALIZE option is useful in the collecting node, because after retrieving the whole data of the query, the serialize time can be properly calculated. Let’s see a simple example below:

-- create, distribute and populate a simple table
SET citus.shard_count TO 32;
CREATE TABLE dist_table(a int, b int);
SELECT create_distributed_table('dist_table', 'a');
INSERT INTO dist_table SELECT c, c * 10000 FROM generate_series(0, 1000) AS c;
-- explain a simple multi-shard query on the table using memory and serialize options
EXPLAIN (costs off, analyze, serialize, memory) SELECT * FROM dist_table;

                                      QUERY PLAN
--------------------------------------------------------------------------------------------
Custom Scan (Citus Adaptive) (actual time=18.490..18.519 rows=1001 loops=1)
Task Count: 32
Tuple data received from nodes: 8008 bytes
Tasks Shown: One of 32
-> Task
    Tuple data received from node: 272 bytes
     Node: host=localhost port=9702 dbname=Naisila
     ->  Seq Scan on dist_table_102141 dist_table (actual time=0.013..0.016 rows=34 loops=1)
         Planning:
           Memory: used=7kB  allocated=8kB
         Planning Time: 0.024 ms
         Serialization: time=0.000 ms  output=0kB  format=text
         Execution Time: 0.031 ms
Planning:
Memory: used=359kB allocated=512kB
Planning Time: 0.287 ms
Serialization: time=0.097 ms output=20kB format=text
Execution Time: 18.902 ms
(18 rows)

This EXPLAIN query is showing one of 32 tasks, where tasks correspond with shards. We can see the amount of memory consumed in a single task in the node where it was executed. In the example above, there is more memory consumed in the coordinator node because the Custom Scan node is coalescing results from all the tasks. Serialization value is shown for the collected results only, for now.

Leveraging optimizer improvements with Citus in Postgres 17

As soon as we enable PG17 in Citus, we can make use of query and optimizer improvements without any further action needed. That’s because such improvements are reflected directly in Citus table shards, which are essentially regular Postgres tables. Thanks to PG17 enabling correlated subqueries to be pulled to a join, Citus can make use of this feature in its distributed planning phase and run even more types of distributed queries, which were not supported with previous PG versions.

PG17 has several commits that bring significant optimizer improvements. This commit in particular: Allow correlated IN subqueries to be transformed into joins, is worth calling out because it enables Citus 13.0 to plan and execute a query with a correlated IN subquery using query pushdown, where it was challenging for pre-PG17 Citus to plan the query. Let’s see what type of new queries in Citus 13.0 with PG17 we can run:

-- create, distribute and populate two simple tables
CREATE TABLE customer ( id int, name text, contact text, category text);
CREATE TABLE orders ( customer_id int, category text);
SELECT create_distributed_table('customer', 'id');
SELECT create_distributed_table('orders', 'customer_id');
INSERT INTO customer VALUES (1, 'Beana', 'beana1234@gmail.com', 'books'),
                            (2, 'Erida', 'erida1234@gmail.com', 'notebooks'),
                            (3, 'Redi', 'redi1234@gmail.com', 'pens');
INSERT INTO orders VALUES (1, 'books'), (2, 'notebooks'), (3, 'hats');

-- with Citus 13.0 in PG17 we are able to run a query
-- on the customer table that has a correlated subquery!
SELECT c.name, c.contact
FROM customer c
WHERE c.id in (SELECT customer_id FROM orders o WHERE o.category = c.category);

name  |       contact
------+---------------------
Beana | beana1234@gmail.com
Erida | erida1234@gmail.com
(2 rows)

-- pre Citus 13 or pre PG17 this query would fail with the following
ERROR:  complex joins are only supported when all distributed tables
        are co-located and joined on their distribution columns

Let’s get into more details on how Citus 13.0 leverages PG17 optimizer improvements and is able to plan the query and execute it:

EXPLAIN (costs off)
SELECT c.name, c.contact
FROM customer c
WHERE c.id in (SELECT customer_id FROM orders o WHERE o.category = c.category);

With Citus 13.0 the plan for this query is:

                              QUERY PLAN
--------------------------------------------------------------------------
Custom Scan (Citus Adaptive)
   Task Count: 32
   Tasks Shown: One of 32
   -> Task
    Node: host=localhost port=9701 dbname=citus
    -> Hash Join
        Hash Cond: ((c.category = o.category) AND (c.id = o.customer_id))
        -> Seq Scan on customer_105861 c
        -> Hash
            -> HashAggregate
        Group Key: o.category, o.customer_id
            -> Seq Scan on orders_105893 o

The Postgres 17 planner converts the IN subquery to a join between the customer and `orders table (technically it is a semi-join). Then, Citus can push down the query to all worker nodes because the join includes an equality on the distribution columns of the tables. In contrast, the same query hits a planning limitation with previous versions of Citus:

-- Pre-13.0 Citus:
EXPLAIN (costs off)
SELECT c.name, c.contact
FROM customer c
WHERE c.id in (SELECT customer_id FROM orders  o WHERE o.category = c.category);
DEBUG:  skipping recursive planning for the subquery since it contains
        references to outer queries
ERROR:  complex joins are only supported when all distributed tables
        are co-located and joined on their distribution columns

Prior to version 17, Postgres planned the subquery as a correlated Subplan and applied that as a filter on the customer table. With Citus, if it is not possible to push down a correlated subquery. But with Postgres 17 the subquery is planned as a join, the query plan has no correlated Subplans, and Citus can naturally pushdown this join!

Important bugfixes, including community contributions into Citus 13.0

Citus 13.0 has bug fixes that address some crashes caused by unsafe catalog access, and segmentation faults in distributed procedures. Citus 13.0 also resolves issues related to role synchronization across nodes, server crashes in specific cluster configurations, and improves handling of shard placement when new nodes are introduced without required reference data.

Other than work from Citus engineers, we have seen significant community contributions to Citus, which we always love to see. We are really grateful for all the contributions to the Citus open-source repository in GitHub, both pull requests and issues. We would like to thank:

Cédric Villemain for his contributions in fault tolerance by fixing a segfault when calling distributed procedure with a parameterized distribution argument.
Karina for her contributions in crash tolerance by fixing a server crash when trying to execute activate_node_snapshot() on a single-node cluster.
Filip Sedlák for his contributions in cluster management & coordination by improving citus_move_shard_placement() to fail early if there is a new node without reference tables yet.

For more details on these community contributions, and more notable fixes, you can check the Citus 13.0 Updates page.

Diving deeper into Citus 13.0 and distributed Postgres

To learn more about Citus 13.0, you can:

Check out the 13.0 Updates page to get the detailed release notes.
Watch the replay of the Citus 13.0 Release Party livestream to see demos and learn more about how Citus 13.0 distributes PostgreSQL 17, as well as exciting Citus team updates.

You can also stay connected on the Citus Slack and visit the Citus open source GitHub repo to see recent developments as well. If there’s something you’d like to see next in Citus, feel free to also open a feature request issue :)

This article was originally published on citusdata.com.

CFP talk proposal ideas for POSETTE: An Event for Postgres 2025

Claire Giordano — 2025-02-04T21:02:01+00:00

Some of you have been asking for advice about what to submit to the CFP for POSETTE: An Event for Postgres 2025. So this post aims to give you ideas that might help you submit a talk proposal (or 2, or 3) before the upcoming CFP deadline.

If you’re not yet familiar with this conference, POSETTE: An Event for Postgres 2025 is a free & virtual developer event now in its 4th year, organized by the Postgres team at Microsoft.

I love the virtual aspect of POSETTE because the conference talks are so accessible—for both speakers and attendees. If you’re a speaker, you don’t need travel budget $$—and you don’t have to leave home. Also, the talk you’ve poured all that energy into is not limited to the people in the room, and has the potential to reach so many more people. If you’re an attendee, well, all you need is an internet connection.

The CFP for POSETTE: An Event for Postgres will be open until Sunday Feb 9th at 11:59pm PST. So as of the publication date of this blog post, you still have time to submit a CFP proposal (or 2, or 3, or 4)—and to remind your Postgres teammates and friends of the speaking opportunity.

If you have a Postgres experience, success story, failure, best practice, “how-to”, collection of tips, lesson about something that's new, or deep dive to share—not just about the core of Postgres, but about anything in the Postgres ecosystem, including extensions, and tooling, and monitoring—maybe you should consider submitting a talk proposal to the CFP for POSETTE.

If you’re not sure about whether to give a conference talk, there are a boatload of reasons why you should. And there’s also a podcast episode with Álvaro Herrera, Boriss Mejías, and Pino de Candia that makes the case for why giving conference talks matters. For inspiration, you can also take a look at the playlist of POSETTE 2024 talks.

And if you’re looking for even more CFP ideas, you’ve come to the right place! Read on…

Ideas for talks you might propose in the POSETTE CFP

On the CFP page there is a list of possible talk titles (screenshot below) you might submit—these are good ideas, although the list is by no means exhaustive, and we welcome talk proposals that are not on this list.

Figure 1: POSETTE CFP talk topics taken from the CFP page on PosetteConf.com

On Telegram the other day, when answering the question “Do you have any ideas of what I should submit?”, I found myself suggesting different TYPES of talks. Not specific ideas and talk titles, but rather I framed the different categories. So I decided to share these different “types” and “classes” of talks with all of you, in the hopes this might give you a good talk proposal idea.

First you need to pick your audience: Before you think about what type of talk to give, remember that the POSETTE team is focused on serving the needs of both the USER community—as well as the Postgres contributor & hacker communities.

That means first you need to decide on your audience. Are you giving a talk for PostgreSQL users, or Azure Database for PostgreSQL customers, or the PostgreSQL contributor community? All are good choices.

Then you need to decide: what do you want to accomplish with your talk?

Do you want to skill up the Postgres hacker community?: If you want to help skill-up the developer/contributor community, maybe pick a part of Postgres that new contributors often ask a lot of questions about, get stuck on, need help with, etc—and give a “tour” of its mechanics, starting with the basics.
Do you want to help grow the Postgres community?: If you want to help grow the Postgres community of contributors and developers, you could propose a talk that would motivate tomorrow's developers/contributors to get involved in the project. Imagine you were going to a university to give a talk about "why work on Postgres"… what would you say? And how would you entice people to work on Postgres?

What pain points would you challenge them with?

What benefits would you share from your own Postgres experience that might inspire these developers to think seriously about Postgres as a career path?

You could also shine a light on the different ways people can (and do!) contribute to the Postgres community: from mentoring to translations to organizing conferences to podcasts to speaking at conferences to publishing PostgreSQL Person of the Week.
Do you want to share your expertise with Postgres users?: If you want your talk to benefit users, maybe pick an area that you are already expert in (or want an excuse to dig into and learn about?) and create a Beginners Guide for it? Or Advanced Tips for it? Or Surprising Benefits of? Or Things People Might Not Know?

Especially if there is a part of Postgres you feel like people sometimes mis-use, or don't take enough advantage of....
Do you want to share your customer experiences with Azure Database for PostgreSQL, or Postgres more generally?: Maybe you have a wild success story you think others will benefit from. Or you want to share a problem you had and how you used Postgres to solve it? People love customer stories.
Do you want to shine a light on the broader Postgres ecosystem?: If you want to target users with your talk, don’t limit yourself the Postgres core. There is a rich ecosystem that surrounds Postgres and people need to understand the ecosystem, too. So maybe there are tools or Postgres extensions or forks or startups that you can give a useful talk about?
Do you want to help experts in other database technologies learn about Postgres?: If you have expertise in other databases as well as Postgres, maybe you can help people who who are skilled in running workloads on other databases and are looking to skill up on Postgres—by helping them understand what’s similar, and what’s different. As if you’re giving them a dictionary to translate from their familiar database to Postgres, and vice versa.
There are so many more possibilities: Often I look at the schedule from previous years to look for inspiration (and to make sure that my talk proposal is not a duplicate of a talk that’s already been given.) And I think about pain points, things people get confused about, or questions that come up a lot. Another thing to keep in mind: how can you help your story to "stick"? Can you make it entertaining? How do you share your story in a way that keeps people watching (versus looking at their phone instead?)

Key things to know about POSETTE: An Event for Postgres 2025

CFP deadline: The CFP for POSETTE will close on Sunday, Feb 9th 2025 @ 11:59pm Pacific Time (PST)
No travel required: free & virtual developer event
Length of talks: 25 minutes/session
Language: All talks will be in English
Talks will be pre-recorded: All talks will be pre-recorded by the POSETTE team during the weeks of Apr 28th and May 5th (with accepted speakers presenting remotely)
When is the event?: Jun 10-12, 2025
Format of the virtual event: All pre-recorded talks will be livestreamed in one of 4 unique livestreams on Jun 10-12, 2025—all with parallel live text chats on Discord. Two of the livestreams will be in Americas-friendly times of day (8:00am-2:00pm PDT) and two of the livestreams will be in EMEA-friendly times of day (8:00am-2:00pm CEST). All talks will be published online after the event is over.
More info about the CFP: All the details, including key dates and how to submit on Sessionize, are spelled out on the CFP page for POSETTE 2025
Code-of-conduct: You can find the Code of Conduct for POSETTE online. Please help us to provide a respectful, friendly, and professional experience for everybody involved in this virtual conference.

Figure 2: the CFP is open for POSETTE: An Event for Postgres 2025 until Sunday Feb 9th at 11:59pm PST. What Postgres story do you want to share?

This article was originally published on citusdata.com.

Say hello to the Talking Postgres podcast

Claire Giordano — 2024-07-09T15:15:01+00:00

The TL;DR of this blog post is simple: the “Path To Citus Con” podcast for developers who love Postgres has been renamed—and the new name is Talking Postgres.

And if you’re just hearing about the Talking Postgres podcast for the first time, it is a monthly podcast for developers who love Postgres, with amazing guests from the Postgres world who talk about the human side of Postgres, databases, and open source.

Listening to the Talking Postgres podcast is the next best thing to being in the hallway at a Postgres conference, eavesdropping on other people’s conversations and learning from the experiences of experts. As Floor Drees says, it’s as if you’re sharing a coffee with them.

Past podcast guests include (in order of appearance) some amazing Postgres, database, and open source people such as: Simon Willison, Marco Slot, Abdullah Ustuner, Burak Yucesoy, Melanie Plageman, Samay Sharma, Álvaro Herrera, Boriss Mejías, Thomas Munro, Grant Fritchey, Ryan Booz, Chelsea Dole, Floor Drees, Paul Ramsey, Regina Obe, Andres Freund, Heikki Linnakangas, Dimitri Fontaine, Vik Fearing, Lukas Fittl, Rob Treat, Jelte Fennema-Nio, Derk van Veen, Arda Aytekin, Chris Ellis, Michael Christofides, Aaron Wislang, and Teresa Giacomini. The podcast is produced by the Postgres team at Microsoft—and I have the privilege of being your host.

So whether you’re an existing listener or new to this podcast, we hope you enjoy the Talking Postgres podcast—and help to spread the word about the new name.

Figure 1: The new “Talking Postgres with Claire Giordano” podcast name (formerly called Path To Citus Con) is depicted here with the same elephant mascot we’ve always used.

Some key things to know about the Talking Postgres podcast

Why did we rename the podcast?: Guests & friends repeatedly—and I mean repeatedly—nudged us to rename the podcast to a name that makes it more clear what the podcast is about. And at the end of the day it’s about Postgres things! So while the podcast was born in March 2023 as a pre-event to last year’s Citus Con—hence the original name, “Path To Citus Con”—Talking Postgres has grown into its own monthly podcast that has everything to do with Postgres and little to do with Citus Con (now called POSETTE.)
Where can you catch up on past podcast episodes?: All 16 of the past episodes of Path To Citus Con can now be found on the talkingpostgres.com site—as well as on the Talking Postgres playlist on YouTube, and wherever you get your podcasts.
If you’re already subscribed to the podcast, are you still subscribed?: We renamed the previous podcast, so if you were already subscribed, you should still be subscribed. Same thing for the RSS feed, it should just work! If you have any problems, please let us know via the #talkingpostgres channel in the Microsoft Open Source Discord.
Can you still attend the LIVE recording of the podcast on Discord each month?: Yes! Inspired by the Oxide and Friends podcast that is hosted by Bryan Cantrill and Adam Leventhal—two of my former teammates from the kernel group at Sun Microsystems—we also record Talking Postgres (formerly Path To Citus Con) each month on Discord—with a parallel live text chat that is quite fun to be part of.
When are the future LIVE podcast recordings: If you’ve never participated in this type of live podcast recording, you might want to give it a try. It’s easy to subscribe to the Talking Postgres calendar of future LIVE podcast recordings: we usually record on Wed mornings Pacific Time (PT) on the 1^st or 2^nd Wednesday of the month.
Episode 17 of Talking Postgres will be recorded LIVE this Wed July 10, 2024: This July, our guest is Pino de Candia—the former co-host of the podcast—and the topic will be a bit “meta” this time! We’ll explore “Podcasting about Postgres” and we’ll look back at some of our greatest hits, talk about some of the other wonderful Postgres podcasts we listen to, and of course we’ll spend a few minutes reflecting on the podcast rename (why why why!) This Ep17 calendar invite should give you all the instructions you need to join us live on Discord this Wed Jul 10th at 10:00am PDT.
And David Rowley is scheduled to be the guest on the August episode: Since David Rowley—a Postgres committer—is based in New Zealand, Ep18 in August with David Rowley will be recorded at an unusual time for us, on a Tuesday, specifically at 4:00pm PDT on Tue Aug 6th. The topic will be “How I got started as a developer & in Postgres” and we hope you can join us on the parallel live text chat! David is brilliant—and I’m definitely going to have to do my homework on Postgres performance topics to prep for the conversation, since that is one of David’s specialties.

Let us know what you think of the podcast, be sure to use hashtag #TalkingPostgres

The new hashtag for the new podcast name is #TalkingPostgres and as soon as we see some interesting tweets, toots, and threads about the podcast using the new name, perhaps we’ll add some of them to the talkingpostgres.com website.

For now, here is a screenshot highlighting guests and topics for some of the most recent podcast episodes. You can of course subscribe to Talking Postgres and listen from anywhere, wherever you get your podcasts from. Enjoy!

Figure 2: Screenshot of the Talking Postgres web page at talkingpostgres.com, showing the most recent 5 episodes.

This article was originally published on citusdata.com.