A database on a VPS: PostgreSQL or MySQL
A database is almost never limited by the processor; memory and disk are what hold it back. If the working set fits in the cache, queries are fast even on an inexpensive server; if it does not, disk speed decides everything. Here is how to choose between PostgreSQL and MySQL, how much memory to give the database, which disk to pick and how to avoid losing data.
For most websites and applications the choice of database has already been made for you: WordPress, 1C-Bitrix and most PHP engines are built for MySQL, while many Django, Rails and Go projects use PostgreSQL by default. If you are free to choose, either database will handle a typical load, and the difference comes down to what you find easier to maintain and what your stack supports.
PostgreSQL or MySQL
- MySQL and MariaDB are the standard for PHP-based CMSs and online shops. Every control panel and every shared hosting plan supports them, there are more ready-made guides for them, and moving a site from shared hosting to a VPS usually comes down to a dump and an import.
- PostgreSQL is the choice for applications with complex queries, reports and strict data integrity. It has richer data types (JSONB, arrays, ranges) and supports extensions such as PostGIS for geodata and pgvector for vector search.
If the project is new and the engine does not dictate the database, pick the one your team knows: on a server with 4–8 GB of memory, the speed difference between them is smaller than the difference between a well-tuned and a poorly tuned database. Switching databases on a live project is expensive, so this decision is made once.
How much memory to give the database
Both databases keep frequently used data in their own cache, and its size is the most important setting after installation. The default is small, 128 MB in both, so without tuning a database on a server with 8 GB of memory barely uses it.
- PostgreSQL: according to the documentation, on a dedicated database server with 1 GB of memory or more, a reasonable starting value for
shared_buffersis 25% of memory. Allocating more than 40% is unlikely to help, because PostgreSQL also relies on the operating system's file cache. - MySQL (InnoDB): according to the MySQL 8.4 documentation, on dedicated servers up to 80% of physical memory is often given to the buffer pool,
innodb_buffer_pool_size.
The key word in both cases is "dedicated". If the same VPS also runs a web server, PHP-FPM, Redis and queues, less is left for the database: on a 4 GB server that also hosts the site, it makes sense to give the MySQL buffer pool 1–1.5 GB rather than 3. The rest is needed by the application processes and as headroom; otherwise the server starts swapping and the database becomes slower than it would be with a small cache.
The yardstick for server size is the volume of "hot" data: the tables and indexes that are accessed all the time. If they fit entirely in the cache, most reads never reach the disk. According to the accsly.io catalog as of November 2026, the median price of a VPS with 4 GB of memory is about $22 a month, with 8 GB about $41, with 16 GB about $74 and with 32 GB about $134. The catalog keeps prices in roubles; dollar figures are converted at the catalog rate of 7 November 2026. Choosing memory and cores is covered in more detail in the article How much RAM and how many cores a website needs, and plans with 16 GB of memory or more are listed on the page VPS with 16 GB RAM.
Disk and IOPS
When the data does not fit in memory, and on every write, the database accesses the disk with small random operations. What matters here is not the capacity or the sequential speed from the plan description but the number of input/output operations per second (IOPS) and latency. This is exactly where NVMe beats SATA SSD, and a hard drive is not suitable for a production database at all: it delivers hundreds of operations per second where an SSD delivers tens of thousands.
According to the accsly.io catalog as of November 2026, NVMe is listed in 41% of 29,603 VPS plans, and its share is higher among larger plans: 38% of plans with 2 GB of memory and 45% of plans with 32 GB. Disk types are compared in the article NVMe or SSD: does it matter for a website, and plans are collected in NVMe VPS.
The figures in a VPS plan description are an upper limit: the disk is shared with neighbours on the physical server, and many hosts cap IOPS per virtual machine. Measure the real speed after purchase, while you can still return the server, with the fio utility, using a random read and write test with 4–16 KB blocks. How to do this during a trial period is explained in the article How to test VPS ping and speed before you pay.
Backups and replicas
A disk snapshot at the host is a convenient but not the most reliable copy of a database: a snapshot taken during a write may need crash recovery, and it is usually stored at the same host. For a database, make your own copies with the database's tools:
- A logical dump with
pg_dumpfor PostgreSQL ormysqldumpfor MySQL. For InnoDB tables, take the dump with the--single-transactionoption; then, as the mysqldump documentation states, it is consistent without locking tables. This suits databases of up to tens of gigabytes; restoring a large database from a dump can take hours. - Point-in-time recovery: a full copy of the database files plus a continuous archive of the change log. In PostgreSQL this is WAL archiving, in MySQL the binary log. This lets you roll back to the minute before an erroneous
DELETErather than to last night.
Keep the copies outside the database server, in object storage or on a separate VPS in another data centre, and test them regularly by restoring. General backup rules are covered in the article VPS backups: strategies and tools, and storage options for copies in the article File storage on a VPS: disks and object storage.
A replica is a second copy of the database on another server that receives changes almost immediately: streaming replication in PostgreSQL, replication in MySQL. It lets you switch over quickly if the primary server fails and take load off it by sending reports to the replica. But it does not replace a backup: an accidentally dropped table disappears from the replica a fraction of a second later.
A managed database or your own on a VPS
Cloud providers offer managed databases: you get an address to connect to, and the provider takes care of installation, updates, backups and replicas. In Amazon RDS, for example, automated backups are kept for up to 35 days with point-in-time recovery.
- A managed database pays off when nobody on the team is ready to take responsibility for the database, when you need fault tolerance with automatic failover, or when downtime costs more than the markup. The downsides: the same memory and disk cost noticeably more than on a VPS, some settings and extensions are unavailable, and moving to another provider is harder.
- Your own database on a VPS is cheaper and gives you full control over the version, settings and extensions. In return, updates, backups, disk space monitoring and restore testing are your job. The difference between the two approaches is covered in the article Cloud server or VPS.
A common compromise for a small project is a database on the same VPS as the site, with a daily dump and a log archive sent to separate storage. When the database grows to several gigabytes of hot data or starts getting in the way of the application, it is moved to a separate server with NVMe, and the database port is closed to the internet, leaving access only from the application's addresses. Plans for such a server are collected on the pages VPS for PostgreSQL, VPS for MySQL and VPS for databases. Add disk space and query latency to monitoring right away: a full disk is the most common reason a database stops.