Postgres at any Scale
summary
Concrete takeaways: Postgres handles everything from <10 GB to multi‑node sharded clusters, with a real case of running 1.5 million Postgres databases on a small ops team; use JSONB + GIN for nested data, target a 99% cache hit ratio before premature tuning, add PG Bouncer for connection pooling, switch from pg_dump to physical backups (pgbackrest/stream WAL) past ~100 GB, test restores, and consider Citus or 128+ shard hashing with colocation when reads/writes outgrow a single instance.
AI-written summary · about
chapters (28)
- 0:00Intro
- 0:36The database is just a hash
- 1:09A bit about me
- 2:35The biggest mistake Postgres ever made - 2006
- 3:53Why Postgres TLDR
- 5:05Unique as open source
- 5:44The structure of the community
- 6:51How the project works
- 8:02Data types
- 9:53Feature rich SQL
- 11:10Indexing
- 13:46Procedural code
- 16:00Some pro-tips
- 18:05Small data ( 10 GB)
- 19:55Cache rules everything around me
- 20:43Index hit rate
- 21:26Unused indexes
- 22:22Rough guidelines
- 23:00Establishing a connection
- 23:31Postgres is bad at connections
- 24:55Pgbouncer is ideal solution
- 25:59Logical backup
- 27:06Slow performance?
- 27:22Horizontal scaling
- 29:15Citus Architecture
- 30:53Hash based distribution
- 32:29Reference tables for tables you can't colocate
- 33:12Sharding
related talks
37mPostgres at Any Scale
30mManaging Postgres at scale: Challenges, Tools & Techniques
51mScaling Postgres to the next level at OpenAI
48mBuilding Petabyte-Scale PostgreSQL Deployments
46mBig databases, many servers, data center or cloud - it's all here!
13mBuilding reliable infrastructure with Postgres
33mFive Sharding Data Models and Which is Right
48mHow to Tame A Mastodon: Lessons for PostgreSQL at Scale