Add configuration properties for MongoDB's read and write consistency

[Torres-09]

Summary

Currently, MongoProperties in Spring Boot does not provide a dedicated property for configuring MongoDB read preference. This limits the ability to declaratively set read preference modes and tags via application properties, especially in replica set environments.

Current Workarounds

Using connection URI with readPreference parameter:

spring:
  data:
    mongodb:
      uri: mongodb://localhost:27017/test?readPreference=secondaryPreferred

Or customizing MongoClientSettings via Java configuration

Limitations:

URI-based configuration is less consistent with other MongoDB properties.
Java-based customization increases configuration complexity and reduces clarity for operations teams.

Proposal

Add a readPreference property to MongoProperties, enabling configuration like:

spring:
  data:
    mongodb:
      read-preference: secondaryPreferred

This property would map to the corresponding ReadPreference in the MongoDB Java driver.

Ensure full backward compatibility with existing URI-based configurations.

Optionally support configuration of readPreferenceTags if alignment with advanced use cases is desired.

Use Cases

Applications running on MongoDB replica sets that require secondary or custom read routing.

Environments where configuration consistency and clarity are important (e.g., cloud-native deployments, infrastructure as code).

References

MongoDB Read Preference Documentation

Spring Boot MongoProperties Source

Request

Is there interest in supporting this feature in Spring Boot?

If so, I am willing to contribute a PR with the proposed changes and documentation updates.

[wilkinsona]

Thanks for the suggestion.

If we're going to add a property, I don't think it should be only one. There are others, such as writeConcern, that are arguably of equal importance. I think it would make sense to add properties for all of them or none of them.

Settings that can be configured in both a URI or an individual configuration property have been a source of unwanted complexity in the past. #6424 is an example of this. The issue of whether Mongo's URI or the specific individual properties should take precedence has been raised in #44712. I feel that we need to sort that out before we add any more properties that can also be configured through the URI.

/cc @mp911de

[mp911de]

WriteConcern, ReadPreference, and ReadConcern are the three ones that fall into the category of configuring read- and write consistency. ReadConcernLevel is an enum, WriteConcern is an immutable class and ReadPreference an abstract class. Read preference can be configured with tags and staleness. Tags are somewhat a set of key-value pairs.

All three can be configured through an URI (com.mongodb.ConnectionString).

[Torres-09]

Thank you also for reviewing and providing the related issues for additional context.

I agree that all the major consistency-related properties are important, and I also recognized that supporting both URI and individual properties could introduce priority and complexity issues. If establishing a clear precedence policy and configuration framework needs to come first, I am happy to wait for the outcome of those discussions.

[wilkinsona]

Thanks, @mp911de.

I think it might be possible to provide configuration properties for all three, although ReadPreference would be fairly complicated. Those properties could be something like:

spring.mongodb.read-concern
spring.mongodb.write-concern
spring.mongodb.readpreference.name
spring.mongodb.readpreference.tags
spring.mongodb.readpreference.max-staleness

We could use a converter for String -> ReadConcern and String -> WriteConcern using each class's constants. For the read preference we could call one of ReadPreference's valueOf methods depending on which of the three properties have been configured.

We'd still need to sort out #44712 before tackling this.

[wilkinsona]

I just stumbled across #41280. There's a fair bit of overlap between it and #44712.

[wilkinsona]

We discussed this today and feel that we could add the new properties without addressing the issue of using both the URI and the properties and expecting some merging to occur.

[Torres-09]

That's great news!

Thanks for discussing this as a team and for the update. I'm happy to hear that adding these new properties is something you're considering.

Should there be any opportunities where I can contribute or assist as these discussions progress, please feel free to reach out. I'm keen to help bring this feature to fruition.

[jayychoi]

@wilkinsona Hi @Torres-09 , are you still working on this? I'd like to work on this if it's okay.