Linux VPS Database Performance Benchmarking Tutorial: Complete MySQL vs PostgreSQL vs MariaDB Testing with sysbench in 2026

Why Database Performance Benchmarking Matters for VPS Hosting

Your VPS database performance directly impacts user experience and server costs. When hosting multiple applications or serving thousands of concurrent users, knowing which database engine performs best under your specific workload saves both money and headaches.

Database performance benchmarking reveals bottlenecks before they affect production. You'll discover whether your current configuration handles peak traffic. You'll also learn which engine suits your application architecture and where to focus optimization efforts.

This tutorial walks through comprehensive benchmarking of MySQL 8.0, PostgreSQL 16, and MariaDB 11.6 on Ubuntu 24.04 VPS instances. We'll use sysbench for standardized testing and analyze results across different workload patterns.

Prerequisites and Environment Setup

Start with a clean Ubuntu 24.04 VPS with at least 4GB RAM and 2 CPU cores. HostMyCode VPS instances provide consistent performance baselines perfect for benchmarking.

Update your system first:

sudo apt update && sudo apt upgrade -y
sudo reboot

Install sysbench, our primary benchmarking tool:

sudo apt install sysbench -y
sysbench --version

You should see sysbench 1.0.20 or later. This version includes improved OLTP workloads and better statistical reporting.

MySQL 8.0 Installation and Configuration

Install MySQL server with optimized settings for benchmarking:

sudo apt install mysql-server -y
sudo systemctl start mysql
sudo systemctl enable mysql

Secure the installation and create a benchmark database:

sudo mysql_secure_installation
sudo mysql -e "CREATE DATABASE sbtest;"
sudo mysql -e "CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'password';"
sudo mysql -e "GRANT ALL ON sbtest.* TO 'sbtest'@'localhost';"

Configure MySQL for optimal benchmarking performance by editing `/etc/mysql/mysql.conf.d/mysqld.cnf`:

[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 1
innodb_file_per_table = 1
max_connections = 200
tmp_table_size = 64M
max_heap_table_size = 64M
query_cache_size = 0
query_cache_type = 0

Restart MySQL to apply changes:

sudo systemctl restart mysql

PostgreSQL 16 Installation and Configuration

Install PostgreSQL from the official APT repository:

sudo apt install postgresql postgresql-contrib -y
sudo systemctl start postgresql
sudo systemctl enable postgresql

Create the benchmark database and user:

sudo -u postgres psql -c "CREATE DATABASE sbtest;"
sudo -u postgres psql -c "CREATE USER sbtest WITH PASSWORD 'password';"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE sbtest TO sbtest;"

Configure PostgreSQL for benchmarking by editing `/etc/postgresql/16/main/postgresql.conf`:

shared_buffers = 2GB
effective_cache_size = 3GB
work_mem = 64MB
maintenance_work_mem = 256MB
wal_buffers = 16MB
checkpoint_completion_target = 0.9
max_connections = 200

Restart PostgreSQL:

sudo systemctl restart postgresql

MariaDB 11.6 Installation and Configuration

Add the MariaDB repository for the latest version:

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
sudo apt update
sudo apt install mariadb-server -y

Start MariaDB and create the benchmark database:

sudo systemctl start mariadb
sudo systemctl enable mariadb
sudo mysql_secure_installation

Create the test database and user:

sudo mysql -e "CREATE DATABASE sbtest;"
sudo mysql -e "CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'password';"
sudo mysql -e "GRANT ALL ON sbtest.* TO 'sbtest'@'localhost';"

Configure MariaDB in `/etc/mysql/mariadb.conf.d/50-server.cnf`:

[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 1
max_connections = 200
tmp_table_size = 64M
max_heap_table_size = 64M
query_cache_size = 0
query_cache_type = 0

Restart MariaDB to apply the configuration:

sudo systemctl restart mariadb

Preparing Benchmark Data

Create consistent test datasets for all three databases. We'll use sysbench's OLTP workload with 10 tables and 100,000 rows each.

For MySQL and MariaDB:

sysbench oltp_read_write \
  --mysql-host=localhost \
  --mysql-user=sbtest \
  --mysql-password=password \
  --mysql-db=sbtest \
  --tables=10 \
  --table-size=100000 \
  prepare

For PostgreSQL:

sysbench oltp_read_write \
  --pgsql-host=localhost \
  --pgsql-user=sbtest \
  --pgsql-password=password \
  --pgsql-db=sbtest \
  --tables=10 \
  --table-size=100000 \
  prepare

Data preparation takes 5-10 minutes depending on your VPS specs. Monitor system resources during this process to establish baseline metrics.

Running Read-Heavy Workload Tests

Test read performance first, as most web applications perform more reads than writes. Run each test three times and average the results for consistency.

MySQL read-only test:

sysbench oltp_read_only \
  --mysql-host=localhost \
  --mysql-user=sbtest \
  --mysql-password=password \
  --mysql-db=sbtest \
  --tables=10 \
  --table-size=100000 \
  --threads=16 \
  --time=300 \
  --report-interval=10 \
  run

PostgreSQL read-only test:

sysbench oltp_read_only \
  --pgsql-host=localhost \
  --pgsql-user=sbtest \
  --pgsql-password=password \
  --pgsql-db=sbtest \
  --tables=10 \
  --table-size=100000 \
  --threads=16 \
  --time=300 \
  --report-interval=10 \
  run

MariaDB read-only test follows the same MySQL syntax. Record the queries per second (QPS) and 95th percentile latency from each test.

On a typical 4GB VPS, PostgreSQL leads in complex query scenarios. MySQL and MariaDB excel in simple SELECT operations.

Write-Heavy Workload Benchmarking

Write performance reveals how each database handles INSERT, UPDATE, and DELETE operations under load.

Run write-only tests with the same parameters:

sysbench oltp_write_only \
  --mysql-host=localhost \
  --mysql-user=sbtest \
  --mysql-password=password \
  --mysql-db=sbtest \
  --tables=10 \
  --table-size=100000 \
  --threads=16 \
  --time=300 \
  run

Write workloads stress the storage subsystem and transaction log. Monitor disk I/O patterns during these tests to identify bottlenecks.

PostgreSQL typically shows higher write throughput for complex transactions. MySQL variants perform better for simple INSERT operations.

Mixed Workload Performance Analysis

Real applications combine reads and writes. Test mixed workloads that simulate production traffic patterns:

sysbench oltp_read_write \
  --mysql-host=localhost \
  --mysql-user=sbtest \
  --mysql-password=password \
  --mysql-db=sbtest \
  --tables=10 \
  --table-size=100000 \
  --threads=32 \
  --time=600 \
  --report-interval=30 \
  run

Mixed workload tests reveal transaction handling efficiency. Pay attention to deadlock frequency and lock contention, especially under high concurrency.

Record metrics for different thread counts: 1, 8, 16, 32, and 64 threads. This shows how each database scales with concurrent connections.

Custom Workload Testing

Create application-specific tests that match your actual usage patterns. If you're running WordPress, test scenarios with typical plugin queries.

Create a custom Lua script for WordPress-like workloads:

-- wordpress_simulation.lua
function thread_init()
  drv = sysbench.sql.driver()
  con = drv:connect()
end

function event()
  local post_id = sysbench.rand.uniform(1, 10000)
  local user_id = sysbench.rand.uniform(1, 1000)
  
  con:query("SELECT * FROM wp_posts WHERE ID = " .. post_id)
  con:query("SELECT * FROM wp_comments WHERE post_id = " .. post_id)
  con:query("UPDATE wp_posts SET post_views = post_views + 1 WHERE ID = " .. post_id)
end

Run custom tests to see which database handles your specific query patterns most efficiently.

Database Performance Benchmarking Results Analysis

Compare key metrics across all databases:

Queries per second (QPS)
95th percentile latency
CPU utilization during peak load
Memory usage patterns
Disk I/O operations per second

Create a results comparison table:

Database    | Read QPS | Write QPS | Mixed QPS | 95% Latency
MySQL 8.0   | 12,450   | 3,240     | 8,650     | 18.2ms
PostgreSQL  | 11,890   | 4,100     | 9,120     | 16.8ms
MariaDB     | 12,680   | 3,180     | 8,520     | 19.1ms

Results vary significantly based on workload characteristics. PostgreSQL often wins in complex analytical queries. MySQL variants excel in simple OLTP scenarios.

Performance Optimization Based on Results

Use benchmark results to guide optimization efforts. If MySQL shows high latency, increase the buffer pool size. If PostgreSQL has low write throughput, adjust WAL settings.

Common optimizations after benchmarking:

Increase buffer pool sizes for memory-bound workloads
Adjust log file sizes for write-heavy applications
Optimize connection pooling for high-concurrency scenarios
Configure appropriate indexes based on query patterns

Re-run benchmarks after each optimization to measure improvements. Systematic query analysis complements raw performance metrics.

Monitoring Production Performance

Establish ongoing monitoring based on benchmark baselines. Set alerts when production metrics fall below benchmark performance levels.

Key monitoring points include:

Query response times
Connection pool utilization
Buffer cache hit ratios
Replication lag for clustered setups

Comprehensive database monitoring ensures production performance matches benchmark expectations.

Ready to deploy your optimized database setup? HostMyCode managed VPS hosting provides pre-tuned database configurations and 24/7 performance monitoring. Our team handles optimization while you focus on application development.

Frequently Asked Questions

How often should I run database performance benchmarks?

Benchmark after major configuration changes, software updates, or when adding significant load. Monthly benchmarks help track performance trends over time.

Can I benchmark databases on shared hosting?

Shared hosting limits make reliable benchmarking impossible. VPS or dedicated servers provide consistent resources needed for accurate testing.

Which database performs best for WordPress hosting?

MySQL and MariaDB typically perform better for WordPress due to optimized plugin compatibility and caching mechanisms. PostgreSQL offers advantages for complex custom applications.

How do I benchmark database replication performance?

Test replication lag under load by measuring time differences between master and replica commits. Database replication setups require specialized testing approaches.

Should benchmark results influence database selection?

Performance is one factor among many. Consider application compatibility, development team expertise, and long-term maintenance requirements alongside benchmark results.