Overview of durability options
==============================

Overview
--------

EDB Postgres Distributed (PGD) allows you to choose from several
replication configurations based on your durability, consistency,
availability, and performance needs using *commit scopes*.

In its basic configuration, PGD uses asynchronous replication. However,
commit scopes can change both the default and the per-transaction
behavior.

It’s also possible to configure the legacy Postgres synchronous
replication using standard ``synchronous_standby_names`` in the same way
as the built-in physical or logical replication. However, commit scopes
provide much more flexibility and control over the replication behavior.

The different synchronization settings affect three properties of
interest to applications that are related but can all be implemented
individually:

- Durability: Writing to multiple nodes increases crash resilience and
  allows you to recover the data after a crash and restart.

- Visibility: With the commit confirmation to the client, the database
  guarantees immediate visibility of the committed transaction on some
  sets of nodes.

- Conflict handling: Conflicts can be handled optimistically postcommit,
  with conflicts resolved when the transaction is replicated based on
  commit timestamps. Or, they can be handled pessimistically precommit.
  The client can rely on the transaction to eventually be applied on all
  nodes without further conflicts or get an abort, directly informing
  the client of an error.

Commit scopes allow four kinds of controlling durability of the
transaction:

- :ref:`Synchronous Commit <Synchronous Commit>`  : This kind of commit scope allows for a behavior where the origin node awaits a majority of nodes to confirm and behaves more like a native Postgres synchronous commit. 

- :ref:`How Quorum Commit works <How Quorum Commit works>`  : Quorum Commit internally uses two-phase commit to guarantee that a transaction commits or rolls back in the entire cluster, effectively serializing conflicting transactions across the cluster. 

- :ref:`Commit At Most Once <Commit At Most Once>`  : This kind of commit scope works with the client to verify that a transaction was committed before retrying, preventing duplicate commits in failover scenarios. 

- :ref:`Lag Control <Lag Control>`  : This kind of commit scope controls how far behind nodes can  be in terms of replication before allowing commit to proceed. 

Synchronous Commit and CAMO each support :ref:`Degrading commit scope rules <Degrading commit scope rules>`  , for even
further control of durability.

..  Note Legacy synchronization availability ::
   For backward compatibility, PGD still supports configuring synchronous replication with `synchronous_commit`  and `synchronous_standby_names` . See :ref:`Legacy synchronous replication using PGD <Legacy synchronous replication using PGD>`  for more on this option. We recommend that you use  :ref:`Synchronous Commit <Synchronous Commit>`  instead.