> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

# Read Concern "majority"

For read operations not associated with [multi-document transactions](https://www.mongodb.com/docs/manual/core/transactions.md), read concern `"majority"` guarantees that the data read has been acknowledged by a majority of the replica set members. The documents read are durable and guaranteed to not roll back.

For operations in [multi-document transactions](https://www.mongodb.com/docs/manual/core/transactions.md), read concern `"majority"` provides its guarantees only if the transaction commits with [write concern "majority"](https://www.mongodb.com/docs/manual/core/transactions.md#std-label-transactions-write-concern). Otherwise, the [`"majority"`](https://www.mongodb.com/docs/manual/reference/read-concern-majority.md#mongodb-readconcern-readconcern.-majority-) read concern provides no guarantees about the data read in transactions.

Regardless of the [read concern](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-read-concern) level, the most recent data on a node may not reflect the most recent version of the data in the system.

For more information about what happens if a primary fails, see [Automatic Failover.](https://www.mongodb.com/docs/manual/replication.md#std-label-replication-auto-failover)

## Performance

Each replica set member maintains, in memory, a view of the data at the majority-commit point; the majority-commit point is calculated by the primary. To fulfill read concern `"majority"`, the node returns data from this view and is comparable in performance to other read concerns.

## Latency

Read concern `"majority"` does not decrease the performance of queries; it only modifies what returns to the client. Read concern `"majority"` allows only data that is durably stored on a majority of nodes in the replica set to return to the client. In comparison, queries with read concern `"local"` can return data that may be lost in certain scenarios, such as a rollback.

## Availability

Read concern [`"majority"`](https://www.mongodb.com/docs/manual/reference/read-concern-majority.md#mongodb-readconcern-readconcern.-majority-) is available for use with or without causally consistent sessions and transactions.

**Warning:**

If you are using a three-member primary-secondary-arbiter (PSA) architecture, consider the following:

- The write concern [`"majority"`](https://www.mongodb.com/docs/manual/reference/write-concern.md#mongodb-writeconcern-writeconcern.-majority-) can cause performance issues if a secondary is unavailable or lagging. For advice on how to mitigate these issues, see [Mitigate Performance Issues in Self-Managed PSA Replica Sets.](https://www.mongodb.com/docs/manual/tutorial/mitigate-psa-performance-issues.md#std-label-performance-issues-psa)

- If you are using a global default [`"majority"`](https://www.mongodb.com/docs/manual/reference/read-concern-majority.md#mongodb-readconcern-readconcern.-majority-) and the write concern is less than the size of the majority, your queries may return stale (not fully replicated) data.

## Example

Consider the following timeline of a write operation Write 0 to a three member replica set:

**Note:**

For simplification, the example assumes:

- All writes prior to Write 0 have been successfully replicated to all members.

- Write prev is the previous write before Write 0.

- No other writes have occured after Write 0.

![Timeline of a write operation to a three member replica set](/images/read-concern-write-timeline.svg)

| Time | Event | Most Recent Write | Most Recent w: "majority" write |
| --- | --- | --- | --- |
| t 0 | Primary applies Write 0 | **Primary**: Write 0**Secondary** 1: Write prev**Secondary** 2: Write prev | **Primary**: Write prev**Secondary** 1: Write prev**Secondary** 2: Write prev |
| t 1 | Secondary 1 applies write 0 | **Primary**: Write 0**Secondary** 1: Write 0**Secondary** 2: Write prev | **Primary**: Write prev**Secondary** 1: Write prev**Secondary** 2: Write prev |
| t 2 | Secondary 2 applies write 0 | **Primary**: Write 0**Secondary** 1: Write 0**Secondary** 2: Write 0 | **Primary**: Write prev**Secondary** 1: Write prev**Secondary** 2: Write prev |
| t 3 | Primary is aware of successful replication to Secondary 1 and sends acknowledgment to client | **Primary**: Write 0**Secondary** 1: Write 0**Secondary** 2: Write 0 | **Primary**: Write 0**Secondary** 1: Write prev**Secondary** 2: Write prev |
| t 4 | Primary is aware of successful replication to Secondary 2 | **Primary**: Write 0**Secondary** 1: Write 0**Secondary** 2: Write 0 | **Primary**: Write 0**Secondary** 1: Write prev**Secondary** 2: Write prev |
| t 5 | Secondary 1 receives notice (through regular replication mechanism) to update its snapshot of its most recent w: "majority" write | **Primary**: Write 0**Secondary** 1: Write 0**Secondary** 2: Write 0 | **Primary**: Write 0**Secondary** 1: Write 0**Secondary** 2: Write prev |
| t 6 | Secondary 2 receives notice (through regular replication mechanism) to update its snapshot of its most recent w: "majority" write | **Primary**: Write 0**Secondary** 1: Write 0**Secondary** 2: Write 0 | **Primary**: Write 0**Secondary** 1: Write 0**Secondary** 2: Write 0 |

Then, the following tables summarizes the state of the data that a read operation with [`"majority"`](https://www.mongodb.com/docs/manual/reference/read-concern-majority.md#mongodb-readconcern-readconcern.-majority-) read concern would see at time `T`.

![Timeline of a write operation to a three member replica set.](/images/read-concern-write-timeline.svg)

| Read Target | Time `T` | State of Data |
| --- | --- | --- |
| Primary | Before t 3 | Data reflects Write prev |
| Primary | After t 3 | Data reflects Write 0 |
| Secondary 1 | Before t 5 | Data reflects Write prev |
| Secondary 1 | After t 5 | Data reflects Write 0 |
| Secondary 2 | Before or at t 6 | Data reflects Write prev |
| Secondary 2 | After t 6 | Data reflects Write 0 |

## Storage Engine Support

Read concern [`"majority"`](https://www.mongodb.com/docs/manual/reference/read-concern-majority.md#mongodb-readconcern-readconcern.-majority-) is available for the WiredTiger storage engine.

**Tip:**

The [`serverStatus`](https://www.mongodb.com/docs/manual/reference/command/serverStatus.md#mongodb-dbcommand-dbcmd.serverStatus) command returns the [`storageEngine.supportsCommittedReads`](https://www.mongodb.com/docs/manual/reference/command/serverStatus.md#mongodb-serverstatus-serverstatus.storageEngine.supportsCommittedReads) field, which indicates whether the storage engine supports `"majority"` read concern.

## Read Concern `"majority"` and Transactions

**Note:**

You set the read concern at the transaction level, not at the individual operation level. To set the read concern for transactions, see [Transactions and Read Concern.](https://www.mongodb.com/docs/manual/core/transactions.md#std-label-transactions-read-concern)

For operations in [multi-document transactions](https://www.mongodb.com/docs/manual/core/transactions.md), read concern `"majority"` provides its guarantees only if the transaction commits with [write concern "majority"](https://www.mongodb.com/docs/manual/core/transactions.md#std-label-transactions-write-concern). Otherwise, the [`"majority"`](https://www.mongodb.com/docs/manual/reference/read-concern-majority.md#mongodb-readconcern-readconcern.-majority-) read concern provides no guarantees about the data read in transactions.

## Read Concern `"majority"` and Aggregation

You can specify [read concern](https://www.mongodb.com/docs/manual/reference/read-concern.md#std-label-read-concern) level [`"majority"`](https://www.mongodb.com/docs/manual/reference/read-concern-majority.md#mongodb-readconcern-readconcern.-majority-) for an aggregation that includes an [`$out`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/out.md#mongodb-pipeline-pipe.-out) stage.

## Read Your Own Writes

You can use [causally consistent sessions](https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency.md#std-label-sessions) to read your own writes, if the writes request acknowledgment.

## Primary-Secondary-Arbiter Replica Sets

Starting in MongoDB 5.0, [`enableMajorityReadConcern`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-replication.enableMajorityReadConcern) and [`--enableMajorityReadConcern`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--enableMajorityReadConcern) cannot be changed and are always set to `true` due to storage engine improvements.

In earlier versions of MongoDB, [`enableMajorityReadConcern`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-replication.enableMajorityReadConcern) and [`--enableMajorityReadConcern`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--enableMajorityReadConcern) are configurable and can be set to `false` to prevent storage cache pressure from immobilizing a deployment with a three-member primary-secondary-arbiter (PSA) architecture.

If you are using a three-member primary-secondary-arbiter (PSA) architecture, consider the following:

- The write concern [`"majority"`](https://www.mongodb.com/docs/manual/reference/write-concern.md#mongodb-writeconcern-writeconcern.-majority-) can cause performance issues if a secondary is unavailable or lagging. For advice on how to mitigate these issues, see [Mitigate Performance Issues in Self-Managed PSA Replica Sets.](https://www.mongodb.com/docs/manual/tutorial/mitigate-psa-performance-issues.md#std-label-performance-issues-psa)

- If you are using a global default [`"majority"`](https://www.mongodb.com/docs/manual/reference/read-concern-majority.md#mongodb-readconcern-readconcern.-majority-) and the write concern is less than the size of the majority, your queries may return stale (not fully replicated) data.