Edit: As @Olivier mentions, my original answer referred to OData in .NET and not Olingo.

Unfortunately as you probably have found out yourself, the standard Olingo documentation doesn't answer this particular question directly, though it does mention support for lazy-loading and streaming behaviour (which would not make any sense to filter on the application level).

However, you would be hard-pressed to find an ORM or DB Adapter nowadays that does not support filtering on the database level, as this will almost always be faster than doing so in your application for non-trivial workloads.

I will try to update this answer with a more authorative source.

(original answer)

According to this analysis:

As long as your data provider supports deferred queries and you don't force evaluation by calling something like .ToList(), the query will not be evaluated until the OData filters are applied, and they'll be handled at the database level.

Short answer, Olingo 2 JPAProcessor will query the database to only fetch limited data if $filter and $orderby are specified.

TLDR;

There are two things we need to consider here. Apache Olingo is a framework which allows people to implement OData Server and Client in Java, bare bones if will just provide you with the Abstract Classes and Interfaces which you implement OdataProcessors, how ever one wants.

Now coming to the second point there is a JPA Implementation also provided in the Olingo Project, which you can locate here

To answer your question, lets dig into the code of this project to see, how its implemented

We will have to start with JPAProcessorImpl and hop into process(final GetEntitySetUriInfo uriParserResultView), this is where the query and the actuals of how the data is fetched in the database are implemented.

At line 150 the actual query is already built,so if you pass $filter(where clause) and $orderby, we can see the values are actually being passed to the database and are baked in query