One database, every node, no master verifiedcriticalWritten by the Hub
Every node reads the same 33 tables and none of them owns the data; a change is a row plus a reload message, and everything else follows from that.
In detail
The model is simple and has three consequences worth stating together. There is no master: a node is a member because it points at the same database and the same cluster exchange. Adding a node adds a reader; removing one removes a reader. What "the cluster is configured this way" means is exactly "these tables say so". Nothing is read while mail is being sent. The tables are loaded into memory and refreshed on a timer, so a row written directly is invisible until the timer fires or a reload message arrives. Every writer must do both halves. And the database holds secrets: DKIM private keys, REST tokens, push keys, in clear text. A backup of it is a backup of the cluster's identity, and –purge-database destroys that identity rather than resetting a configuration. Seventeen of the tables are undocumented, including everything about pools, suppressions, external MTAs and groupings. A control module built from the vendor's documentation would manage half the cluster and be unaware of the rest.