Choosing your architecture¶

Always On architectures reflect EDB’s Trusted Postgres architectures that encapsulate practices and help you to achieve the highest possible service availability in multiple configurations. These configurations range from single-location architectures to complex distributed systems that protect from hardware failures and data center failures. The architectures leverage EDB Postgres Distributed’s multi-master capability and its ability to achieve 99.999% availability, even during maintenance operations.

You can use EDB Postgres Distributed for architectures beyond the examples described here. Use-case-specific variations have been successfully deployed in production. However, these variations must undergo rigorous architecture review first. Also, EDB’s standard deployment tool for Always On architectures, TPAExec, must be enabled to support the variations before they can be supported in production environments.

Standard EDB Always On architectures¶

EDB has identified four standard Always On architectures:

Always On Bronze : Single location with two data nodes, a witness node,

and a local backup

Always On Silver : Single location with three data nodes and second

location with an offsite backup

Always On Gold : Two locations with two data nodes each and a third

location with a witness

Always On Platinum : Two locations with three data nodes each (two masters

plus additional redundant hardware in a hot standby mode)

Each architecture can provide zero Recovery Point Objective (RPO), as data can be streamed synchronously to at least one local master, thus guaranteeing zero data loss in case of local hardware failure. However, synchronous replication is highly discouraged for Bronze architectures due to the extended RPO on failure of either data node.

Increasing the availability guarantee drives additional cost for hardware and licenses, networking requirements, and operational complexity. Carefully consider your availability and compliance requirements before choosing an architecture.

Architecture details¶

EDB Postgres Distributed uses a show-raft -based consensus architecture. While regular database operations (insert, select, delete) don’t require cluster-wide consensus, EDB Postgres Distributed benefits from an odd number of nodes to make decisions that require consensus, such as generating new global sequences, or distributed DDL operations. Even the simpler architectures always have three nodes within a location, even if not all of them are storing data. Always On Gold and Platinum, which use two locations, introduce a fifth node as a witness node to support the RAFT requirements.

Applications connect to the standard Always On architectures by way of multi-host connection strings, where each HARP-proxy server is a distinct entry in the multi-host connection string. Other connection mechanisms have been successfully deployed in production, but they’re not part of the standard Always On architectures.