Do we really need a DBA to manage our PostgreSQL databases on DBaaS
summary
Argues that DBaaS defaults are generic and often harmful: vendors set max_connections=16000+ to avoid support tickets, autotuning ignores workload patterns, and customers pay higher bills by blindly upsizing instances. Gives concrete failures: frequent autovacuums and unseen autovacuum_freeze_max_age=200000000 risks, 90% of clients not monitoring table age, Postgres 14 behavioral changes, and logical replication causing high WAL decoding load during upgrades. Recommends hands‑on DBA work for parameter tuning, partitioning, indexing and upgrade strategies.
AI-written summary · about
chapters (12)
- 0:00Intro
- 2:51Database Provisioning should not decrease Developer efficiency
- 6:25Database Tuning
- 8:17Sharing an Incident
- 11:00When does Autovacuum Run ?
- 13:13Scalability
- 15:58Heavy resource consuming background jobs
- 18:56Forced VACUUM FREEZE
- 20:37One of the Support Cases
- 24:08You may forget to Benchmark
- 25:41Database Upgrades are not really seamless
- 28:31Review of Schema changes
related talks
05mCommon mistakes of DBAs
46mPostgres Platform "Best Practices" for the Modern DBA
44mBridging the Gap: The Vital Role of DBAs while contributing to the DevOps Culture
36mPostgreSQL: Ups, DevOps...
51mHow Postgres is misused and abused in the wild
36mPostgreSQL: Ups, DevOps...
26mNavigating Managed Databases for Over a Decade as a Non-DBA
44mContinuous Database Administration