PostgreSQL Server Requirements: Memory Settings, Replication and the Monthly Cost of a Cluster

PostgreSQL has no system requirements page in the usual sense; what it has is a resource consumption chapter that tells an operator how to divide whatever memory the server has. That chapter, checked on 1 November 2026, is enough to size a database node honestly. This guide applies it to a primary with hot standbys and prices three configurations of the PostgreSQL primary-secondary cluster package on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic).

What PostgreSQL says about memory

The documentation's guidance on shared_buffers, the database's own cache of table and index pages, is the sizing rule that matters: the default is typically 128 MB, but "if you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in your system". It adds that PostgreSQL also relies on the operating system's cache, so an allocation of more than 40% of RAM is unlikely to work better than a smaller one, and that larger settings usually need a larger max_wal_size to spread the writing of changed pages over time.

Two per-operation settings complete the picture. work_mem, the memory a sort or hash may use before spilling to disk, defaults to 4 MB and is multiplied by the number of concurrent operations, which is why raising it carelessly on a busy server exhausts memory; maintenance_work_mem, for VACUUM and index builds, defaults to 64 MB and can be raised freely because few run at once.

From the rules to a node size

Read the rules backwards and a node size follows from the working set. A database whose hot tables and indexes total 500 MB wants about 2 GiB on the node: 25% in shared_buffers holds the hot set, the operating system cache holds the rest, and there is room for connections and sorts. A 2 GB working set wants about 8 GiB. The common mistake is sizing to the database on disk rather than the part that is actually read; a 50 GB database with a 1 GB hot set is a 4 GiB node, not a 64 GiB one.

Standbys need the same memory as the primary if they serve reads, because they cache the same pages, and can be smaller if they exist only as a failover target. Connections cost memory too: a few megabytes each, so a pool (Pgpool-II in the package, or PgBouncer) in front of the database is what lets hundreds of application connections share dozens of database ones.

The three configurations on PaaS and their cost

The PostgreSQL primary-secondary cluster package installs a primary, hot-standby secondaries with streaming replication, a Pgpool-II entry point and optional TLS. Cloudlets are 128 MiB RAM plus 400 MHz CPU, billed at $0.003372 per cloudlet-hour, $2.46 per cloudlet-month, no licence fee.

The figures are ceilings for always-on nodes before volume discounts; disk is per gigabyte on top. Set shared_buffers to a quarter of the node's cloudlet limit in RAM terms and leave the rest to the operating system cache inside the same container. The PaaS pricing calculator prices other node sizes and a third standby.

What replication adds and what it does not

Streaming replication keeps standbys a few milliseconds behind the primary and lets them serve reads, which is where the Production row's two standbys earn their cost: reporting and analytics queries leave the primary alone. It does not give you a second writable node, and failover promotes a standby, which the package handles with Pgpool-II so that the application's connection string does not change. The read replicas post shows the Pgpool-II routing for a SaaS application, and the failover post is the night the primary died.

Backups are not replication

A standby replicates a mistaken DELETE as faithfully as a good INSERT. Backups are the Database Backup/Restore add-on dumping the primary on a schedule to a Backup Storage node, with retention you choose, plus WAL archiving if point-in-time recovery is required. Encrypt client connections with the PostgreSQL TLS add-on when the application lives in another environment or a review asks, and raise maintenance_work_mem before large index builds so they finish in minutes rather than hours.

Frequently Asked Questions

How much RAM does PostgreSQL need?

PostgreSQL publishes no minimum; its documentation, checked on 1 November 2026, says to start shared_buffers at 25% of RAM on a dedicated server with 1 GB or more and rarely to exceed 40%, leaving the rest to the operating system cache. Size the node to the working set: about 2 GiB for a hot set of 500 MB, which is the Standard configuration on MassiveGRID PaaS.

Do standbys need as much memory as the primary?

If they serve reads, yes, because they cache the same pages; if they exist only as a failover target they can be smaller. The Production configuration gives the primary and both standbys 4 GiB so reporting queries can run on the standbys.

What does a PostgreSQL cluster cost per month?

About $39.36 for a 1 GiB primary and standby, $78.72 at 2 GiB each, and $236.16 for a 4 GiB primary with two 4 GiB standbys on MassiveGRID PaaS, at $0.003372 per cloudlet-hour before volume discounts, plus disk per gigabyte. The package includes Pgpool-II and optional TLS at no licence fee.