The Building Blocks for Self-Driving PostgreSQL
summary
Claims a working path to a true self-driving database by combining workload forecasting, learned component behavior models, and automated action deployment using NoisePage and OtterTune ideas. Uses PGCollector and pg_dump for traces, finds pg_replay single‑threaded so Oracle RAT works better for concurrent replay, and relies on HypoPG for index what‑ifs because Postgres lacks a full what-if API and partitioning simulation. Proposes Linux BPF for missing OS‑level telemetry, notes many knobs require restarts and nonblocking partitioning is missing.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 2:05What is a self-driving database?
- 8:32Does Postgres have what we need for a self-driving database?
- 10:31Workload capture
- 16:34System telemetry
- 20:38What-if API
- 25:28Action APIs
- 29:01So, does Postgres have what we need?
related talks
53mMake Your Database Dream of Electric Sheep: Designing for Autonomous Operation
21mDriving the Future of PostgreSQL Adoption
34mAnalytics and AI with PostgreSQL - Mission Possible!
51mWhen Postgres Can't, You Can!
35mBreakout Session
47mBeginner's guide to PostgreSQL Hacking
01h 00mPostgreSQL and Artificial intelligence
51mScaling Postgres to the next level at OpenAI