PostgreSQL on a VPS in 2026: Tuning, Backups and Security for Production

PostgreSQL is the database behind a large share of modern applications, from SaaS products to ERP systems and analytics. It runs well on a VPS, but its default configuration is deliberately conservative and assumes very little memory. A few changes to memory settings, connections, backups and network exposure make the difference between a database that struggles and one that quietly handles growth. This guide covers those changes.

Choosing the right VPS for PostgreSQL

• Memory first. PostgreSQL is fastest when the data you query most often fits in RAM. Estimate your working set and size memory around it.

• NVMe storage. Every commit writes to disk. Low-latency NVMe storage directly improves write performance and checkpoint behavior.

• Dedicated CPU. Query performance should not depend on what other tenants are doing. A Cloud VPS with fully dedicated vCPU and RAM gives stable, predictable performance.

Step 1: Tune memory settings

These values in postgresql.conf are a reasonable starting point for a VPS with 8 GB RAM that runs mainly PostgreSQL. Adjust them to your server and measure.

# Example starting point for a VPS with 8 GB RAM, NVMe storage
shared_buffers = 2GB
effective_cache_size = 6GB
work_mem = 16MB
maintenance_work_mem = 512MB
max_connections = 100
random_page_cost = 1.1
effective_io_concurrency = 200
wal_compression = on
checkpoint_completion_target = 0.9

• shared_buffers: about 25 percent of RAM is a common starting point.

• effective_cache_size: tells the planner how much memory is available for caching, including the OS cache. It does not allocate memory.

• work_mem: memory per sort or hash operation, per connection. Set it too high with many connections and you can run out of RAM.

• random_page_cost: lower values suit SSD and NVMe storage, where random reads are cheap.

Step 2: Control connections with a pooler

Each PostgreSQL connection is a separate process with its own memory. Applications that open hundreds of connections, such as serverless functions or many app workers, can exhaust the server. Put PgBouncer in front of PostgreSQL in transaction pooling mode, keep max_connections modest, and let the pooler handle bursts.

Step 3: Never expose port 5432 to the internet

Bind PostgreSQL to localhost or a private network, and allow only your application servers in pg_hba.conf. If a remote tool needs access, use an SSH tunnel or VPN instead of opening the port. Use scram-sha-256 password authentication and a separate role for each application, with only the privileges it needs.

Step 4: Back up in two layers

1. Logical backups with pg_dump: simple, portable and good for restoring a single database or table. Run them nightly and copy them off the server.

2. Physical backups with point-in-time recovery: tools such as pgBackRest or WAL-G take base backups and archive the write-ahead log continuously, so you can restore to a specific moment, for example just before an accidental DELETE.

Store backups in a different location from the database server, encrypt them, and test restores regularly. On an IM HOST Cloud VPS, the free automatic server backup every 72 hours is a useful extra layer, but database-aware backups remain essential for consistent restores and point-in-time recovery.

Step 5: Keep vacuum and statistics healthy

PostgreSQL relies on autovacuum to reclaim space and keep table statistics up to date. Leave it enabled. For large, busy tables, make autovacuum more aggressive on that table rather than turning it off. Watch for table bloat and long-running transactions, which block cleanup.

Step 6: Find slow queries

Enable the pg_stat_statements extension to see which queries consume the most time, and set log_min_duration_statement to log anything slower than, for example, 500 milliseconds. Most performance problems are fixed with an index or a rewritten query, not a bigger server.

Step 7: Monitor the right metrics

• Cache hit ratio and disk read rates.

• Active and idle connections.

• Replication lag, if you run replicas.

• Disk usage growth and WAL volume.

• Long-running queries and locks.

Step 8: Plan for growth

When one server is no longer enough, add a streaming replica for read traffic and failover, move heavy analytics to a replica, or move PostgreSQL to a dedicated server. For very large databases, a dedicated server gives the database the entire machine.

Run PostgreSQL on IM HOST

IM HOST Cloud VPS plans combine fully dedicated vCPU and RAM, NVMe storage and KVM virtualization, with locations in the US, UK, Poland, Germany and Egypt, so you can keep your database close to your users and inside the right jurisdiction.