Efficiently distributing Postgres with Citus – How to choose the right shard key?
summary
Citus uses a create_distributed_table shard key to hash and place rows across workers; pick a column with hundreds-to-tens-of-thousands cardinality to avoid skew, or you bottleneck a single node. Multi-tenant apps shard on tenant_id to keep joins, transactions and indexes local; real‑time analytics co‑locate large fact tables on a shared dimension; high‑throughput OLTP shards on the point-lookup key. Sai outlines using pg_stat_statements or PGCollector to analyze queries and even heuristically predict shard keys for Hyperscale Citus.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 1:31What is Citus?
- 4:24What is a distribution column & why is it important?
- 9:223 steps to building highly scalable apps with Citus
- 10:43Multi-tenant SaaS apps
- 15:40Real-time operational analytics apps
- 19:33High throughput transactional apps
- 22:14Exploring automation of choosing the right shard key
- 24:31Q&A with Sai & Marco
related talks
31mKEYNOTE: The Distributed PostgreSQL Problem & How Citus Solves it
31mSharding Without the Complexity
44mDistributed Postgres with Citus
33mFive Sharding Data Models and Which is Right
40mBeginner's Guide to Partitioning vs. Sharding in Postgres
08mFoundations of Distributed PostgreSQL with Citus
24mCitus from the Customer eyes
16mKeynote – Umur Cubukcu