Why would you enable the majority option on a table prone to network partitions?

Without the majority option, a partition can let two isolated groups of nodes both keep accepting writes to the same replicated table independently, setting up an inconsistent-database conflict that has to be manually or programmatically resolved once the partition heals — and any conflicting writes made on the losing side get discarded, meaning real data loss for whatever was written there during the split.

Enabling {majority, true} prevents that scenario for the table it's set on: the minority side simply can't commit writes at all while partitioned, so there's no conflicting history to reconcile afterward. This makes sense specifically for tables where correctness genuinely depends on there being one agreed-upon sequence of writes (critical shared configuration, a distributed lock table) — and makes less sense for tables where availability matters more than strict consistency during a split, since it directly reduces uptime for writes on a minority partition.