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.

Invest now in Acorns!!! 🚀
Join Acorns and get your $5 bonus!

Acorns is a micro-investing app that automatically invests your "spare change" from daily purchases into diversified, expert-built portfolios of ETFs. It is designed for beginners, allowing you to start investing with as little as $5. The service automates saving and investing. Disclosure: I may receive a referral bonus.

Invest now!!! Get Free equity stock (US, UK only)!

Use Robinhood app to invest in stocks. It is safe and secure. Use the Referral link to claim your free stock when you sign up!.

The Robinhood app makes it easy to trade stocks, crypto and more.

Webull! Receive free stock by signing up using the link: Webull signup.