Architecture and performance
============================

Architectural options and performance
-------------------------------------

Always-on architectures
^^^^^^^^^^^^^^^^^^^^^^^

A number of different architectures can be configured, each of which has
different performance and scalability characteristics.

The group is the basic building block consisting of 2+ nodes (servers).
In a group, each node is in a different availability zone, with a
dedicated router and backup, giving immediate switchover and high
availability. Each group has a dedicated replication set defined on it.
If the group loses a node, you can easily repair or replace it by
copying an existing node from the group.

The Always-on architectures are built from either one group in a single
location or two groups in two separate locations. Each group provides
high availability. When two groups are leveraged in remote locations,
they together also provide disaster recovery (DR).

Tables are created across both groups, so any change goes to all nodes,
not just to nodes in the local group.

One node in each group is selected as the group’s write leader. Proxies
then direct application writes and queries to the write leader. The
other nodes are replicas of the write leader. If, at any point, the
write leader is seen to be unavailable, the remaining nodes in the group
select a new write leader from the group and the proxies direct traffic
to that node. Scalability isn’t the goal of this architecture.

Since writes are mainly to only one node, the possibility of contention
between nodes is reduced to almost zero. As a result, performance impact
is much reduced.

Secondary applications might execute against the shadow nodes, although
these are reduced or interrupted if the main application begins using
that node.

In the future, one node will be elected as the main replicator to other
groups, limiting CPU overhead of replication as the cluster grows and
minimizing the bandwidth to other groups.

Supported Postgres database servers
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

PGD is compatible with `PostgreSQL <https://www.postgresql.org/>`_  , :ref:`EDB Postgres Extended Server </pge/latest>`  , and `EDB Postgres Advanced Server <https://www.enterprisedb.com/docs/epas/latest>`_ 
and is deployed as a standard Postgres extension named BDR. See
:ref:`Compatibility changes <Compatibility changes>`  for details about supported version combinations.

Some key PGD features depend on certain core capabilities being
available in the target Postgres database server. Therefore, PGD users
must also adopt the Postgres database server distribution that’s best
suited to their business needs. For example, if having the PGD feature
Commit At Most Once (CAMO) is mission critical to your use case, don’t
adopt the community PostgreSQL distribution. It doesn’t have the core
capability required to handle CAMO.

PGD offers close-to-native Postgres compatibility. However, some access
patterns don’t necessarily work as well in multi-node setup as they do
on a single instance. There are also some limitations in what you can
safely replicate in a multi-node setting. `Application usage <https://www.enterprisedb.com/docs/pgd/latest/appusage>`_  goes into detail
about how PGD behaves from an application development perspective.

Characteristics affecting performance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

By default, PGD keeps one copy of each table on each node in the group,
and any changes propagate to all nodes in the group.

Since copies of data are everywhere, SELECTs need only ever access the
local node. On a read-only cluster, performance on any one node isn’t
affected by the number of nodes and is immune to replication conflicts
on other nodes caused by long-running SELECT queries. Thus, adding nodes
increases linearly the total possible SELECT throughput.

If an INSERT, UPDATE, and DELETE (DML) is performed locally, then the
changes propagate to all nodes in the group. The overhead of DML apply
is less than the original execution. So if you run a pure write workload
on multiple nodes concurrently, a multi-node cluster can handle more TPS
than a single node.

Conflict handling has a cost that acts to reduce the throughput. The
throughput then depends on how much contention the application displays
in practice. Applications with very low contention perform better than a
single node. Applications with high contention can perform worse than a
single node. These results are consistent with any multimaster
technology and aren’t particular to PGD.

Synchronous replication options can send changes concurrently to
multiple nodes so that the replication lag is minimized. Adding more
nodes means using more CPU for replication, so peak TPS reduces slightly
as each node is added.

If the workload tries to use all CPU resources, then this resource
constrains replication, which can then affect the replication lag.

In summary, adding more master nodes to a PGD group doesn’t result in
significant write throughput increase when most tables are replicated
because all the writes are replayed on all nodes. Because PGD writes are
in general more effective than writes coming from Postgres clients by
way of SQL, you can increase performance. Read throughput generally
scales linearly with the number of nodes.