Self-Hosted Database Configuration Tuning: MySQLTuner vs pgTune vs pgtune-ng (2026)

Database performance tuning is one of the most impactful yet often overlooked aspects of self-hosted infrastructure. A database running with default configuration parameters typically uses only a fraction of available CPU, memory, and I/O resources. Proper tuning can improve query throughput by 2-10x and reduce latency dramatically.

While commercial database platforms offer automated tuning advisors, the self-hosted ecosystem provides several free, open-source tools that analyze your workload and recommend optimal configuration settings. This guide compares three widely-used database tuning tools: MySQLTuner for MySQL and MariaDB optimization, pgTune for PostgreSQL configuration, and pgtune-ng as a modern PostgreSQL tuning alternative.

The Database Tuning Problem

When you install MySQL or PostgreSQL from package repositories, the default configuration is conservative — designed to run on minimal hardware without crashing. This means:

• InnoDB buffer pool defaults to 128 MB on a server with 32 GB of RAM
• Shared buffers in PostgreSQL may be set to 128 MB regardless of available memory
• Connection limits are often set too low for production workloads
• WAL and checkpoint settings are not tuned for your I/O subsystem
• Query cache and sort buffer sizes are not optimized for your query patterns

These defaults are safe but wasteful. A properly tuned database uses available hardware resources efficiently, reducing the need for expensive hardware upgrades. The tuning tools covered in this guide analyze your current configuration, server resources, and workload patterns to generate optimized parameter recommendations.

MySQLTuner: MySQL and MariaDB Performance Advisor

MySQLTuner is the most popular database tuning script for MySQL, MariaDB, and Percona Server. Written in Perl and maintained since 2006, it has accumulated over 9,400 GitHub stars and remains actively developed. The script connects to a running MySQL server, analyzes runtime statistics, and produces a detailed report with specific configuration recommendations.

Key Features

• Comprehensive analysis: Examines 300+ configuration variables and runtime metrics
• Multi-engine support: Works with MySQL, MariaDB, Percona Server, and Galera Cluster
• Security audit: Checks for weak passwords, anonymous users, and insecure configurations
• Performance metrics: Reports on query cache efficiency, InnoDB buffer pool hit rate, and temporary table usage
• Actionable recommendations: Each suggestion includes the current value, recommended value, and explanation
• Tuning primer mode: Historical performance analysis over the server’s uptime period
• JSON output: Machine-readable results for integration with monitoring pipelines

Installation and Usage

MySQLTuner is a single Perl script — no server component needed. Install it directly from the repository:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Install via package manager
sudo apt install mysqltuner    # Debian/Ubuntu
sudo yum install mysqltuner    # RHEL/CentOS

# Or download the latest version directly
curl -LO https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
chmod +x mysqltuner.pl

# Run against a local MySQL server
./mysqltuner.pl --host localhost --user root --pass yourpassword

# Run with full diagnostic output
./mysqltuner.pl --verbose --bannedports --passwordfile=/etc/mysql/.my.cnf

Sample Output Analysis

MySQLTuner produces a structured report divided into sections:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

[OK] Currently running supported MySQL version 8.0.36
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics ---------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in InnoDB tables: 12.4G (Tables: 342)
[--] Data in MyISAM tables: 1.2G (Tables: 89)

-------- Performance Metrics -------------------------------
[!!] Maximum reached memory usage: 14.2G (44.3% of installed RAM)
[!!] Maximum possible memory usage: 28.6G (89.4% of installed RAM)
[OK] Overall possible memory usage with other process exceeded physical memory

-------- Recommendations -------------------------------------
General recommendations:
  * MySQL was started within the last 24 hours - calculations may be inaccurate
  * innodb_buffer_pool_size (>= 16G) if possible
  * innodb_log_file_size should be (= 2G)
  * tmp_table_size (> 64M)
  * max_heap_table_size (> 64M)
  * thread_cache_size should be set to 16
  * table_open_cache should be set to 4000

Configuration Recommendations

pgTune: PostgreSQL Configuration Generator

pgTune is a PostgreSQL configuration tuning tool that generates optimized postgresql.conf settings based on your server’s hardware specifications and workload type. Unlike MySQLTuner’s runtime analysis approach, pgTune uses a formula-based calculation that considers total RAM, CPU cores, storage type, and application profile to produce a complete configuration file.

Key Features

• Hardware-aware tuning: Calculates optimal settings based on RAM, CPU, and disk type
• Workload profiles: Supports web applications, online transaction processing, data warehousing, and desktop usage patterns
• PostgreSQL version support: Generates compatible settings for PostgreSQL 9.6 through 17
• Web interface: Browser-based tool at pgtune.leopard.in.ua for quick configuration generation
• CLI mode: Command-line interface for automated configuration in infrastructure pipelines
• Conservative defaults: Recommendations stay within safe bounds to prevent misconfiguration
• Complete config output: Generates a full postgresql.conf snippet ready to apply

Web Interface Usage

The pgTune web interface is the simplest way to generate a configuration:

1. Navigate to the pgTune web application
2. Enter your DB Version (e.g., PostgreSQL 16)
3. Enter Total Memory (e.g., 32 GB)
4. Enter Number of CPUs (e.g., 8)
5. Select Type of application (Web, OLTP, DWH, Desktop, Mixed)
6. Select Type of storage (HDD, SSD, SAN)
7. Click “Generate” to receive optimized settings

Docker Deployment for Self-Hosted pgTune

For teams that want to self-host the pgTune web interface:

1
2
3
4
5
6
7
8

services:
  pgtune:
    image: le0pard/pgtune:latest
    ports:
      - "8080:80"
    environment:
      - TZ=UTC
    restart: unless-stopped

Alternatively, run pgTune locally using Docker:

1

docker run --rm -p 8080:80 le0pard/pgtune:latest

Access the web interface at http://localhost:8080.

Generated Configuration Example

For a server with 32 GB RAM, 8 CPU cores, SSD storage, and OLTP workload:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# Generated by pgTune for PostgreSQL 16
# Hardware: 32 GB RAM, 8 CPU cores, SSD storage
# Workload: Online Transaction Processing (OLTP)

max_connections = 200
shared_buffers = 8GB
effective_cache_size = 24GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 20MB
huge_pages = off
min_wal_size = 2GB
max_wal_size = 8GB
max_worker_processes = 8
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_parallel_maintenance_workers = 4

pgtune-ng: Modern PostgreSQL Tuning

pgtune-ng is the actively maintained successor to the original pgTune project. It provides the same formula-based configuration generation with improved PostgreSQL version support, a modern web interface, and additional tuning parameters that reflect the evolution of PostgreSQL’s optimizer and executor.

Key Features

• Latest PostgreSQL support: Covers PostgreSQL 15, 16, and 17 with version-specific parameters
• Enhanced work_mem calculation: Accounts for parallel query execution and complex sort operations
• WAL tuning: Optimized checkpoint and WAL settings for modern SSD and NVMe storage
• Parallel query support: Configures max_parallel_workers and related settings for multi-core systems
• Improved HDD/SSD detection: Better cost parameter estimation based on storage characteristics
• Open-source and self-hostable: Full source code available for running your own instance

When to Use Each Tool

Feature Comparison Table

Why Self-Host Database Tuning Tools?

Running database tuning tools on your own infrastructure keeps sensitive server metrics and configuration data private. MySQLTuner’s runtime analysis reveals detailed information about query patterns, table sizes, and user activity that you may not want to transmit to external services. Similarly, self-hosting pgTune means your hardware specifications and workload profiles stay within your network.

For compliance-regulated environments (healthcare, finance, government), self-hosted tuning tools eliminate the data transmission concern entirely. You can run MySQLTuner against production replicas and pgTune with your exact hardware specifications without exposing any operational details to third-party services.

When tuning databases that handle sensitive data, combine your tuning workflow with self-hosted database monitoring to track the impact of configuration changes over time. For PostgreSQL deployments, pairing tuned configuration with self-hosted high availability ensures both performance and resilience.

Applying Tuning Recommendations Safely

Never apply tuning recommendations directly to production without testing. The safe workflow is:

1. Run the tuning tool against a staging replica or during a maintenance window
2. Review recommendations carefully — understand what each parameter change does
3. Apply to staging first and monitor for 24-48 hours
4. Compare before/after metrics using your monitoring stack
5. Apply to production during a scheduled maintenance window
6. Monitor closely for the first few hours after applying changes

MySQLTuner explicitly warns that its recommendations are based on historical data and may not be accurate if the server has been running for less than 24 hours. Always let the server accumulate sufficient runtime statistics before trusting the analysis.

FAQ

How often should I run MySQLTuner against my database?

Run MySQLTuner at least once per week during the first month after any major configuration change, workload shift, or hardware upgrade. Once your database has been stable with consistent settings for several weeks, monthly checks are sufficient. MySQLTuner needs at least 24 hours of runtime for accurate recommendations — ideally 48-72 hours — so schedule it after your server has been up long enough to accumulate representative statistics.

Can pgTune replace a database administrator?

No. pgTune provides starting-point recommendations based on general formulas. A skilled database administrator considers workload-specific factors that no automated tool can fully capture — query patterns, index usage, replication topology, and business requirements. Use pgTune to establish a solid baseline configuration, then refine based on your actual workload characteristics and monitoring data.

What is the most important MySQL parameter to tune?

For most MySQL deployments, innodb_buffer_pool_size has the single largest impact on performance. This parameter controls how much RAM InnoDB uses to cache data and indexes. A common rule is to set it to 70-80 percent of available RAM on a dedicated database server. The second most impactful parameter is innodb_log_file_size, which affects write performance — larger log files reduce checkpoint frequency and improve write throughput.

Does MySQLTuner work with MySQL 8.0 and newer versions?

Yes. MySQLTuner supports MySQL 8.0, 8.1, and 8.4, as well as MariaDB 10.x and Percona Server. The script is regularly updated to handle new configuration variables and deprecations introduced in recent MySQL versions. Note that MySQL 8.0 removed the query cache, so MySQLTuner will recommend keeping query_cache_type disabled — this is correct behavior.

Should I use the pgTune web interface or self-host it?

The pgTune web interface does not send your configuration data anywhere — all calculations happen in the browser. However, self-hosting pgTune via Docker eliminates any dependency on an external service and gives you full control over availability. For air-gapped environments or organizations with strict data handling policies, self-hosting is the recommended approach.

Can I automate the application of tuning recommendations?

Both MySQLTuner and pgTune produce output that can be parsed and applied programmatically. MySQLTuner supports --outputfile to save results, and pgTune generates complete postgresql.conf snippets. However, automated application of tuning changes is risky — always review recommendations before applying. A safer approach is to generate a configuration diff, have it reviewed by a database administrator, and apply through your infrastructure-as-code pipeline with proper testing stages.