pgEdge

pgEdge is a distributed PostgreSQL distribution for edge deployments. It uses Spock multi-master logical replication.

Overview

Pigsty integrates pgEdge through pg_mode: pgedge and delivers it through the standard PostgreSQL cluster workflow:

• pgedge: a PG15, PG16, PG17, and PG18 compatible kernel; the template defaults to PG18
• spock: Active-active multi-master logical replication
• snowflake: Distributed unique sequences
• lolor: Large object logical replication compatibility layer

The current Pigsty repository supplies the versioned kernel packages pgedge-15, pgedge-16, pgedge-17, and pgedge-18. The template defaults to pg_version: 18. The pgedge-$v kernel package includes the control files, SQL files, and shared libraries for spock, snowflake, and lolor. Thus, these extensions are no longer separate packages in pg_extensions. pgEdge supports the PostgreSQL wire protocol, so psql, JDBC/ODBC, DBeaver, and similar tools work as usual.

First validate the kernel on one node. Then expand to a replication topology with multiple nodes. The template configures the kernel, extensions, monitoring, backup, and access control. Design the multi-master topology for your workload consistency requirements and conflict strategy.

Installation

Use the built-in Pigsty template:

./configure -c pgedge
./deploy.yml

The template installs spock, snowflake, and lolor in the meta database. After deployment, verify the kernel and extensions:

psql -d meta -c "SELECT version();"
psql -d meta -c "SELECT extname, extversion FROM pg_extension WHERE extname IN ('spock','snowflake','lolor') ORDER BY 1;"

For the full template and parameters, see: pgedge config template.

Configuration

Key parameters in the pgedge template (matching conf/pgedge.yml):

pg_mode: pgedge
pg_version: 18
pg_packages: [ pgedge, pgsql-common ]
pg_libs: 'spock, lolor, pg_stat_statements, auto_explain'
pg_databases:
  - { name: meta ,baseline: cmdb.sql ,comment: pigsty meta database ,schemas: [pigsty] ,extensions: [spock, snowflake, lolor] }

For a future multi-node multi-master topology, we recommend explicit settings for logical replication capacity and snowflake.node:

pg_parameters:
  wal_level: logical
  max_replication_slots: 16
  max_wal_senders: 16
  'snowflake.node': 1

snowflake.node must be unique on every writable node. Otherwise, distributed IDs will collide.

Usage

First validate the kernel on one node. Then expand to a Spock replication topology with multiple nodes.

If you need these capabilities in a business database as well, create the extensions first:

CREATE EXTENSION IF NOT EXISTS spock;
CREATE EXTENSION IF NOT EXISTS snowflake;
CREATE EXTENSION IF NOT EXISTS lolor;

Then use the Spock SQL API or the pgEdge CLI to create nodes, replication sets, and subscriptions. If your schema uses serial or identity, plan the snowflake sequence migration before you enable multi-master writes. Otherwise, primary key collisions between nodes are likely.

Notes

• Configure pgEdge replication for each database. There is no instance-wide switch to enable multi-master replication for all databases.
• Replicated tables should have a PRIMARY KEY or an appropriate REPLICA IDENTITY.
• UNLOGGED and TEMPORARY tables do not participate in Spock logical replication.
• Spock configuration and operations usually require superuser privileges. Production deployments should define privilege boundaries clearly.
• If your workload requires large object replication, use lolor explicitly. Do not assume that native large objects will replicate correctly.
• Before you configure multi-master replication across regions, evaluate network latency, conflict handling, and the write model.

Related Docs

• PGSQL Kernel Overview
• pgedge config template
• PGSQL kernel mode config
• spock extension
• snowflake extension
• lolor extension
• pgEdge official docs
• Spock Limitations
• Snowflake Sequences

Available Extensions

The pgEdge kernel has 63 available extensions. The following table lists the extra extensions, excluding bundled PG Contrib extensions: