Loading Raymanthis…

Engineering

Why we moved our Postgres write path off RDS

Itse Sagay2 min read
Lattice of orange light trails on black

For two years our write path ran on a managed RDS instance sized for a traffic peak we hit twice a quarter. It was reliable, and it was the single largest line on our infrastructure bill.

This is the story of how we split reads from writes, moved the write primary to hardware we control, and cut $4,200 a month without adding a single page to the on-call rotation.

#What we measured first

Before touching anything we logged every query for a week and grouped them by plan shape. Ninety-one percent of our write load came from three tables, and almost none of it needed cross-region durability.

That told us the expensive part was not storage or compute, it was provisioned IOPS we paid for around the clock to survive a burst that lasted forty minutes.

  • Writes: 3 hot tables, append-heavy, batched every 200ms
  • Reads: 80% served from replicas with under 2s of lag tolerance
  • Peak: two events per quarter, both predictable from the calendar

#The cutover

We ran logical replication into the new primary for three weeks and compared row counts nightly. The cutover itself was a connection-string change behind a feature flag, rehearsed four times in staging.

The rollback plan was the boring kind: keep the old primary replicating backwards for 30 days, and only decommission it after a full billing cycle with no incidents.

sql
-- on the new primary
CREATE SUBSCRIPTION write_path_sub
  CONNECTION 'host=old-primary dbname=app user=replicator'
  PUBLICATION write_path_pub
  WITH (copy_data = true, create_slot = true);

-- nightly parity check
SELECT 'events' AS tbl, count(*) FROM events
UNION ALL
SELECT 'orders', count(*) FROM orders;

Share

Itse Sagay

Written by

Itse Sagay

Founder & Principal

Itse founded Raymanthis and leads the studio, hands-on in the work.

Meet the team →

Building something similar?