Global Replication with Postgres & Postgres 19 REPACK

Hi Everyone,

We're excited to invite you to the next Boston PostgreSQL User Group (BPUG) Meetup, hosted at the Datadog Boston office.
📅 Date: Wednesday, October 14, 2026
🕡 Time: 6:30 PM – 8:30 PM ET
📍 Location: Datadog Boston Office
Agenda

1. Building a Global Store Using Postgres
2. Postgres 19 REPACK

Please RSVP by October 13, 2026. Food and drinks will be provided 🍕

Please find the abstract of the talks below

Talk 1: Building a Global Store Using Postgres
Datadog runs a globally distributed infrastructure in which client applications connect to the nearest datacenter, with a strong preference for local access. Supporting this model takes storage that is globally replicated, cost-efficient, highly reliable, quick to recover, and able to keep cross-region replication latency low.
Our team built a new global storage system on Postgres using only its built-in logical replication, with no custom extensions and no forked Postgres.
In this talk, we'll cover:

*Why our legacy global store fell short, and what we needed from a new system

• The architecture, key challenges, and design trade-offs behind the new store
  *An AI-first approach to onboarding and operating the system
• How we leveraged Datadog's deep Postgres expertise and ecosystem
  *Results and lessons learned from running it at scale

Speakers

• Sanketh Balakrishna is a Senior Engineering Manager at Datadog, where he leads the Managed Replication & Search team within the Transactional Storage group, which provides platforms for replicating and searching data.
  *Maxim Briskin is a Senior Software Engineer at Datadog on the Data Replication team, which provides a fast, reliable way to replicate data across databases, regions, and systems. He’s also the lead engineer for the Global Storage initiative.

Talk 2: Postgres 19 REPACK
REPACK in PostgreSQL 19: Rewriting a Bloated Table Without Locking Everyone Out

VACUUM FULL and CLUSTER both give disk space back to the operating system, but they hold an ACCESS EXCLUSIVE lock for the whole rewrite. That is why most of us reach for the pg_repack extension instead. PostgreSQL 19 adds a built-in REPACK command that covers both jobs, and REPACK (CONCURRENTLY) keeps the table readable and writable during the rewrite. It uses logical decoding to catch up on concurrent changes, and takes the heavy lock only for the final file swap. In fifteen minutes I will show how it works, what it costs, and the limits you should know before you run it in production.

Speaker

***Shihao Zhong **is a Senior Software Engineer at Google, works on the AlloyDB Storage team, focusing on replication and performance.

We look forward to seeing you there!