Documentation Index
Fetch the complete documentation index at: https://docs.controlplane.com/llms.txt
Use this file to discover all available pages before exploring further.
Overview
pgEdge is an active-active distributed PostgreSQL cluster using Spock multi-master replication. Every node accepts both reads and writes simultaneously, and data written to any node replicates to all others automatically. The cluster spans multiple geographic locations with configurable replicas per location, providing a globally distributed, fault-tolerant database with no single point of failure.Architecture
- pgEdge — Stateful workload running PostgreSQL 17 with the Spock extension. All nodes are active writers connected in a full-mesh replication ring. Each replica gets its own persistent volume.
- pgcat — Connection pooler providing a single virtual endpoint for applications. Routes writes to the designated primary and distributes reads across all nodes.
- Spock — Multi-master logical replication extension included in the pgEdge image. Handles cross-node replication with last-update-wins conflict resolution.
What Gets Created
- Stateful pgEdge Workload — PostgreSQL 17 with the Spock extension. One set of replicas per configured location, each with its own persistent volume.
- Standard pgcat Workload — Connection pooler that routes application traffic to pgEdge nodes. Autoscales on RPS.
- Cron Backup Workload (optional) — Runs
pg_dumpon a schedule and uploads the result to AWS S3 or GCS. Only active in the first configured location. - Volume Set — ext4 general-purpose SSD volumes with 7-day snapshots. One volume per replica.
- Identity & Policy — An identity bound to the workloads with
revealpermissions on all secrets. When backup is enabled, the identity is also configured with the appropriate cloud account and IAM policy. - Secrets — A dictionary secret holding database credentials, an opaque secret containing the pgcat TOML configuration, and an opaque secret containing the node startup script.
- GVC — A GVC spanning all configured locations.
Prerequisites
- At least one Control Plane location to deploy into.
- For backup: an AWS or GCP cloud account and a storage bucket.
Installation
To install, follow the instructions for your preferred method:UI
Browse, install, and manage templates visually
CLI
Manage templates from your terminal
Terraform
Declare templates in your Terraform configurations
Pulumi
Declare templates in your Pulumi programs
Configuration
The defaultvalues.yaml for this template:
GVC & Locations
Each independent pgEdge deployment must use a uniquegvc.name. Configure one or more locations, each with a replica count:
| Environment | Replicas per location |
|---|---|
| Dev / testing | 1 |
| Production | 3 |
multiZone: true to spread replicas across availability zones within each location. Verify your selected locations support multiple availability zones before enabling.
Volume Set
Set the initial storage capacity (minimum 10 GiB). Optionally enable autoscaling to expand as data grows:Internal Access
Control which workloads can connect to pgEdge and pgcat:same-gvc— Allow access from all workloads in the same GVC.same-org— Allow access from all workloads in the org.workload-list— Allow access only from the specified workloads.
pgcat Pool Modes
pgcat multiplexes application connections into a smaller pool of real database connections, reducing overhead and protecting Postgres from connection exhaustion.| Mode | Behavior |
|---|---|
transaction | Connection held only for the duration of a transaction. Best for most web and API workloads. Not compatible with SET variables, temporary tables, or advisory locks. |
session | Connection held for the entire client session. Compatible with all Postgres features but provides less connection reuse. |
statement | Connection returned after every statement. Transactions are not supported. Rarely used. |
Connecting
Connect through pgcat for all application traffic. Each application only needs this single endpoint — pgcat handles routing to the appropriate pgEdge node:Schema Changes (DDL)
Spock replicates row-level changes (INSERT, UPDATE, DELETE) automatically. DDL (CREATE TABLE, ALTER TABLE, etc.) must be broadcast using spock.replicate_ddl() so it executes on all nodes.
Creating a table
Run on one node only — the DDL replicates to all nodes, then add the table to the replication set:Step 2 is required because Spock suppresses event triggers during replication apply to prevent loops. The
repset_add_table call itself replicates to all other nodes automatically.Other DDL
Primary Keys
Useuuid primary keys instead of serial/bigserial. Each node maintains its own sequence, so auto-increment integers will collide when the same ID is generated on multiple nodes simultaneously:
Backup
Whenbackup.enabled is true, a cron workload runs pg_dump on the configured schedule. Because every pgEdge node holds a full copy of the data, the backup job connects to replica-0 of the first configured location. Backup runs only in the first location — other locations have the backup workload suspended.
AWS S3 Prerequisites
- Create your S3 bucket and note its name and region.
- If you do not have a Cloud Account set up, refer to the docs to Create a Cloud Account. Note the cloud account name.
- Create a new AWS IAM policy with the following JSON (replace
YOUR_BUCKET_NAME):
- Set
backup.aws.cloudAccountNameto your cloud account name. - Set
backup.aws.policyNameto the policy created in step 3.
GCS Prerequisites
- Create your GCS bucket and note its name.
- If you do not have a Cloud Account set up, refer to the docs to Create a Cloud Account. Note the cloud account name.
- Add the
Storage Adminrole to the GCP service account created by the cloud account. - Set
backup.gcp.cloudAccountNameto your cloud account name.
Restoring a Backup
AWS S3:Important Notes
- GVC naming — Each independent pgEdge deployment must use a unique GVC name.
- Minimum replicas — Use at least 3 replicas per location for production to survive a node loss within a location.
- Conflict resolution — Concurrent writes to the same row from different nodes are resolved by last-update-wins based on commit timestamp. For workloads requiring stronger consistency, route writes for a given entity to a single node using application-level logic.
- multiZone — Verify your selected locations support multiple availability zones before enabling.
External References
pgEdge Documentation
Official pgEdge documentation
Spock Documentation
Spock multi-master replication extension
pgcat Documentation
pgcat connection pooler
pgEdge Template
View the source files, default values, and chart definition