Super Validator Deployment Recommendations

This page collects deployment recommendations for operators running a Super Validator (SV) node. These settings are not strictly required, but following them helps your node run reliably and perform well under production load.

PostgreSQL configuration

The recommended values below are expressed the way many managed PostgreSQL providers (for example, GCP Cloud SQL) require them: as plain numbers in the unit the parameter expects (KB or MB), rather than human-friendly strings such as 2GB. Adjust the notation to match your platform if it accepts unit suffixes directly.

Parameter	Recommended value	Reason	Reference
`random_page_cost`	`1.1`	Lowers the planner’s assumed cost of random disk access. The default of `4.0` assumes spinning disks and causes the planner to avoid index scans. On SSD or network-attached storage, random access is nearly as cheap as sequential access, so a lower value produces better query plans.	random_page_cost
`temp_file_limit`	`2147483647`	Raises the per-session limit on temporary files (in KB, ~2 TB) so that large analytical or maintenance queries do not fail with `temporary file size exceeds temp_file_limit` under heavy load.	temp_file_limit
`max_wal_size`	`20480`	Increases the maximum WAL size to 20 GB (value in MB). Larger WAL headroom reduces how often checkpoints are forced under write-heavy load, smoothing out I/O spikes and improving throughput.	max_wal_size
`maintenance_work_mem`	`2000000`	Allocates ~2 GB (value in KB) of memory for maintenance operations such as `VACUUM`, `CREATE INDEX`, and autovacuum. More memory makes these operations significantly faster and helps autovacuum keep up with the SV’s write rate.	maintenance_work_mem
`work_mem`	`16384`	Raises the per-operation working memory to 16 MB (value in KB), up from the default of 4 MB, to better support large queries. This is still low enough to avoid out-of-memory conditions when many queries run concurrently. Increase it further on instances with more available memory.	work_mem
`autovacuum_freeze_max_age`	`500000000`	Raises the maximum transaction age before an aggressive anti-wraparound autovacuum is forced, from the default of 200 million to 500 million. This reduces the impact of large, disruptive autovacuum freeze runs and gives regular autovacuum more time to do the work incrementally.	autovacuum_freeze_max_age

Data checksums

We strongly recommend enabling PostgreSQL data checksums on all databases backing your SV node. Data checksums allow PostgreSQL to detect on-disk data corruption early, which can prevent full node breakage in cases of state corruption. Data checksums are enabled by default for databases created by the in-cluster Postgres Helm chart (splice-postgres) and by the Docker Compose based deployments.

Data checksums can only be enabled when a database cluster is first initialized (initdb). Enabling them by default only affects freshly initialized databases. Existing deployments are not automatically migrated and will continue to run without data checksums until they are explicitly enabled.Operators of existing deployments should enable checksums on their existing databases out-of-band, for example by stopping PostgreSQL and running pg_checksums --enable against the data directory (see the pg_checksums documentation).

Overview

Validator Deployment