EDB Engineering Newsletter #6

May 09, 2025

Welcome to the 6th edition of the EDB Engineering Newsletter! Where we share happenings in the data world that the team has enjoyed discussing, as well as other news about what the EDB Engineering team is up to.

What we're following

Built-in Raft replication

An interesting (but very speculative) thread about integrating Raft within Postgres, primarily for automatic leader failover without losing data.

https://www.postgresql.org/message-id/flat/Z_1Cq7JvabsFYjQo%40ark

An Intro to DeepSeek's Distributed File System

Henry Zhu, PhD student at University of Illinois Urbana-Champaign, wrote a great article walking through DeepSeek’s new 3FS distributed filesystem.

https://maknee.github.io/blog/2025/3FS-Performance-Journal-1/

CloudNativePG Contributor Spotlights

Floor Drees has been interviewing contributors to CloudNativePG, this month included interviews with:

From the EDB team

New committer: Jacob Champion

Hundreds of people contribute to Postgres. But very few (exactly 31) people have rights to commit to Postgres. Most contributions are by an author (the contributor) and a different committer (someone with commit rights), unless the author is a committer.

From the Postgres Committers page:

New committers are added approximately annually after discussions and vote among the existing committers. Contributors to PostgreSQL are selected to be committers based on the following loose criteria:
several years of substantial contributions to the project
multiple and continuing code contributions
responsibility for maintenance of one or more areas of the codebase
track record of reviewing and helping other contributors with their patches
high quality code contributions which require very little revision or correction for commit
demonstrated understanding of the process and criteria for patch acceptance

https://www.postgresql.org/message-id/flat/253b3db5-4250-49fc-9c81-2167cb9f3c04%40postgresql.org

CloudNativePG 101

Gabriele Quaresima gave a talk at PGDay Chicago on CloudNativePG basics. His slides are now available.

https://postgresql.us/events/pgdaychicago2025/sessions/session/1867/slides/185/CloudNativePG_101.pdf

Compliance at the Speed of Innovation: Leveraging AI-Driven Automation for Real-Time Regulatory Read

Simon Metson joined a panel at KubeCon + CloudNativeCon Europe to speak about how adopting a code-based approach to compliance—powered by agentic AI—can accelerate one’s go-to-market strategy by automating the creation of compliance artifacts.

Consistent Volume Group Snapshots, Unraveling the Magic

Leonardo Cecchi of EDB teamed up with Xing Yang of VMware at KubeCon + CloudNativeCon 2025 to explore the inner workings of VolumeGroupSnapshots, which provides write-order consistent snapshots for multiple volumes. It is an alpha feature in Kubernetes 1.27 and is now in the process of being promoted to beta. They spoke about its proper usage and gave troubleshooting and debugging advice.

The Next Wave Of Data On Kubernetes: Winning Over The Enterprise

Simon Metson gave the sponsored keynote at KubeCon + CloudNativeCon Europe, sharing real-world examples of enterprises successfully adopting Postgres on Kubernetes for critical and complex workloads.

Allow NOT NULL constraints to be marked NOT VALID

A patch from Rushabh Lathia and Jian He was committed, adding support for altering a table to add a NOT NULL constraint that is also marked NOT VALID.

As the Postgres ALTER TABLE documentation mentions, this allows a user to split up adding a constraint and validating a constraint for greater performance.

Scanning a large table to verify a new foreign key or check constraint can take a long time, and other updates to the table are locked out until the ALTER TABLE ADD CONSTRAINT command is committed. The main purpose of the NOT VALID constraint option is to reduce the impact of adding a constraint on concurrent updates. With NOT VALID, the ADD CONSTRAINT command does not scan the table and can be committed immediately. After that, a VALIDATE CONSTRAINT command can be issued to verify that existing rows satisfy the constraint. The validation step does not need to lock out concurrent updates, since it knows that other transactions will be enforcing the constraint for rows that they insert or update; only pre-existing rows need to be checked. Hence, validation acquires only a SHARE UPDATE EXCLUSIVE lock on the table being altered. (If the constraint is a foreign key then a ROW SHARE lock is also required on the table referenced by the constraint.) In addition to improving concurrency, it can be useful to use NOT VALID and VALIDATE CONSTRAINT in cases where the table is known to contain pre-existing violations. Once the constraint is in place, no new violations can be inserted, and the existing problems can be corrected at leisure until VALIDATE CONSTRAINT finally succeeds.

And an example of how it is used:

To add a foreign key constraint to a table with the least impact on other work:
ALTER TABLE distributors ADD CONSTRAINT distfk FOREIGN KEY (address) REFERENCES addresses (address) NOT VALID;
ALTER TABLE distributors VALIDATE CONSTRAINT distfk;

Previously NOT VALID was only allowed for foreign key constraints and CHECK constraints.

https://github.com/postgres/postgres/commit/a379061a22a8fdf421e1a457cc6af8503def6252

Until next time

We hope you enjoyed this edition of the EDB Engineering Newsletter! Consider joining the PostgreSQL Hacker Mentoring Discord to get involved!

The EDB Engineering Team