Comparing native host deployments against containerized environments reveals specific overhead patterns in relational database transactions. The following benchmark isolates resource allocation differences between a host-resident MySQL binary and an official Docker image to quantify throughput reduction and latency elevation under mixed OLTP conditions.

Test Environment Specifications

Component	Specification	Notes
OS	Debian 12	4 vCPU, 16 GB RAM
Runtime	Docker Engine 20.10.17	Standard cgroup configuration
Database (Host)	MySQL 8.0.34	Official Linux generic package
Database (Container)	MySQL 8.0.34	Pull-based mysql repository image
Benchmark Tool	Sysbench 1.0.20	Remote client execution

Sequential testing prevents concurrent resource contention. The client targets the database endpoint at 192.168.3.21.

Configuration Parameters Identical InnoDB tuning applies across both setups, with innodb_buffer_pool_size=2G. The containerized variant utilizes the default bridge network mode and maps a persistent volume to /var/lib/mysql to bypass the overlay filesystem for data files.

Benchmark Execution Workflow The workload simulates mixed read/write operations using Sysbench. The test sequence is encapsulated below for reproducibility:

# Define connection parameters
DB_HOST="192.168.3.21"
DB_PORT="3306"
DB_USER="benchmark_user"
DB_PASS="secure_test_pass_123"
DB_NAME="sbtest_db"

# Table generation phase
sysbench \
  --db-driver=mysql \
  --mysql-host=$DB_HOST \
  --mysql-port=$DB_PORT \
  --mysql-user=$DB_USER \
  --mysql-password=$DB_PASS \
  --mysql-db=$DB_NAME \
  --table_size=10000000 \
  --tables=20 \
  --threads=4 \
  oltp_read_write prepare

# Stress testing phase (5-minute duration)
sysbench \
  --db-driver=mysql \
  --mysql-host=$DB_HOST \
  --mysql-port=$DB_PORT \
  --mysql-user=$DB_USER \
  --mysql-password=$DB_PASS \
  --mysql-db=$DB_NAME \
  --time=300 \
  --threads=8 \
  --report-interval=10 \
  oltp_read_write run

# Resource deallocation
sysbench \
  --db-driver=mysql \
  --mysql-host=$DB_HOST \
  --mysql-port=$DB_PORT \
  --mysql-user=$DB_USER \
  --mysql-password=$DB_PASS \
  --mysql-db=$DB_NAME \
  --table_size=10000000 \
  --tables=20 \
  --threads=4 \
  oltp_read_write cleanup

Quantitative Results The dataset consists of 20 tables holding 10 million rows each. Four independent runs were conducted per deployment model to establish statistical baselines.

Individual Run Metrics

Deployment Model	Iteration	Total Queries	QPS	TPS	Avg Latency (ms)	P95 Latency (ms)
Host Binary	1	3,798,093	12,658.84	632.78	12.64	20.00
Host Binary	2	3,914,578	13,047.91	652.28	12.26	17.01
Host Binary	3	4,059,867	13,531.79	676.46	11.82	15.55
Host Binary	4	3,772,390	12,574.00	628.58	12.72	19.65
Docker Image	1	3,230,678	10,768.41	538.28	14.86	26.20
Docker Image	2	3,538,573	11,794.68	589.62	13.57	19.29
Docker Image	3	3,567,943	11,892.56	594.50	13.45	17.63
Docker Image	4	3,616,204	12,053.53	602.58	13.27	17.32

Aggregated Performance Delta

Metric	Host Binary Avg	Docker Image Avg	Deviation
Total Queries	3,886,232	3,488,350	-10.24%
Queries/sec	12,953.14	11,627.30	-10.24%
Transactions/sec	647.53	581.25	-10.24%
Avg Latency	12.36 ms	13.79 ms	+11.57%
P95 Latency	18.05 ms	20.11 ms	+11.41%

Previous iterations utilizing sub-million row distributions demonstrated minimal throughput divergence between both deployment strategies. As dataset growth pushes memory management and I/O scheduling limits, the abstraction layer introduces measurable serilaization costs. At the ten-million-row threshold, the containerized environment exhibits roughly an eleven percent reduction in transactional velocity alongside corresponding latency elevation. Scaling beyond this boundary typically amplifies the overhead proportionally due to increased context-switching frequency and virtual filesystem translation demands.