The Spring Data MongoDB Reactive module has only one implementation of the ReactiveMongoRepository interface, namely the SimpleReactiveMongoRepository class. It provides implementations for all methods of ReactiveMongoRepository and uses the ReactiveMongoOperations interface for handling all the operations at the lower level.

Let's look at the findAllById(Publisher<ID> ids) method implementation:

public Flux<T> findAllById(Publisher<ID> ids) {
   return Flux.from(ids).buffer().flatMap(this::findAllById);
}

It is evident that this method gathers all the ids with the buffer operation and then makes one request using the findAllById(Iterable<ID> ids) override of the method. That method, in turn, formulates the Query object and calls findAll(Query query), which invokes the ReactiveMongoOperations instance, mongoOperations.find(query,...).

Another interesting observation is that the insert(Iterable<S> entities) method inserts entities in a one batch query. At the same time, the insert(Publisher<S> entities) method generates many queries inside the flatMap operator as follows:

public <S extends T> Flux<S> insert(Publisher<S> entities) {
   return Flux.from(entities)
     .flatMap(entity -> mongoOperations.insert(entity,...));
}

In this case, two overrides of the findAllById method behave in the same way and generate only one database query. Now, let's look at the saveAll method. The method override that consumes a Publisher issues a query per entity. The method override, that consumes an Iterable, issues one query in the case when all entities are new, but issues a query per entity in other cases. The deleteAll(Iterable<? extends T> entities) method always issues a query per entity even though all the entities are available in the Iterable container and there is no need to wait for elements to appear asynchronously.

As we can see, different overrides of the same method may behave in different ways and may generate different amount of database queries. Also, such behavior has no strong correlation with whether the method consumes some synchronous iterator or reactive Publisher. So, we recommend checking method implementation of the repository method to understand how many queries it issues to the database.

In cases when we use ReactiveCrudRepository methods with implementations generated on-the-fly, it is harder to look at the actual query. However, in that case, query generation behaves in the ways similar to ordinary synchronous CrudRepository. RepositoryFactorySupport generates an appropriate proxy for the ReactiveCrudRepository. The ReactiveStringBasedMongoQuery class is used for generating queries when the method is decorated with the @Query annotation. The ReactivePartTreeMongoQuery class is used for query generation based on method name conventions. Of course, setting the DEBUG level for the ReactiveMongoTemplate's logger allows tracking all queries sent to MongoDB.