Other considerations v5
Review these other considerations when planning your deployment.
Data consistency
Read about Conflicts to understand the implications of the asynchronous operation mode in terms of data consistency.
Deployment
PGD is intended to be deployed in one of a small number of known-good configurations, using either Trusted Postgres Architect or a configuration management approach and deployment architecture approved by Technical Support.
Manual deployment isn't recommended and might not be supported.
Log messages and documentation are currently available only in English.
Sizing considerations
For production deployments, EDB recommends a minimum of 4 cores for each Postgres data node. Witness nodes don't participate in the data replication operation and don't have to meet this requirement. One core is enough without subgroup Raft. Two cores are enough when using subgroup Raft. Always size logical standbys exactly like the data nodes to avoid performance degradations in case of a node promotion. In production deployments, PGD Proxy nodes require a minimum of 1 core and must increase incrementally with an increase in the number of database cores in approximately a 1:10 ratio. We recommend detailed benchmarking of your specific performance requirements to determine appropriate sizing based on your workload. The EDB Professional Services team is available to assist if needed.
For development purposes, don't assign Postgres data nodes fewer than two cores. The sizing of Barman nodes depends on the database size and the data change rate.
You can deploy Postgres data nodes, Barman nodes, and PGD Proxy nodes on virtual machines or in a bare metal deployment mode. However, don't deploy multiple data nodes on VMs that are on the same physical hardware, as that reduces resiliency. Also don't deploy multiple PGD Proxy nodes on VMs on the same physical hardware, as that, too, reduces resiliency.
Single PGD Proxy nodes can be colocated with single PGD data nodes.
Clocks and timezones
EDB Postgres Distributed is designed to operate with nodes in multiple timezones, allowing a truly worldwide database cluster. Individual servers don't need to be configured with matching timezones, though we do recommend using log_timezone = UTC to ensure the human readable server log is more accessible and comparable.
Synchronize server clocks using NTP or other solutions.
Clock synchronization isn't critical to performance, as is the case with some other solutions. Clock skew can affect origin conflict detection, though EDB Postgres Distributed provides controls to report and manage any skew that exists. EDB Postgres Distributed also provides row-version conflict detection, as described in Conflict detection.