Using predefined scopes v6.4.0

If your cluster uses a single node group, start with a predefined scope. PGD ships four that cover the most common patterns, ready to use with no configuration, so you don't need to understand the full policy language to get started. Each predefined scope applies to a single node group. For clusters that span multiple groups with different requirements, use a custom scope instead.

• local protect suits workloads where low latency is the priority and some data loss on node failure is acceptable. It commits as soon as the local node persists the transaction, with no remote confirmation required. If that node fails before replication catches up, any transactions that committed on it but hadn't yet replicated to a peer are permanently lost — no other node has a copy.
• lag protect suits high-throughput workloads that need async performance but a bounded recovery point. It commits asynchronously while replication lag stays under a threshold (30 seconds by default). When lag grows too large, commits slow down until replication catches up. Commits block when lag exceeds the threshold.
• majority protect suits production write workloads that need strong durability guarantees. It waits for a majority of nodes in the origin group to confirm before the commit returns. Commit latency is higher than with async replication.
• adaptive protect suits cross-site deployments where network disruptions are common and writes can't afford to block. It waits for majority confirmation like majority protect, but degrades to async automatically if a majority isn't reachable within 10 seconds. Strict behavior resumes as soon as a majority is available again. Recovery point weakens temporarily during degrade.

Set a predefined scope as the default for a node group:

SELECT bdr.alter_node_group_option(
    node_group_name := 'top_group',
    config_key := 'default_commit_scope',
    config_value := 'majority protect'
);

Apply a predefined scope to a single transaction:

BEGIN;
SET LOCAL bdr.commit_scope = 'majority protect';
-- ... your writes ...
COMMIT;

Set a group-level default when all transactions in that group need the same durability guarantee and you don't want to rely on application code to set it consistently. Use SET LOCAL for transactions that need a different level, for example a bulk import that can tolerate async while individual payment records need majority confirmation. Transaction-level settings always override the group default.

See Predefined commit scopes for the full definitions.

Example scenario: primary active group with DR group

In a primary active group, DR group deployment, the primary site has two nodes (a write leader and a second node) with a single DR node in the DR site used for disaster recovery on full loss of the primary site.

The replication goals for this setup are:

• Within the primary group: synchronous confirmation from the second primary node, degrading to async after 10 seconds if it's unreachable
• To the DR site: asynchronous replication so transaction latency is unaffected, while keeping the DR node reasonably current for a sustained primary site outage

Apply adaptive protect as the default scope for the primary group:

SELECT bdr.alter_node_group_option(
    node_group_name := 'primary_group',
    config_key := 'default_commit_scope',
    config_value := 'adaptive protect'
);

The commit scope is applied to the primary group only. Async replication to the DR site is implicit. The DR node receives changes as a result of the primary group's replication, not through a separately configured policy.

After applying the scope, expect the following:

• Commits from the write leader return only after the second primary node confirms receipt.
• If the second primary node is unreachable for 10 seconds, writes continue without blocking — the scope degrades to async automatically.
• When the second primary node is reachable again, the scope returns to requiring confirmation before commits return. No manual intervention needed.
• The DR node receives changes asynchronously and doesn't delay commits.
• On failover, PGD reassigns write leadership automatically — no scope reconfiguration needed.