{"slug": "show-hn-pbtune-evolutionary-auto-tuning-for-postgresql-no-ml-required", "title": "Show HN: PBTune – Evolutionary auto-tuning for PostgreSQL (no ML required)", "summary": "A research implementation called PBTune applies Population-Based Training (PBT), an evolutionary algorithm from DeepMind, to automatically tune PostgreSQL database configurations without machine learning. The system maintains a population of configurations, allowing poor performers to copy from top performers and explore variations, achieving autonomous discovery of high-performance settings. The project is open-source with documentation available at alshawai.github.io/PBTune.", "body_md": "This repository contains a research implementation applying **Population-Based Training (PBT)**, originally developed by DeepMind for neural network hyperparameter optimization, to the domain of database configuration tuning. Our work demonstrates that evolutionary optimization strategies can autonomously discover high-performance database configurations without domain expertise.\n\n📚 **Full Documentation**: [alshawai.github.io/PBTune](https://alshawai.github.io/PBTune/)\n\n[Overview](#overview)[Key Innovation](#key-innovation)[Architecture](#architecture)[Repository Structure](#repository-structure)[Installation](#installation)[Quick Start](#quick-start)[Documentation](#documentation)[Research Foundation](#research-foundation)[Experimental Results](#experimental-results)[Future Work](#future-work)[Contributing](#contributing)[License](#license)[Citation](#citation)[Acknowledgments](#acknowledgments)\n\nDatabase configuration tuning is a critical yet challenging task in database administration. PostgreSQL exposes over 300 configuration parameters (\"knobs\"), with complex interdependencies and non-linear effects on performance. Traditional approaches rely on:\n\n**Manual tuning** by expert DBAs (time-consuming, non-scalable)**Rule-based systems**(inflexible, limited adaptability)** Bayesian Optimization**(sample-inefficient for high-dimensional spaces)** Reinforcement Learning**(requires extensive training data, unstable)\n\nThis work proposes a **novel alternative**: applying Population-Based Training—an evolutionary algorithm that maintains a population of configurations, periodically allowing poor performers to \"exploit\" successful configurations and \"explore\" nearby variations.\n\n**Key Advantages:**\n\n**Parallel Exploration**: Evaluates multiple configurations simultaneously across isolated PostgreSQL instances** Online Adaptation**: Configurations evolve during optimization, avoiding wasted evaluations** Sample Efficiency**: Poor performers copy from elites rather than exploring randomly** No Training Required**: Unlike RL, PBT needs no pre-training phase or external datasets** Automatic Convergence**: Built-in exploitation naturally drives population toward optimal regions\n\n**Novel Contributions:**\n\n- First application of PBT to database configuration optimization\n- Adaptive metric normalization for heterogeneous workload types\n- Feature-driven composite scoring with compatibility mode for historical sessions\n- Intelligent restart management balancing exploration vs. overhead\n\nPBT maintains a population of\n\n- A\n**configuration**$\\theta_i$ (knob values) - A\n**performance score**$f(\\theta_i)$ (throughput, latency, etc.)\n\nAt regular intervals (generations), the algorithm performs:\n\n**Truncation Selection (Exploit)**: Bottom 20% of workers copy configurations from top 20%** Perturbation (Explore)**: Copied configurations are perturbed (±20% for continuous, probabilistic flip for categorical)** Evaluation**: All workers evaluated in parallel on isolated database instances\n\nThis creates a co-evolutionary process where configurations **evolve during training**, unlike traditional hyperparameter search methods that evaluate configurations independently.\n\nOur implementation extends vanilla PBT with database-specific adaptations:\n\n**Proportional Perturbation**: Categorical knobs perturbed based on value space size (30% for booleans, adaptive for enums)** Metric Normalization**: OtterTune-inspired percentile-based normalization adapts to observed ranges** Feature-Driven Scoring**: Workload features drive composite metric weighting through scoring-v2, with`fixed_v1`\n\nretained for compatibility**Intelligent Restarts**: CDBTune-inspired batched restarts (every 10 generations) balance configuration changes vs. overhead\n\nSee [ docs/architecture/feature-driven-scoring.md](/alshawai/PBTune/blob/main/docs/architecture/feature-driven-scoring.md) for the scoring model, policy metadata, and migration notes.\n\nSee [ docs/architecture/pbt-core.md](/alshawai/PBTune/blob/main/docs/architecture/pbt-core.md) for detailed algorithm description.\n\n```\n┌───────────────────────────────────────────────────────────────┐\n│                     PBT Tuner System                          │\n└───────────────────────────────────────────────────────────────┘\n\n                    ┌──────────────────┐\n                    │   Main Tuner     │\n                    │  (Orchestrator)  │\n                    └────────┬─────────┘\n                             │\n          ┌──────────────────┼──────────────────┐\n          │                  │                  │\n          ▼                  ▼                  ▼\n    ┌────────────┐    ┌────────────┐    ┌────────────┐\n    │ Population │    │  Workload  │    │ Instance   │\n    │  Manager   │───→│Orchestrator│───→│  Manager   │\n    └────────────┘    └────────────┘    └────────────┘\n            │                 │               │\n            │                 │               │\n      ┌─────┴─────┐      ┌────┴────┐   ┌──────┴───┐\n      ▼           ▼      ▼         ▼   ▼          ▼\n  ┌────────┐  ┌────────┐ │    │ ┌────────┐  ┌────────┐\n  │Worker 0│  │Worker 1│ │    │ │ PG:5440│  │ PG:5441│\n  │config_0│  │config_1│ │    │ │Instance│  │Instance│\n  │score_0 │  │score_1 │ │    │ │worker_0│  │worker_1│\n  └────────┘  └────────┘ ... ...└────────┘  └────────┘\n     │            │                  │           │\n     ↓            ↓                  ↓           ↓\n┌─────────────────────────────────────────────────────┐\n│         Evolution (Exploit-Explore Cycle)           │\n├─────────────────────────────────────────────────────┤\n│ • Truncation Selection: Bottom 20% copy top 20%     │\n│ • Perturbation: Continuous (±20%), Categorical (30%)│\n│ • Convergence Detection: 3 generations stable       │\n└─────────────────────────────────────────────────────┘\n```\n\n| Component | Purpose | Location |\n|---|---|---|\nPopulation |\nManages worker pool, orchestrates PBT algorithm |\n`src/tuners/pbt/population.py` |\n\n**Worker**`src/tuners/pbt/worker.py`\n\n**Evolution**`src/tuners/pbt/evolution.py`\n\n**Generation Barriers**`src/tuners/engine/barriers.py`\n\n**Workload Orchestrator**`src/tuners/engine/orchestrator.py`\n\n**Environment Backends**`src/utils/environments/`\n\n**Knob Space**`src/knobs/knob_space.py`\n\n**Scoring (v2)**`src/utils/scoring/`\n\nSee [ docs/architecture/pbt-core.md](/alshawai/PBTune/blob/main/docs/architecture/pbt-core.md) for component interaction details.\n\n```\n.\n├── src/                          # Source code\n│   ├── tuners/                   # Tuning engines (PBT + shared base/engine)\n│   │   ├── base.py               # BaseTuner (shared session/CLI scaffolding)\n│   │   ├── bo/                   # BO: Bayesian Optimization baseline\n│   │   ├── engine/               # WorkloadOrchestrator + restart policy + barriers + base worker\n│   │   ├── lhs_design/           # LHS Design to create diverse data for knob importance analysis\n│   │   ├── pbt/                  # PBT: population, worker, evolution, config, tuner, cli\n│   │   └── __main__.py           # Routed CLI entry point (python -m src.tuners pbt)\n│   ├── utils/                    # Shared utilities\n│   │   ├── environments/         # Docker / bare-metal database backends\n│   │   ├── scoring/              # Feature-driven scoring v2\n│   │   ├── logger/               # Colored logging + HTML output + context\n│   │   ├── applicator.py         # KnobApplicator\n│   │   ├── metrics.py            # PerformanceMetrics\n│   │   ├── metric_instrumentation.py\n│   │   ├── hardware_info.py      # WorkerResources detection\n│   │   ├── calibration.py       # Post-hoc global score recalibration (was rescoring.py)\n│   │   └── types.py\n│   ├── benchmarks/               # External benchmark executors (sysbench, tpch)\n│   ├── database/                 # psycopg2 / SQLAlchemy connections + lifecycle\n│   ├── config/                   # Env-derived database credentials + data-root resolution\n│   ├── knobs/                    # pg_settings retrieval + tuning metadata + policy filter\n│   ├── analysis/                 # fANOVA + TreeSHAP + tier generation\n│   ├── evaluation/               # Post-hoc default-vs-tuned comparison suite\n│   ├── visualization/            # Plot loaders + registry + theme + CLI\n│   └── scripts/                  # Setup, cleanup, BO baseline, comparisons\n├── docs/                         # Documentation (see docs/README.md for the index)\n├── data/                         # Knob metadata, policy, tier CSVs\n│   ├── knob_metadata.json\n│   ├── knob_policy.json\n│   ├── expert_defined_knobs/     # minimal | core | standard | extensive CSVs\n│   └── data_driven_knobs/        # workload-specific tiers from analysis pipeline\n├── results/                      # Optimization results (JSON + HTML logs)\n│   ├── oltp/{workload}/{pbt_runs,bo_runs,comparisons,baselines}/\n│   ├── olap/{pbt_runs,bo_runs,comparisons,baselines}/\n│   └── analysis/{workload}/\n├── workloads/                    # Workload definitions (OLTP, OLAP, custom)\n├── notebooks/                    # Jupyter notebooks for analysis\n├── tests/                        # Unit test suite\n├── requirements.txt              # Runtime Python dependencies\n├── requirements-dev.txt          # Dev/test/lint/typecheck dependencies\n├── pyproject.toml                # Ruff + mypy configuration\n└── Makefile                      # Deterministic local validation targets\n```\n\n**Python 3.11+****PostgreSQL 14+**(with`pg_ctl`\n\n,`initdb`\n\nin PATH)**psutil**(system monitoring)** sysbench**(optional, for OLTP workloads)\n\n```\ngit clone https://github.com/alshawai/PBTune.git\ncd PBTune\npip install -r requirements.txt\n```\n\nFor contributor workflows (tests, lint, type checks), install development dependencies as well:\n\n```\npip install -r requirements-dev.txt\n```\n\n**Key Dependencies:**\n\n`psycopg2-binary`\n\n- PostgreSQL adapter`psutil`\n\n- System resource monitoring`numpy`\n\n- Numerical operations for PBT`pandas`\n\n- Knob metadata processing`python-dotenv`\n\n- Environment variable management`pytest`\n\n- Unit test runner`ruff`\n\n- Linting baseline (high-signal correctness checks)`mypy`\n\n- Type-check baseline for evaluation module\n\nCreate a `.env`\n\nfile from the template:\n\n```\ncp .env.example .env\n```\n\nEdit `.env`\n\nwith your database (e.g., PostgreSQL) credentials:\n\n```\nDB_USER=postgres\nDB_PASSWORD=your_secure_password\nDB_HOST=localhost\nDB_PORT=5432\nDB_NAME=test_dataset\n```\n\nSee [ docs/getting-started/setup.md](/alshawai/PBTune/blob/main/docs/getting-started/setup.md) for detailed setup instructions.\n\n```\npython -m src.scripts.setup_database\n```\n\nThis creates:\n\n`sbtest1`\n\ntable with 10,000 rows (OLTP workload testing)- Indexes and constraints\n\nRun the deterministic command matrix used by CI:\n\n```\nmake lint\nmake typecheck\nmake test\n# or run all gates\nmake check-all\n```\n\nImportant Notes:\n\n- Actual runtime depends on your hardware (CPU cores, RAM, storage speed). Times shown are estimates for modern multi-core systems with SSD storage.\n- The number of knobs does\nNOTscale proportionally to wall-clock time, as PBT applies a candidate configuration from the entire knob spaceat once. But tuning performance may be degraded, causing PBT to requiremore generationsto reach optimal performance.\n\nOptimize 5 core knobs with minimal population for quick testing:\n\n```\npython -m src.tuners pbt \\\n  --tier minimal \\\n  --config rapid \\\n  --generations 10 \\\n  --population 4\n```\n\n**Output:**\n\n- JSON results:\n`results/oltp/oltp_read_write/pbt_runs/minimal/tuning_sessions/pbt_results_TIMESTAMP.json`\n\n- HTML log (colored):\n`results/oltp/oltp_read_write/pbt_runs/minimal/pbt_tuning_TIMESTAMP.html`\n\n- Best config:\n`results/oltp/oltp_read_write/pbt_runs/minimal/best_configs/best_config_TIMESTAMP.json`\n\nTune 13 core knobs with standard PBT configuration:\n\n```\npython -m src.tuners pbt \\\n  --tier core \\\n  --config standard \\\n  --generations 30 \\\n  --population 8\n```\n\nLarger knob space (36 parameters) with thorough evaluation:\n\n```\npython -m src.tuners pbt \\\n  --tier standard \\\n  --config thorough \\\n  --generations 50 \\\n  --population 12 \\\n  --workload oltp\npython -m src.tuners pbt \\\n  --tier core \\\n  --config standard \\\n  --workload-file workloads/custom_queries.json\n```\n\nOverride automatic hardware detection to manually allocate RAM and CPU cores for each parallel worker (up to 95% of host capacity):\n\n```\npython -m src.tuners pbt \\\n  --worker-ram 4G \\\n  --worker-cpus 2 \\\n  --parallel-workers 3\n```\n\nOpen the HTML log in your browser for color-coded output:\n\n```\n# Path follows the workload-partitioned layout, e.g. for OLTP read-write minimal tier:\nLOG=results/oltp/oltp_read_write/pbt_runs/minimal/pbt_tuning_TIMESTAMP.html\n\n# Windows\nstart \"$LOG\"\n\n# macOS\nopen \"$LOG\"\n\n# Linux\nxdg-open \"$LOG\"\npython -m src.tuners pbt --help\n```\n\n**Key Arguments:**\n\n| Argument | Options | Default | Description |\n|---|---|---|---|\n`--tier` |\n`minimal` , `core` , `standard` , `extensive` |\n`minimal` |\nKnob space tier (5, 13, 36, 80+ knobs) |\n`--config` |\n`rapid` , `standard` , `thorough` , `research` , `extreme` |\n`standard` |\nPBT configuration profile |\n`--population` |\ninteger | from profile | Worker count (overrides profile) |\n`--generations` |\ninteger | from profile | Optimization iterations |\n`--workload` |\n`oltp` , `olap` , `mixed` |\n`oltp` |\nWorkload type |\n`--duration` |\nseconds | 30 | Evaluation duration per worker |\n`--sysbench-workload` |\n`oltp_read_only` , `oltp_read_write` , `oltp_write_only` |\n`oltp_read_write` |\nSysbench OLTP mode when `--benchmark sysbench` |\n`--scoring-policy` |\n`fixed_v1` , `feature_driven_v2` |\nfalls back to PBT config | Scoring policy (`feature_driven_v2` for new runs) |\n`--scoring-policy-version` |\nversion string | `2.0` |\nScoring policy version |\n`--scoring-calibration-evals` |\ninteger | `5` |\nNumber of evals for normalization calibration |\n`--tuning-mode` |\n`online` , `offline` , `adaptive` |\n`offline` |\nRestart policy (online = no restarts; offline = every gen; adaptive = every N gens) |\n`--verbose` |\n`DEBUG` , `INFO` , `WARNING` , `ERROR` , `TRACE` |\n`INFO` |\nConsole log level |\n\nUse explicit Sysbench workload mode selection when running OLTP benchmarks:\n\n```\n# Read-only OLTP benchmark\npython -m src.tuners pbt --benchmark sysbench --sysbench-workload oltp_read_only --tier core --config standard\n\n# Read-write OLTP benchmark (default)\npython -m src.tuners pbt --benchmark sysbench --sysbench-workload oltp_read_write --tier core --config standard\n\n# Write-only OLTP benchmark\npython -m src.tuners pbt --benchmark sysbench --sysbench-workload oltp_write_only --tier core --config standard\n```\n\nSysbench outputs are partitioned by mode:\n\n- PBT sessions:\n`results/oltp/{sysbench_workload}/pbt_runs/{tier}/...`\n\n- BO sessions:\n`results/oltp/{sysbench_workload}/bo_runs/{tier}/...`\n\n- Evaluation comparisons:\n`results/oltp/{sysbench_workload}/comparisons/{tier}/...`\n\nUse feature-driven scoring during tuning for workload-aware metric weighting:\n\n```\n# Use feature-driven scoring during tuning\npython -m src.tuners pbt --tier core --config standard --scoring-policy feature_driven_v2\n\n# Re-evaluate a session with a different scoring policy\npython -m src.evaluation \\\n    --session results/olap/pbt_runs/extensive/tuning_sessions/pbt_results_YYYYMMDD_HHMM.json \\\n    --scoring-policy feature_driven_v2\n```\n\nAvailable policies:\n\n`fixed_v1`\n\n— legacy static weights (compatibility only; loaded automatically for historical sessions)`feature_driven_v2`\n\n— dynamic workload-feature-conditioned weights (**default for new runs**)\n\nThis framework intentionally supports a two-pronged benchmarking methodology:\n\n**Academic Baselines**: For scientifically rigorous evaluations without Python overhead, use external C-binaries (e.g.`--benchmark sysbench`\n\n).**Custom Prototyping**: For tuning proprietary application databases, use the internal JSON-based query templates.\n\nFor full architectural details on this design, please read the [Benchmarking Documentation](/alshawai/PBTune/blob/main/docs/reference/benchmarking.md).\n\nThe tuner allows you to define your own workload templates using JSON or YAML.\nThese files are natively executed by the `WorkloadExecutor`\n\n, which supports\ndynamic parameter injection for variables such as `{id}`\n\n, `{k_val}`\n\n, `{threshold}`\n\n,\n`{low}`\n\n, `{high}`\n\n, and `{offset}`\n\n.\n\nExample JSON (`my_workload.json`\n\n):\n\n```\n{\n  \"name\": \"Custom Workload\",\n  \"description\": \"Application-specific query patterns\",\n  \"queries\": [\n    {\n      \"sql\": \"SELECT * FROM users WHERE id = {id}\",\n      \"weight\": 0.5,\n      \"description\": \"Primary key lookup\"\n    }\n  ]\n}\n```\n\nRun with:\n\n```\npython -m src.tuners pbt --workload-file path/to/my_workload.json\n```\n\nSee the [workloads directory README](/alshawai/PBTune/blob/main/workloads/README.md) for full formatting details.\n\nComprehensive documentation available in [ docs/](/alshawai/PBTune/blob/main/docs):\n\n- Navigation map for all project docs[Documentation Index](/alshawai/PBTune/blob/main/docs/README.md)\n\n- Worker, Evolution, Population, lockstep generation barriers[PBT Core Components](/alshawai/PBTune/blob/main/docs/architecture/pbt-core.md)- Scoring-v2 policies, workload features, normalization, and reliability gate[Feature-Driven Scoring](/alshawai/PBTune/blob/main/docs/architecture/feature-driven-scoring.md)- WorkloadOrchestrator, PerformanceMetrics, scoring integration[Performance Evaluation](/alshawai/PBTune/blob/main/docs/architecture/performance-evaluation.md)- KnobSpace, tier CSVs, KnobApplicator, verify() read-back[Configuration Management](/alshawai/PBTune/blob/main/docs/architecture/configuration-management.md)\n\n- Database connection, knob retrieval, tuning metadata, policy filter[PostgreSQL Connection and Knobs](/alshawai/PBTune/blob/main/docs/architecture/postgresql-connection-and-knobs.md)- Installation, configuration, troubleshooting[Environment Setup](/alshawai/PBTune/blob/main/docs/getting-started/setup.md)- Canonical comparative-evaluation commands, outputs, and reproducibility checks[Evaluation Reproducibility Runbook](/alshawai/PBTune/blob/main/docs/guides/evaluation-runbook.md)\n\nThis work builds upon several research directions:\n\n**Jaderberg et al. (2017)**: \"Population Based Training of Neural Networks\" - Original PBT algorithm for neural network hyperparameter optimization\n\n-\n**OtterTune (2017)**: Automated configuration tuning using ML and transfer learning*Contribution*: Adaptive metric normalization using percentile-based ranges\n\n-\n**CDBTune (2019)**: Deep reinforcement learning for database knob tuning*Contribution*: Intelligent restart management, batched restarts every N iterations\n\n-\n**QTune (2019)**: Query-aware database configuration tuning*Contribution*: Workload-specific metric weighting\n\n**Latin Hypercube Sampling**: Space-filling initial population generation** Truncation Selection**: Efficient exploitation mechanism** Adaptive Perturbation**: Context-aware exploration strategies\n\nSee the curated analysis and references in:\n\n-\nAuto DBMS Tuner (5 papers)\n\n-\nReinforcement Learning for DB tuning (4 papers)\n\n-\nQuery Optimization (1 paper)\n\n-\nAdaptive Indexing (3 papers) - future work\n\n: This section describes the expected research methodology. Comprehensive benchmarking across diverse hardware configurations and workloads is ongoing. Results shown below are preliminary and illustrative of the system's capabilities.⚠️ Status\n\n**System Used for Development:**\n\n- Population: 4-8 workers\n- Generations: 10-30\n- Knob Tier:\n`core`\n\n(13 parameters) - Workload: OLTP (Sysbench-compatible)\n\n**Observed Behavior:**\n\n**Convergence**: The population shows convergence within 10-15 generations** Configuration Evolution**: Poor performers successfully adopt elite configurations** Stability**: Top-performing configurations remain stable across multiple generations** Restart Management**: Batched restarts (every 10 generations) successfully balance configuration changes with overhead\n\nBelow is an actual configuration discovered by PBT on development hardware (format only - not claiming optimality):\n\n```\n{\n  \"shared_buffers\": 75984, // ~593 MB\n  \"effective_cache_size\": 87009, // ~679 MB\n  \"work_mem\": 6800, // ~53 MB\n  \"maintenance_work_mem\": 504084, // ~3.8 GB\n  \"random_page_cost\": 1.98, // SSD-friendly\n  \"effective_io_concurrency\": 156,\n  \"max_parallel_workers_per_gather\": 2,\n  \"checkpoint_completion_target\": 0.55,\n  \"checkpoint_timeout\": 439, // ~7 minutes\n  \"wal_buffers\": 272, // ~2 MB\n  \"default_statistics_target\": 2405,\n  \"max_connections\": 81,\n  \"max_worker_processes\": 6\n}\n```\n\nNote: Actual optimal configurations vary significantly based on hardware (CPU cores, RAM, storage type), workload characteristics (OLTP vs OLAP), and database size. The PBT system adapts to your specific environment.\n\nFuture work includes rigorous benchmarking:\n\n- Multiple hardware configurations (cloud and on-premise)\n- Diverse workload types (YCSB, TPC-C, real-world traces)\n- Comparison with more baseline tuning methods\n\nSee `results/`\n\ndirectory for optimization traces from your runs.\n\n**Advanced Features** like Workload prediction -- Query clustering for adaptive metric weighting**Cloud Deployment**: Kubernetes orchestration for multi-instance database, AWS RDS/Aurora integration** Multi-DBMS integration**: MySQL, MariaDB.\n\nThis is an **academic research project** under active development.\n\nFor academic collaborators:\n\n**Research Extensions**: Contact repository maintainers for collaboration** Bug Reports**: Open GitHub issues with reproduction steps** Documentation**: Improvements to docs always welcome\n\nFor external contributors:\n\n- Currently\n**not accepting pull requests** for core algorithm changes - Bug fixes and documentation PRs may be considered on case-by-case basis\n\nBe respectful, professional, and constructive. This is academic research—critiques should be evidence-based and cite relevant literature.\n\nPBTune is licensed under the [GNU General Public License v3.0](/alshawai/PBTune/blob/main/LICENSE).\n\nThis means you are free to use, modify, and distribute PBTune, provided that any derivative work is also released under GPL v3. All forks must remain open source.\n\nFor **commercial licensing inquiries**, contact: [Ibrahim Al-Shawa](mailto:contact.alshaw.ai@gmail.com)\n\nIf you use this work in academic research, please cite:\n\n```\n@software{pbtune2026,\n  title     = {PBTune: Population-Based Training for Automatic Database Parameter Tuning},\n  author    = {Al-Shawa, Ibrahim and Hedia, AbdelRahman and Darwish, Mahmoud and Saber, Walaa and El-Sayed, Emad},\n  year      = {2026},\n  url       = {https://github.com/alshawai/PBTune},\n  license   = {GPL-3.0}\n}\n```\n\nPBTune is described in a paper currently in preparation:\n\nPBTune: Population-Based Training for Automatic Database Parameter TuningIbrahim Al-Shawa, AbdelRahman Hedia, Mahmoud Darwish, Walaa Saber, Emad El-Sayed\n\nA preprint will be available soon.\n\n| Tool | Approach | Key Paper |\n|---|---|---|\n| PBTune | Evolutionary (PBT) | In preparation |\n| OtterTune | GP + Lasso + NN |\n|\n\n[Zhang et al., SIGMOD 2019](https://doi.org/10.1145/3299869.3300085)[Kanellis et al., VLDB 2022](https://doi.org/10.14778/3551793.3551844)[Lao et al., VLDB 2024](https://doi.org/10.14778/3659437.3659449)\n\nNote:Direct performance comparisons are omitted — these systems were evaluated on different hardware and workloads.\n\nPBTune was built by:\n\nWith contributions from:\n\n**Maintainer**: [Ibrahim Al-Shawa](https://github.com/alshawai)\n\n**Email**: [contact.alshaw.ai@gmail.com](mailto:contact.alshaw.ai@gmail.com)\n\n**Repository**: [https://github.com/alshawai/PBTune](https://github.com/alshawai/PBTune)\n\n**Issues**: [https://github.com/alshawai/PBTune/issues](https://github.com/alshawai/PBTune/issues)\n\n**Built with** 🧬 **Evolutionary Optimization** | 🛢 **Database Configuration** | 🐍 **Python**\n\n*Advancing the state-of-the-art in autonomous database systems*", "url": "https://wpnews.pro/news/show-hn-pbtune-evolutionary-auto-tuning-for-postgresql-no-ml-required", "canonical_source": "https://github.com/alshawai/PBTune", "published_at": "2026-07-28 13:10:55+00:00", "updated_at": "2026-07-28 13:22:17.399957+00:00", "lang": "en", "topics": ["artificial-intelligence", "machine-learning"], "entities": ["PBTune", "DeepMind", "PostgreSQL", "OtterTune", "CDBTune"], "alternates": {"html": "https://wpnews.pro/news/show-hn-pbtune-evolutionary-auto-tuning-for-postgresql-no-ml-required", "markdown": "https://wpnews.pro/news/show-hn-pbtune-evolutionary-auto-tuning-for-postgresql-no-ml-required.md", "text": "https://wpnews.pro/news/show-hn-pbtune-evolutionary-auto-tuning-for-postgresql-no-ml-required.txt", "jsonld": "https://wpnews.pro/news/show-hn-pbtune-evolutionary-auto-tuning-for-postgresql-no-ml-required.jsonld"}}