Building safety tooling for risk-free AI tuning of Postgres
summary
DBtune builds a safety layer for AI-driven Postgres tuning that actually works: it tests across Aurora, RDS (example db.r6g.4xlarge, 128 GB), GCP, Azure Flexible Server, CNPG, Kubernetes/Patroni and EPAS using HammerDB, BenchBase, pgbench and ClickHouse workloads, and enforces memory guardrails (80–85% threshold to prevent OOM from e.g. shared_buffers 32 GB + work_mem 64 MB causing OOM with 500 clients), uses Grafana/Prometheus plus pg_stat_statements/pg_stat_plans for performance regression detection, narrows search to fingerprints of top queries, validates with 30 iterations and rollback logic, and logs rejected configs for reproducible, safe tuning.
AI-written summary · about
chapters (11)
- 0:00Music & introduction
- 1:26The promise and fears around AI tuning
- 3:35Why Postgres tuning is complex
- 6:00Testing across environments and workloads
- 7:26Five key challenges in AI tuning
- 8:44Memory pitfalls and OOM risks
- 12:54Exploration trade-offs and search strategy
- 17:29Confidence and statistical validation
- 20:30Parameter interactions and ripple effects
- 22:47Evaluating AI tools without blind trust
- 24:40Safety-first design principles and takeaways
related talks
48mDBtune: AI-driven performance tuning for all PostgreSQL flavors
20mDebate: Autotuning
28mAutotuning PostgreSQL on Azure Flexible Server
48mChatGPT Ain’t Got $%@& On Me! Next Generation Automated Database Tuning
36mAutomated Performance Testing of Postgres
04mPostgres Tuning is saved by Sovenath Shaw
18mWhy Postgres Is Better Than MySQL for Automated Knob Tuning
44mContinuous Database Administration