Upgrading Postgres Clusters With Minimal Downtime
ProductsPayments<br>Stablecoins<br>Ledgers
SolutionsCross-Border<br>Digital Wallets<br>Embedded ACH<br>Global USD Accounts<br>Lending<br>Payroll<br>Rewards & Points<br>Stablecoin Orchestration<br>Programmatic Sub-Accounts
ResourcesLibrary<br>Journal<br>Newsroom
DocsPayments<br>Ledgers<br>API Reference<br>Release Notes
CustomersPricing
Journal•May 29, 2026
Upgrading Postgres Clusters With Minimal Downtime<br>Learn how we upgraded Amazon Aurora PostgreSQL from 14 to 17 with zero downtime using a custom Blue/Green deployment, logical replication, and fully automated cutover.<br>Tony Li / Software Engineer
Contents&]:rotate-180" fill="currentColor" height="24px" role="img" viewBox="0 -960 960 960" width="24px" xmlns="http://www.w3.org/2000/svg" aria-hidden="true">
Explore With AI&]:rotate-180" fill="currentColor" height="24px" role="img" viewBox="0 -960 960 960" width="24px" xmlns="http://www.w3.org/2000/svg" aria-hidden="true">
Topics<br>Engineering
Upgrading a database will never be exciting. But with the right design and automation, it doesn't have to be scary either.<br>We needed to upgrade our Aurora Postgres clusters from version 14 to 17 across multiple production environments powering real-time payment systems. Aurora had just added support for version 17 with features we wanted to adopt. But the constraints were strict: no downtime visible to the users, no data loss, and no manual, one-off processes. The entire upgrade had to be automated and repeatable, so future upgrades could follow the same process rather than being treated as one-off efforts.<br>The Constraints<br>A cell in our system is an independent, self-contained production environment that serves a subset of traffic and can be operated or upgraded in isolation. Each of our production cells runs its own Aurora Postgres cluster. Applications connect through multiple paths:<br>Most workloads through PgBouncer in transaction-pooling mode<br>Some containers directly to the writer endpoint (these workloads require features that PGBouncer in transaction-pooling mode cannot provide, such as WITH HOLD CURSOR)<br>ParadeDB is a separate Postgres-based system used for search, which continuously replicates data from our primary database via logical replication.<br>ParadeDB was a key constraint because it’s an external Postgres system continuously replicating from our Aurora primary via replication slots. It connects through an NLB whose target is kept in sync with the current primary by a Lambda that resolves the writer endpoint every 2 minutes. This NLB’s target group is pointed to the primary IP by a lambda that runs every 2 minutes, resolving the DNS of the writer endpoint of the Aurora cluster.<br>The presence of active replication slots for ParadeDB meant we couldn't use Aurora's native Blue/Green upgrade feature (which creates a fully synchronized copy of the database and allows traffic to be switched over). AWS doesn't allow creating a green deployment when replication slots exist. Deleting them would cause ParadeDB to fall behind and require manual backfills—not an acceptable tradeoff.<br>All this meant we needed our own Blue/Green upgrade—one that could maintain replication, preserve users and roles, and switch traffic seamlessly.At a high level, our approach still follows the familiar Blue/Green pattern—replicate, then cut over. However, because Aurora’s native implementation doesn’t support active logical replication slots, we had to build a custom workflow to preserve replication and orchestrate the transition safely.<br>Design Constraints<br>We built the solution around a few non-negotiables:<br>No data loss : All writes replicated and confirmed before switching.<br>Zero downtime : No lost connections or paused systems visible to users.<br>Full automation : Every step repeatable through infrastructure-as-code and AWS Step Functions.<br>The high-level approach: stand up a new Aurora cluster (the "green" database) running Postgres 17, replicate data from the existing Postgres 14 cluster (the "blue" database) using logical replication, and switch connections once both are in sync.<br>Testing in the demo<br>Before rolling this out to production, we ran the full upgrade process end-to-end in a demo cell. This let us validate the replication setup, switchover sequence, and automation under realistic conditions.<br>Testing in isolation helped catch issues early—such as configuration assumptions and credential handling—and gave us confidence that the process would behave as expected in production.<br>The phases<br>The upgrade process unfolds in two main phases: setup and switchover.<br>Setup Phase<br>Provision the new cluster : Terraform brings up the green database alongside the existing blue one. The green instance is monitored by its own Datadog agent so replication lag can be tracked independently.<br>Establish logical replication : Publications and subscriptions mirror every table from blue to green. In larger clusters, multiple publications and subscriptions are created, with high throughput tables...