PostgreSQL

Planned design. TractorStack is in development. This page describes how it is designed to work; nothing here is available to install yet. See the roadmap for the status of each part.

PostgreSQL is the main database in TractorStack. It holds your application data, and the design also uses it for two platform jobs: storing OpenTofu state and keeping a history of routine jobs such as backups and restore tests. From stage 2 it runs as PostgreSQL with Patroni high availability, which is the one part of TractorStack already built and working internally.

Role in each stage

Stage	Setup
1 In design	A single instance, nightly pgBackRest backups to RustFS, automatic test restore
2 Built	A Patroni cluster with automatic failover
3 Planned	The same cluster, still on VMs managed by Ansible
4 Exploring	CloudNativePG operator inside the cluster

PostgreSQL with Patroni high availability

Patroni manages leader election and automatic failover across several PostgreSQL nodes, using a distributed configuration store such as etcd. Applications reach the current primary through a routing layer such as HAProxy or a virtual IP, so they keep one connection address while the leader changes underneath. Details of our reference layout will be published.

Failover depends on quorum. The configuration store needs three or more members to decide safely who leads; on a two-server site, a small witness node can be the third. The High availability page covers this, and how failovers are rehearsed.

Backups with pgBackRest

pgBackRest takes full and incremental backups and archives the write-ahead log, which lets you restore to a point in time. It works alongside Patroni and can write straight to an S3-compatible repository, so the design points it at a bucket on RustFS from stage 1. Using S3 from the start means a later stage can restore a stage 1 backup without conversion.

A backup nobody has restored is a hope, not a backup. After each nightly run the plan is to restore the latest backup into a scratch container, run a few sanity queries and record the result. More in Backups.

Planned configuration

A planned example of pgBackRest settings Ansible would write. Illustrative only.

# Planned example only: /etc/pgbackrest/pgbackrest.conf
[global]
repo1-type=s3
repo1-s3-endpoint=rustfs.example.internal
repo1-s3-bucket=backups
repo1-s3-region=local
repo1-path=/pgbackrest
repo1-retention-full=4
repo1-cipher-type=aes-256-cbc

[main]
pg1-path=/var/lib/postgresql/data

Stage 4: CloudNativePG

When running the database outside Kubernetes becomes the bottleneck, the design looks at the CloudNativePG operator. It manages PostgreSQL clusters inside Kubernetes, can back up to S3-compatible storage and can bootstrap a new cluster from an existing one, which gives a path to move without a long outage. This is still being explored.

PostgreSQL as a queue

For background jobs at small scale, a table read with SELECT ... FOR UPDATE SKIP LOCKED works well as a queue. That is why Valkey or Redis is optional.

Limits and caveats

A replica is not a backup. A bad delete replicates in seconds; point-in-time restore is what saves you.
Applications must reconnect after a failover. Short retries in the connection code are enough.
Major version upgrades still need planning and a maintenance window.
The backup encryption key must be stored safely away from the servers. Without it, backups can’t be read.

Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com