A slow database does not always throw an error. It shows up as pages that take two seconds to render and users hitting refresh. On a VPS, the bottleneck is rarely where people look first. Before you add RAM, it helps to understand what the disk, the memory and a handful of settings are actually doing to your queries: here is the order to measure in, what genuinely matters, and when a larger plan is the right answer.
Why the database sets perceived speed
In a business application, response time follows the same chain every time: a request arrives, the application queries the database, the engine fetches the pages it needs, and a result comes back. The CPU works in microseconds, the disk in milliseconds — that gap, repeated thousands of times an hour, separates a smooth interface from a painful one.
The consequence is simple: a well-tuned database on a small server often beats a badly tuned one on a machine twice the size. Hardware sets the ceiling; configuration decides how far below it you sit.
NVMe vs SATA: what actually changes for a database engine
What NVMe really buys you
A database engine does not read large files in one sweep. It reads 8 KB or 16 KB pages scattered across the volume, several at a time. That is the random-access profile — exactly where NVMe pulls furthest ahead of spinning disks and keeps an edge over SATA SSDs. Under a random read load, the difference shows up in queue depth long before it shows up in a throughput chart.
What NVMe will not fix
Fast storage does not cancel a badly written query: a full table scan, a missing index or a sort on an unindexed column stays slow. A volume filled to 95% also loses most of its advantage, because the controller has to manage wear and writes get reordered.
- Latency: what your application feels, query by query.
- Throughput: what matters for backups and restores.
- Queue depth and free space: the two signs of storage falling behind.
Working set versus RAM: the real tipping point
The working set is the set of pages a database actually touches in a working day: hot indexes, the most-read tables, a few heavily used rows. As long as it fits in available memory, the engine answers without going to disk; the moment it spills over, every query needs a physical read.
So measure the working set before you think in gigabytes. A 20 GB catalogue where 2 GB is read each day does not need 20 GB of memory; an 800 MB table read in full on every connection will swamp a 1 GB machine. Then watch the cache hit ratio: below 95%, memory is short before the CPU is.
The six settings that matter
Six parameters explain most of the gap between a slow database and a decent one. Change them in this order, one at a time.
Memory handed to the engine
shared_buffers on PostgreSQL, innodb_buffer_pool_size on MariaDB and MySQL: the engine's internal cache, the one that keeps hot pages close. A quarter of RAM is a sensible starting point for PostgreSQL; on a database-only server the InnoDB pool can go higher. Giving everything to the engine starves the operating system's file cache, which also does real work.
Sorts and connections
work_mem is paid per sort operation, not per query: a generous value multiplied by fifty concurrent connections can exhaust memory. effective_cache_size allocates nothing — it tells the planner what the system can keep cached. And max_connections belongs with a pool on the application side: ten well-used connections beat two hundred waiting in line.
Writes and durability
Durability settings — log synchronization, transaction log size, checkpoint frequency — trade safety for speed. Loosening them speeds up bulk inserts at the cost of losing the last transactions in an abrupt shutdown: an operations decision to document, not a snippet to copy.
Caching in front of the engine
The cheapest layer is often outside the database. An application cache for expensive results, full page caching for anonymous visitors and a CDN for static assets remove thousands of calls before they reach the server. A database twice as fast is less noticeable than a database you query half as often.
Measure before you tune
Tuning without a baseline is driving without a dashboard:
- Set a baseline: 95th percentile latency, queries per second, slowest page time, captured off-peak and at peak.
- Rank queries by total time with pg_stat_statements or performance_schema: not the single slowest query, but the one that eats the most time overall.
- Watch the disk: average I/O wait, utilization, queue length. Storage near saturation explains more slowdowns than a CPU at 60%.
- Check memory: reads served from cache, swap usage, real available memory rather than the theoretical figure.
- Change one setting, then re-measure under the same conditions: two changes at once and you learn nothing about either.
A common trap: comparing a reading taken during a reindex with one from a quiet Monday morning. Record the time, the load and the connection count with every sample.
Which VPS plan for which load
Sizing follows the working set and concurrent connections, not total database size. The table covers the four mid-range plans; the full price list is on the Open Vista pricing page.
| Plan | vCPU / RAM | NVMe | Typical database profile | USD / month | MAD excl. tax |
|---|---|---|---|---|---|
| VPS-2G Business | 1 vCPU / 2 GB | 40 GB | 1–1.5 GB working set, a few dozen connections | $19.99 | 189.06 |
| VPS-3G Performance | 2 vCPU / 3 GB | 50 GB | Database and app on one machine, moderate hot cache | $34.99 | 330.93 |
| VPS-4G Advanced | 2 vCPU / 4 GB | 80 GB | Dedicated database, 2–3 GB working set, steady writes | $39.99 | 378.22 |
| VPS-5G Ultra | 3 vCPU / 5 GB | 100 GB | Mixed read/write load, several databases or one large one | $49.99 | 472.80 |
Every plan includes a dedicated IPv4 address, unlimited bandwidth, root access, a management panel, automatic backups, a firewall with DDoS protection, 24/7 monitoring, six-day-a-week support and a 99.9% SLA on infrastructure. Servers run in a New York datacenter; a Rabat facility is announced but not yet open. Delivery takes under fifteen minutes, and moving to a larger plan needs no painful migration.
FAQ
Do I need more RAM or more vCPU for a slow database?
Start with the cache hit ratio and disk utilization. A cache ratio that will not climb and disk queues that keep growing point to memory and I/O, not the CPU. A CPU near saturation with a comfortable cache points to computation: look at indexes and queries before buying hardware.
Can the database and the application share one VPS?
Yes, and it is the most common setup well into the tens of thousands of monthly visits. Reserve engine memory carefully, cap connections and watch for spikes: an import job can eat the RAM the database needs. Two machines start to pay off when both workloads compete for the same resource at the same hours.
Is NVMe enough to make a database fast?
No. NVMe lowers the cost of random reads, which helps a lot when the working set exceeds RAM, but it does not compensate for a missing index or a badly placed sort. On a database whose working set fits in memory, a faster disk brings a modest gain: fix the queries first.
How do I know storage is the bottleneck?
Compare average I/O wait with application response time and watch queue length over a busy period. If both rise together, storage is the cause. If disk time stays low while the app slows down, look at locks or exhausted connection pools.
Conclusion: measure, tune, then size
A fast database on a VPS is almost never a budget question. It is a question of order: measure real latency, rank queries by total cost, confirm the working set fits in memory, then change one setting at a time. In most cases that work delivers more than moving up a plan, and it makes the upgrade genuinely useful when it does become necessary.
The next step is concrete: open the Open Vista NVMe VPS page, compare the five plans against your measured working set, and pick the one that fits the load you have today. If you are torn between two tiers, start smaller: upgrading needs no painful migration the following month.