Scaling a Saas application beyond a single Postgres with Citus
summary
SaaS primary DB moves from a single Postgres (~0.7 TB) to Citus with 64 shards, a 60 GB coordinator and 661 GB data nodes totaling ~3.8 TB available; migration costs about 3 dev‑months of prep, a 19‑hour cutover day for eight people, and extra hotfix hours. Rails code gets shard keys everywhere (acts_as_tenant), PG Bouncer is tuned, indices rebuilt with tuned maintenance_work_mem and create index concurrently where possible. Result: no data loss, much easier indexing and headroom, but coordinator overload from distributed scans forces index reordering and adding explicit shard hints to fix performance.
AI-written summary · about
chapters (22)
- 0:00Introduction
- 1:02Who are we
- 1:51Agenda
- 3:35Stealing work
- 4:16We dont have an elite problem
- 7:37Level of effort
- 15:44Code examples
- 19:42ActiveRecord Multitenant
- 20:51Rails ActiveRecord
- 22:45Read with Shard ID
- 24:44Save with Shard ID
- 25:14Wrappers
- 25:36Reads
- 25:55Distributed queries
- 28:03Index build speed
- 29:17Creating an index
- 32:56Postmortem
- 34:10Citus Fix
- 36:25Lucas Fix
- 37:25Hotfixes
- 42:08What went right
- 44:10What went wrong
related talks
24mLessons learned: Migrating from AWS-Hosted PostgreSQL RDS to Self-Hosted Citus
20mLessons learned scaling our SaaS on Postgres to 8+ billion events
44mDistributed Postgres with Citus
36mPostgres at any Scale
24mCitus from the Customer eyes
28mEfficiently distributing Postgres with Citus – How to choose the right shard key?
16mOnline Scale-Out and Cloud Data Ingestion
25mSelf Hosted Citus using Cloud Computing