The Evolution of Postgres Performance
summary
Postgres 18 adds an io_method (sync, worker, io_uring) option but PlanetScale benchmarks show io_uring is often slower than the worker thread mode and sometimes slower than Postgres 17 depending on storage (EBS vs local NVMe). Autovacuum tuning shows an aggressive schedule prevents bloat—the lazy run grows >1GB and accumulates 11 million dead rows—while connection tests on an 8‑core box peak around ~64 active Postgres processes, so use a pooler like PG bouncer for thousands of client connections.
AI-written summary · about
chapters (7)
- 0:00Introduction to database ops
- 2:02Historical performance trends
- 5:11Utility of benchmarks
- 7:32Managing table bloat
- 10:31Optimizing connections
- 13:00I/O performance and hardware
- 15:47Conclusion
related talks
19mVacuuming Enhancements in PostgreSQL 18: Faster, Smarter, More Predictable
25mScaling PostgreSQL Beyond Query Optimization
52mBoosting Typical Query Patterns: PostgreSQL 18's Performance Enhancements
34mPostgres 10, Performance, and You
51mScaling Postgres to the next level at OpenAI
25mUnderstanding & Managing Postgres Table Bloat
53mVisualizing Postgres I O Performance for Development
43mPostgres Performance: From Slow to Pro