Database Geek and PostgreSQL fan. With over 17 years of experience with databases like Oracle, Postgresql, MySQL for 17 years with roles like DBA, Database Engineer, Database Architect, Migration Specialist, Database SA.
Partitioning is often presented as a straightforward solution for scaling large PostgreSQL tables. When applied correctly, it can improve query performance, simplify data retention, and reduce operational risk. When applied incorrectly, it can increase maintenance overhead, amplify bloat, and quietly degrade system reliability. This talk takes a practical, production-focused look at PostgreSQL partitioning beyond syntax and basic use cases. We will explore how partitioned tables interact with MVCC, vacuum, and autovacuum, and why partitioning does not eliminate bloat but instead redistributes it across many smaller relations. We will examine how partition count, partition size, and access patterns affect vacuum scheduling, index maintenance, planning time, and overall system stability. Using real-world scenarios, the session highlights common failure modes: over-partitioning, poorly chosen partition keys, vacuum storms, retention jobs causing I/O spikes, and unexpected behavior with replicas or logical replication. We will also discuss cases where partitioning provides little or no benefit compared to simpler designs. Rather than prescribing rigid rules, this talk provides a decision framework for using partitioning safely: when it is the right tool, when it is not, and how to balance performance gains against operational complexity. Attendees will leave with a clearer understanding of the trade-offs involved and the ability to evaluate partitioning as an architectural choice rather than a default scaling mechanism.