You can run a lot of business on a single 16GB VPS. Until you can’t. The failure mode is rarely “it crashed instantly.” It’s worse: it limps, then your app piles on more connections, then the database turns into a busy restaurant with one cook and 200 people waving credit cards.
This is where “MySQL vs MariaDB” stops being a bikeshed debate and becomes an operational decision: which one gives you the safer defaults, the clearer observability, and the least surprise when you add replication and connection pooling—because you will add replication and pooling if you care about uptime.
The 16GB VPS reality: you’re not capacity-rich
A 16GB VPS is the “mid-size sedan” of database hosting. It’s enough to feel confident. It’s also small enough that one wrong knob turns into a CPU-bound, I/O-starved, swap-happy incident with a side of “why is the load average 40?”
Here’s what you’re really buying with 16GB:
- Memory budget: not 16GB. The kernel, filesystem cache, your agent zoo, and the database itself all want a cut. Assume 12–13GB usable for MySQL/MariaDB processes before you risk swap and jitter.
- I/O ceiling: VPS “NVMe” often means “shared NVMe.” Latency spikes are not a bug; they’re a neighbor.
- CPU contention: even with dedicated vCPUs, noisy neighbors show up as steal time, scheduler delays, and unpredictable tail latency.
- Single host blast radius: kernel panic, filesystem corruption, provider maintenance, fat-fingered rm, and you’re offline.
On this box, replication and pooling aren’t performance “enhancements.” They’re the difference between a bad day and a career-limiting day.
Facts and history that still matter in production
Some context points are trivia until they bite you during an upgrade window.
- MariaDB forked from MySQL in 2009 after Oracle acquired Sun. That fork wasn’t just ideology; it shaped release cadence and defaults.
- MySQL 5.6/5.7 made InnoDB the undisputed center; the old MyISAM days are mostly history, but many legacy schemas still carry their assumptions.
- MariaDB kept different storage engines alive longer (and added more). That’s power and risk: more options means more ways to choose poorly.
- MySQL 8.0 removed the query cache entirely (it was a global mutex party). MariaDB kept a version of it longer, but it’s still rarely a good idea under concurrency.
- GTID implementations differ between MySQL and MariaDB. “GTID is on” is not the end of the conversation; it’s the start of compatibility questions.
- MySQL’s default authentication plugin changed (caching_sha2_password became common). Old clients and some proxies had feelings about that.
- MariaDB and MySQL diverged in optimizer behavior over time. Same SQL, different plan. On a VPS, plan regressions are expensive because you have no headroom to hide them.
- Replication has evolved from “best effort” to operational backbone: crash-safe replication metadata, multi-threaded appliers, semi-sync options. But you still need to test failover like you mean it.
MySQL vs MariaDB: how to choose on a VPS
Decision framing: operational guarantees, not feature checklists
On a 16GB VPS, you’re constrained by two things: latency and variance. Peak throughput matters less than consistent response time under load and safe recovery when things go sideways.
So pick the engine based on:
- Upgrade safety: how predictable are major/minor upgrades, and how well does your team understand them?
- Tooling compatibility: does your proxy, backup tooling, ORM, and monitoring stack behave sanely?
- Replication ergonomics: do you get clear replication status, easy re-seeding, and fewer edge-case surprises?
- Performance stability: does it avoid pathological stalls (metadata locks, flushing stalls, buffer pool thrash) under your workload?
MySQL: the “boring default” that’s boring for a reason
If you’re running a typical web workload (InnoDB tables, OLTP queries, some reporting), MySQL 8.0 is often the safe bet. It’s widely tested across ecosystems, proxies, drivers, and managed services. Operationally, that matters more than a shiny feature you’ll never deploy.
MySQL strengths on a VPS:
- Predictable ecosystem support: drivers, connectors, and cloud tooling tend to assume MySQL behavior first.
- Performance Schema maturity: excellent for diagnosing waits, locks, and top SQL without guessing.
- Replication “normality”: many failover tools and runbooks are written with MySQL semantics.
MariaDB: strong option, but treat compatibility as a project
MariaDB can be a great choice when you need its specific capabilities or your organization standardizes on it. But don’t treat it as “MySQL with a different logo.” The divergence is real, and on a small box the operational cost of surprises is amplified.
MariaDB strengths on a VPS:
- Different replication and clustering choices: MariaDB + Galera is a common pattern (with caveats), and MariaDB replication features can be attractive depending on version.
- Community velocity and packaging: some distros and vendors have strong MariaDB defaults and backports.
Opinionated call: If you’re starting fresh and your dependency graph is typical (web app + proxies + standard connectors), choose MySQL 8.0. If you’re already on MariaDB and stable, don’t migrate out of boredom—migrate because you have a clearly defined pain point and a tested path.
One reliability quote worth keeping on a sticky note
Werner Vogels: “Everything fails, all the time.” (paraphrased idea)
When connection pooling becomes mandatory (not “nice”)
On a 16GB VPS, your database server is not just running queries. It is also babysitting connections. Threads, memory per connection, context switches, authentication handshakes, TLS, and internal bookkeeping. This overhead is invisible right until it isn’t.
Pooling becomes mandatory when you see any of these patterns
- Connection storms: autoscaling app instances, cron bursts, deploys, or retries create spikes of hundreds/thousands of new connections in seconds.
- Many short queries: classic web OLTP where queries are fast but numerous; connection overhead becomes the bottleneck.
- High concurrency with small box limits: even if each query is cheap, the DB spends time scheduling rather than working.
- Tail latency sensitivity: you care about p95/p99, not average. New connection setup and thread scheduling makes tails ugly.
Here’s the blunt truth: if your app opens and closes connections per request, pooling is not optional. The database will eventually throttle you with CPU, mutex contention, or memory pressure. And it will do it at the least convenient time.
Joke #1: A database without pooling is like a nightclub with a bouncer who re-checks your ID every time you blink.
What “pooling” actually means in production
There are two layers:
- Application-level pooling (preferred baseline): your app maintains a stable pool of connections per instance. This is good, but it scales linearly with instance count.
- Network/proxy pooling (mandatory as you grow): a pooler/proxy like ProxySQL multiplexes many client sessions onto fewer server connections, applies routing rules, and protects the DB from storms.
Pool sizing on a 16GB VPS: stop thinking “max_connections = 2000”
High max_connections is not a badge of honor. It’s often a confession that you haven’t done pooling and you’re compensating with denial.
On 16GB, you generally want:
- Reasonable server connections: often in the low hundreds or less, depending on workload.
- Strict timeouts: kill idle clients before they become a resource leak.
- Backpressure: poolers that queue and shed load instead of letting the DB die.
When replication becomes mandatory (even if you hate complexity)
Replication is not just “for scaling reads.” On a single VPS, it’s primarily for survivability: backups, recovery time, maintenance, and testing. The first time your only database host fails and your restore takes hours, you’ll learn to love replicas.
Replication becomes mandatory when you need any of the following
- RPO < 1 hour without gambling on binlog backups and perfect restore procedures.
- Maintenance windows without downtime: OS patches, DB upgrades, storage migration.
- Backups that don’t crush production: take logical backups or run heavy reads against a replica.
- Safe experiments: test schema changes, query plans, index builds.
- Incident response sanity: you need a clean place to run forensic queries without fighting live traffic.
Replica on another VPS: the minimum viable architecture
For a 16GB primary, a common “grown-up” move is:
- Primary (16GB): accepts writes
- Replica (8–16GB): serves reads, runs backups, can be promoted
- Pooler/proxy (small VM or on app hosts): controls concurrency and routing
This is not glamorous. It is reliable. Like a fire extinguisher: boring until it’s everything.
Asynchronous vs semi-sync replication on a VPS
Asynchronous is the default: primary returns success before replica acknowledges. It’s fast, and it can lose the last few transactions on primary loss.
Semi-sync can reduce that risk by waiting for at least one replica acknowledgment before commit returns. On VPS networks with jitter, semi-sync can also amplify tail latency. Use it when you can tolerate the latency and you have a stable replica link; otherwise focus on good backups and fast failover.
Joke #2: Replication is like flossing: everyone swears they’ll start after the first emergency.
Fast diagnosis playbook: find the bottleneck quickly
When latency spikes or throughput collapses, don’t start by editing configs. Start by figuring out what the box is doing right now. This is the shortest path from panic to a correct decision.
First: is it CPU, memory, or I/O?
- CPU saturation / run queue: if CPU is pegged and load average is high, look for expensive queries, mutex waits, or too many threads.
- Memory pressure: if swapping or reclaim is happening, you’re not tuning; you’re drowning. Reduce memory footprint and connections, then revisit buffer sizing.
- I/O latency: if disk await time spikes, you can have plenty of CPU and still be “down.” InnoDB flush behavior, doublewrite, fsync frequency, and neighbor noise matter.
Second: is it too many connections or too few resources per connection?
- Check thread count, active connections, aborted connections.
- Check whether queries are blocked on locks or waiting on I/O.
- Look for connection storms after deploys and autoscaling events.
Third: is it query plan regression or schema/index debt?
- Identify top queries by total time and by p95 latency.
- Confirm index usage and row estimates.
- Check for missing composite indexes and accidental full scans.
Fourth: replication health (if you have it)
- Replica lag: seconds behind source, relay log growth.
- Applier threads stuck on a transaction, lock waits.
- Disk full on replica due to binlogs/relay logs.
Practical tasks: commands, outputs, and decisions
These are the real checks I run on a 16GB VPS when something feels off. Each includes a command, typical output, what it means, and what decision I make from it.
Task 1: Confirm memory pressure and swap activity
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 15Gi 12Gi 520Mi 310Mi 2.6Gi 1.8Gi
Swap: 2.0Gi 1.2Gi 820MiWhat it means: Swap is actively used. “Available” is small. Expect stalls, especially under write load.
Decision: Immediately reduce connection count and per-connection memory. If you’re using huge sort/join buffers, stop. Then right-size InnoDB buffer pool and implement pooling.
Task 2: Check CPU saturation and steal time
cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.1.0 (server) 12/31/2025 _x86_64_ (4 CPU)
12:00:01 AM CPU %usr %sys %iowait %steal %idle
12:00:02 AM all 72.4 10.8 1.2 8.6 7.0
12:00:03 AM all 70.1 11.2 0.9 9.3 8.5What it means: CPU is slammed and steal time is high. You’re competing for host CPU.
Decision: Reduce concurrency (pooling), cut max_connections, and prioritize query efficiency. Consider moving DB to a less contended plan or a dedicated CPU offering.
Task 3: Check disk latency quickly
cr0x@server:~$ iostat -x 1 3
Device r/s w/s rkB/s wkB/s await svctm %util
nvme0n1 35.2 210.7 2200.1 9800.4 18.40 0.52 96.8What it means: Disk is near saturated and average await is high. InnoDB will stall on fsync and flushing.
Decision: Investigate write amplification (binlogs, doublewrite, redo), check dirty page flushing, and reduce bursts (batching, transaction size). If this is shared-storage jitter, replication won’t fix it; better storage will.
Task 4: Confirm MySQL/MariaDB version and engine
cr0x@server:~$ mysql -e "SELECT VERSION() AS version, @@version_comment AS comment\G"
*************************** 1. row ***************************
version: 8.0.36
comment: MySQL Community Server - GPLWhat it means: Knowing the exact flavor and version determines which performance counters, replication status fields, and defaults apply.
Decision: Align troubleshooting steps to version. Don’t apply MariaDB-era advice to MySQL 8.0 blindly (and vice versa).
Task 5: Check connection pressure and thread usage
cr0x@server:~$ mysql -e "SHOW GLOBAL STATUS LIKE 'Threads_%'; SHOW VARIABLES LIKE 'max_connections';"
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_cached | 12 |
| Threads_connected | 385 |
| Threads_created | 98123 |
| Threads_running | 42 |
+-------------------+-------+
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 800 |
+-----------------+-------+What it means: Many created threads suggests churn. High connected threads on a small box is often overhead rather than useful work.
Decision: Enforce pooling. Lower max_connections. Set sane timeouts. If thread churn is high, check thread_cache_size and connection reuse.
Task 6: Identify top waits (MySQL Performance Schema)
cr0x@server:~$ mysql -e "SELECT event_name, COUNT_STAR, SUM_TIMER_WAIT/1000000000000 AS total_s
FROM performance_schema.events_waits_summary_global_by_event_name
WHERE event_name LIKE 'wait/io/file/innodb/%'
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 5;"
+----------------------------------------+------------+---------+
| event_name | COUNT_STAR | total_s |
+----------------------------------------+------------+---------+
| wait/io/file/innodb/innodb_log_file | 8421132 | 912.21 |
| wait/io/file/innodb/innodb_data_file | 20122341 | 311.45 |
| wait/io/file/innodb/innodb_temp_file | 1023311 | 88.17 |
+----------------------------------------+------------+---------+What it means: Heavy waits on log file imply fsync/log pressure. Data file waits suggest I/O-bound reads/writes.
Decision: If log waits dominate, review transaction size, durability settings, and redo log sizing. If data waits dominate, look at buffer pool hit rate and query plans.
Task 7: Check InnoDB buffer pool efficiency
cr0x@server:~$ mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';"
+---------------------------------------+-----------+
| Variable_name | Value |
+---------------------------------------+-----------+
| Innodb_buffer_pool_read_requests | 987654321 |
| Innodb_buffer_pool_reads | 12345678 |
+---------------------------------------+-----------+What it means: Reads vs read requests gives a rough cache miss ratio. Misses here are expensive on VPS storage.
Decision: If misses are high and memory is available, increase buffer pool. If memory is not available, fix queries/indexes and reduce working set.
Task 8: Find the worst queries by total time
cr0x@server:~$ mysql -e "SELECT DIGEST_TEXT, COUNT_STAR, ROUND(SUM_TIMER_WAIT/1e12,2) AS total_s, ROUND(AVG_TIMER_WAIT/1e9,2) AS avg_ms
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 3\G"
*************************** 1. row ***************************
DIGEST_TEXT: SELECT * FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT ?
COUNT_STAR: 1243321
total_s: 812.44
avg_ms: 0.65What it means: The query is cheap per call but dominates time due to volume. That’s a pooling and indexing story, not a “bigger server” story.
Decision: Ensure correct composite index (user_id, created_at). Consider caching at app layer. Add pooling to avoid connection overhead on high QPS.
Task 9: Spot lock contention quickly
cr0x@server:~$ mysql -e "SHOW ENGINE INNODB STATUS\G"
TRANSACTIONS
------------
Trx id counter 123456789
Purge done for trx's n:o < 123456700 undo n:o < 0 state: running
History list length 9821
LATEST DETECTED DEADLOCK
------------------------
*** (1) TRANSACTION:
... WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 123 page no 456 n bits 72 index PRIMARY of table `app`.`accounts` trx id 123456780 lock_mode X locks rec but not gap waitingWhat it means: Deadlocks and waits indicate conflicting writes or long transactions holding locks.
Decision: Shorten transactions, add proper indexes, and make updates deterministic. If an ORM is doing “select then update” patterns, fix it.
Task 10: Check replication status (MySQL)
cr0x@replica:~$ mysql -e "SHOW REPLICA STATUS\G"
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 4
Last_SQL_Error:What it means: Healthy replication with small lag.
Decision: You can safely offload reads/backups. If lag grows, stop pushing heavy reads to it and check applier/IO bottlenecks.
Task 11: Confirm binlog retention and disk pressure
cr0x@server:~$ mysql -e "SHOW BINARY LOGS;"
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| binlog.000231 | 1073741824|
| binlog.000232 | 1073741824|
| binlog.000233 | 1073741824|
+------------------+-----------+What it means: Binlogs are large and numerous. On a VPS disk, binlogs can quietly eat your root filesystem and turn a good week into a reboot loop.
Decision: Set explicit retention (expire settings), monitor filesystem usage, and ensure replicas are not preventing purges due to being offline.
Task 12: Check filesystem capacity and inode exhaustion
cr0x@server:~$ df -h /var/lib/mysql
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 200G 186G 14G 94% /What it means: You’re close to full. MySQL will misbehave long before 100% because it needs scratch space for temp tables, logs, and crash recovery.
Decision: Free space now. Purge old logs, move backups off-host, increase disk, or reduce retention. If you’re at 94% during business hours, you’re already late.
Task 13: Check for temp table pressure (memory vs disk)
cr0x@server:~$ mysql -e "SHOW GLOBAL STATUS LIKE 'Created_tmp%tables';"
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Created_tmp_disk_tables | 842113 |
| Created_tmp_tables | 902331 |
+-------------------------+----------+What it means: A high ratio of tmp disk tables means queries are spilling to disk. On a VPS, that’s a latency tax.
Decision: Add indexes, reduce result set size, fix GROUP BY/ORDER BY patterns, and avoid huge sorts. Don’t “solve” it by blindly inflating tmp_table_size until you hit OOM.
Task 14: Check table/index sizes to understand your working set
cr0x@server:~$ mysql -e "SELECT table_schema, table_name,
ROUND((data_length+index_length)/1024/1024,1) AS mb
FROM information_schema.tables
WHERE table_schema='app'
ORDER BY (data_length+index_length) DESC
LIMIT 5;"
+-------------+----------------+------+
| table_schema| table_name | mb |
+-------------+----------------+------+
| app | events | 8420 |
| app | orders | 3120 |
| app | users | 980 |
+-------------+----------------+------+What it means: Your biggest tables define your buffer pool needs. If the hot set can’t fit, you’ll pay I/O forever.
Decision: Partition/archive cold data, add summary tables, or move analytics elsewhere. Scaling “up” won’t fix a perpetually growing working set on a single VPS.
Three corporate mini-stories from the trenches
Mini-story 1: The incident caused by a wrong assumption
They ran a SaaS app on a single 16GB VM. It worked for months. A new integration went live, and the team assumed “the database can handle more connections; it’s just a config value.” They raised max_connections and moved on.
The next Monday, traffic spiked. The app opened new connections per request because the connection pool was misconfigured and effectively disabled. The database accepted the connections, because of course it did. It also created threads, allocated per-connection buffers, and started context-switching like a caffeinated hummingbird.
Latency climbed. The app retried. That created more connections. The OS started swapping. Now every query had the special seasoning of memory page faults. Engineers stared at CPU graphs and wondered why “adding more connections” didn’t add more throughput.
What fixed it wasn’t hero tuning. They enforced pooling, cut max_connections to a value the machine could actually honor, and added a small proxy layer to absorb bursts. Replication came next—not for reads, but so they could take backups without dragging production through molasses.
Mini-story 2: The optimization that backfired
A different company had slow report queries. Someone decided the best fix was bigger temporary table settings and more memory for sorts. They raised session and global buffers aggressively: sort buffers, join buffers, temp table sizes. The reports improved in staging. Everyone high-fived and shipped it.
Production didn’t fail immediately. It failed politely. Under concurrency, each connection could allocate big chunks of memory. Hundreds of connections times “reasonable” per-connection buffers becomes “surprise, you’re out of RAM.” The box started swapping. Then the database hit a wall of stalls: disk I/O spiked, fsyncs queued, and response time went asymptotic.
The team chased ghosts: network? provider? kernel? In reality, they had turned a controlled memory budget into a per-connection roulette wheel.
The rollback was humbling: reduce per-connection buffers, use proper indexes, rewrite the report queries, and move heavy reporting to a replica. They also learned a valuable lesson: on small hosts, predictable resource limits beat “fast when alone” every time.
Mini-story 3: The boring but correct practice that saved the day
A third team ran MySQL with a replica in another region. Nothing fancy: asynchronous replication, daily logical backups, and a weekly restore test. No one bragged about it in meetings because it was too dull to impress anyone.
Then their primary VPS had a storage incident. The filesystem went read-only mid-day. The database did what databases do under that condition: it complained, stopped making progress, and left everyone with a choice between downtime and bad choices.
They didn’t panic-tune. They promoted the replica using their practiced runbook, flipped the application to the new primary through the pooler, and took the old primary out of rotation. Service degraded briefly; it did not collapse. Later, they rebuilt the old node from scratch and re-seeded it cleanly.
The key detail: they had rehearsed. The boring restore test meant they knew the replica was usable, the credentials worked, and the app could point somewhere else without a three-hour config archaeology expedition.
Common mistakes: symptom → root cause → fix
This is where most 16GB VPS database deployments die: not from one big bug, but from a handful of common operational misunderstandings.
1) Symptom: sudden spike in latency after deploy
Root cause: connection storm (new app pods start, each opens a pool; or pooling disabled and connections per request).
Fix: enforce pooling, cap concurrency at the proxy, set wait_timeout/interactive_timeout appropriately, and keep max_connections realistic. If using ProxySQL, configure multiplexing carefully and test with your transaction patterns.
2) Symptom: CPU high, QPS flat, “Threads_running” high
Root cause: too many concurrent queries, lock contention, or query plan regression causing expensive scans.
Fix: identify top digests, add indexes, reduce concurrency via pooling, and fix long transactions. Don’t “solve” it by raising CPU limits before you know why threads are running.
3) Symptom: load average huge, but CPU not fully used
Root cause: I/O wait or blocked threads (fsync pressure, disk jitter, metadata locks).
Fix: use iostat -x, check Performance Schema waits, and look for long DDL or backup operations on primary. Move backups and heavy reads to replica.
4) Symptom: replica lag increases steadily during peak
Root cause: replica I/O bottleneck, applier single-thread bottleneck, or heavy reads starving replication.
Fix: increase replica resources or reduce its read load; tune parallel replication where applicable; ensure relay logs and disk aren’t saturated; avoid running massive reports on the same replica used for failover.
5) Symptom: “Too many connections” errors even though the server seems idle
Root cause: connection leaks or long-lived idle transactions pinning connections; pool exhaustion; max_connections too low for real concurrency pattern.
Fix: find the client causing leaks, enforce timeouts, and put a proxy in front to queue. Raise max_connections only after you’ve bounded per-connection memory and stabilized pooling.
6) Symptom: periodic stalls every few minutes
Root cause: checkpointing or flushing stalls, temp table spills, or background jobs doing bursts.
Fix: smooth the write workload, check dirty page behavior, avoid huge transactions, and schedule batch jobs. On VPS storage, large bursts are punished with latency spikes.
Checklists / step-by-step plan
Step-by-step: make pooling real on a 16GB VPS
- Inventory clients: list all services/jobs that connect to DB (app, workers, cron, BI tools).
- Fix app pooling first: set explicit pool size, max lifetime, and idle timeout. Avoid “unbounded pools.”
- Put a proxy/pooler in front when you have multiple app nodes or unpredictable bursts.
- Set server max_connections to a number the host can afford. This is a safety fuse, not a throughput dial.
- Set timeouts to kill idle connections and stuck sessions.
- Monitor Threads_created, Threads_connected, aborted connects. You want stable, boring graphs.
Step-by-step: add replication without turning it into a hobby
- Pick topology: one primary + one replica is the baseline. Keep it simple.
- Provision replica on separate failure domain: different VPS host, ideally different provider zone.
- Enable binary logging and set retention appropriate to your recovery needs and disk size.
- Seed replica correctly: use a consistent snapshot method (physical backup tool or logical dump with proper locking/GTID semantics).
- Verify replication health and alert on lag and errors.
- Write and rehearse promotion steps. Rehearse again when you upgrade versions.
- Move backups and heavy reads to replica. Keep failover replica clean and not overloaded.
Step-by-step: tune InnoDB for a 16GB VPS without self-harm
- Right-size buffer pool based on memory headroom and working set. Don’t starve the OS cache completely.
- Keep per-connection buffers modest. Global buffers are safer than per-connection surprises.
- Watch temp table spills and fix queries before inflating memory limits.
- Confirm durability settings match business requirements. Don’t cargo-cult unsafe settings just to win benchmarks.
- Measure, change one thing, measure again. “Tuning” by editing 30 parameters is how you create mysteries.
FAQ
1) Should I pick MySQL or MariaDB for a single 16GB VPS?
If you’re greenfield and want the smoothest ecosystem support, pick MySQL 8.0. If you’re already stable on MariaDB, stay unless you have a concrete compatibility or operational reason to migrate.
2) When is connection pooling truly mandatory?
When you have bursts, many app instances, or short queries at high QPS. If you see thread churn (Threads_created climbing fast) or connection storms during deploys, it’s past mandatory.
3) Can I just increase max_connections instead of pooling?
You can, the same way you can remove a smoke alarm because it’s loud. Higher max_connections often increases memory usage and context switching, making outages worse.
4) Is replication only for read scaling?
No. On a VPS, replication is primarily for recovery, backups, and maintenance. Read scaling is a nice side effect, not the main justification.
5) Async replication is risky. Should I use semi-sync?
Maybe. Semi-sync can reduce data loss on primary failure, but on VPS networks it can also add tail latency. Decide based on RPO tolerance and network stability, then test under load.
6) Why does my replica lag when I run reports?
Because reads compete with the replication applier for CPU and I/O. If the replica is your failover target, keep heavy reporting off it or provision a separate analytics replica.
7) What’s the first metric to watch on a small DB host?
Disk latency (iostat await / utilization) and memory pressure (swap activity). CPU graphs lie when the real bottleneck is I/O wait or swapping.
8) Is Galera (MariaDB) a good idea on VPS instances?
It can work, but it’s not a free lunch. Synchronous-ish write coordination can punish latency, and split-brain risks increase if you don’t design quorum properly. If you’re not prepared to operate a cluster, prefer primary+replica first.
9) Do I need a proxy like ProxySQL if my app already pools connections?
Not always, but often. App pooling alone still scales server connections with the number of app instances. A proxy adds backpressure, routing, multiplexing, and protection against storms.
10) What’s the fastest safe improvement I can make this month?
Add a replica for backups and rehearsed failover, and implement connection pooling with strict limits. Those two changes prevent the most common “single VPS melted” incidents.
Conclusion: what to do next week
If you’re on a 16GB VPS, you don’t have the luxury of sloppy concurrency. You also don’t have the luxury of “we’ll add replication later.” Later is when you’re restoring from backups while your CEO learns new vocabulary.
Practical next steps:
- Implement pooling (app-level immediately; add a proxy if you have multiple app nodes or bursty traffic).
- Set realistic connection limits and timeouts; treat max_connections as a circuit breaker.
- Add a replica on a separate VPS and move backups/reporting there.
- Write a failover runbook and rehearse it during business hours with guardrails.
- Run the fast diagnosis playbook during your next latency blip and document what you learned.
MySQL vs MariaDB won’t save you by itself. Replication and pooling will. Pick the database that your team can operate calmly at 2 a.m., and then engineer the system so 2 a.m. stays boring.